How can I consult users of my FOSS library about a design change idea?

Question

I have a FOSS library made public through GitHub. It's not a big library, it doesn't have a community around it or anything like that - but it does get a few dozen unique clones a week.

Now, I'm considering a design change in this library. It's not merely internal, it's a significant change to the API. It's "my" library, so I could just go ahead and do it, but - I want to get users' opinions about this change.

Obviously, I don't have their details and can't actively ask them. How would you suggest I approach trying to poll their opinions?

Note: I'm interested both in "Support/object" binary information and in longer appraisals of the suggested change.

Answer 1

The most direct way would be to set up a public forum for your lib where you can discuss such things.

You could also bring a new "2.0 experimental" branch in place where you demonstrate how the new design and the new API will look like. Also, add deprecation marks into your current "1.x" version line of your lib at the appropriate places like the API docs.

If you think setting up a forum is too much effort, just put an email adress on the main project page and tell people to use it for feedback on the experimental branch.

If you don't get enough feedback within a reasonable amount of time, just go ahead - people who do not inform themselves which route version "2.0" is going to are probably happy with version 1.0 of your lib and are actually not interested in how the 2.0 API will look like.

Answer 2

I think there are two problems, how to engage with my user base, and how to make breaking changes.

The second answer is easier, you bump the major version number (semantic versioning)

I think there are some arguments for just putting it out there. New users will start with the new version. Users having issues migrating might open issues. If nobody migrates, that might be an answer as well. It depends a little bit how good the available analytics on observable user behaviour are.