Interesting topic 
One of my pet peeves in FOSS is the belief that, because a project started by scratching an itch, the maintainer(s) “always know” which new features make sense. The reality is that, the moment you release your “itch scratching” to the world and user number 1 turns up, you are no longer the user, and you know pretty much nothing Therefore, there is very much a need for formative design research, as with any commercial product.
This is an easy one: how do you know what “better” is? You need to find out! What’s better for you is probably not “better” for the bulk of the project’s users. Or maybe it is, but you cannot be sure until you validate your ideas.
I think they are more nuances than fundamental differences.
One of them is the fact that part of your user base is bound to also contribute to the product. We must watch for “maintainer bias”, but you cannot disregard the maintainers’ perspective on the basis that they are contributing and that automatically makes them “developers” instead of “users”. Sometimes they are both. I’ve found the way you engage with these users is somehow different to how you engage with users who do not contribute to the project. The usual participatory design and research techniques must be tweaked to accommodate their dual role.
Another one is derived from the high number of communication channels and high volumes of communication in FOSS projects, all of which are completely open and accessible. For FOSS, it is possible to gather tons of insights about users’s goals, needs and context just by combing mailing lists, forums, bug reports and IRC channels. Very often there is no such thing in commercial products.
You also have conferences (you often don’t in commercial settings), where at least part of your user base gathers. You can do a lot of ethnography-like research when attending those, and also carry out short, focused validation studies with users you grab at sessions, booths, or while having beers!
Finally, because of the openness, and because you often have a vocal and technologically inclined user community, the “put something basic out there and check out what happens” becomes a particularly productive approach. You very often don’t have the freedom to do something like that in commercial settings.
It would be really interesting to produce a list of “FOSS particularities” that impact the way you plan and execute formative and summative research + design iterations.
Yes! And most of the time you do somehow, even if it’s not formalised or structured, and you don’t directly involve users in the process.
Yes! And it would be really interesting to come up with a lightweight approach that could be applied to very small, scratch your own itch type of things.
