Today in one of my favorite irc channels a heated discussion broke out about submission of “patches” to this particular Open Source project. As a huge fan and long time evangelist for said project I was shocked. When you love something you tend to be blind to it’s faults (mostly) and as I’m not a developer I wasn’t privy to the issues this gentleman was experiencing. The conversation got me thinking about the way that “outsiders” to a project community might view issues we feel are inconsequential (or unimportant).
So how does an Open Source project deal with all the “needs” of it’s community and still move forward with it’s own plans for world domination?
Listen to the average user
The average, everyday user is the one that will help keep your project alive and kicking. If you don’t have users, you don’t have a project, pure and simple. That isn’t to say that every single complaint is cause for rewriting code or changing planned features. Complaints and concerns from your userbase are a good sign, your project is being used in an active way. Learn how to separate, “I’m complaining because I’m lazy and don’t want to learn more than I have to” from “I’m complaining because I really love your project but this issue is a major deterrent”.
One thing I’ve found with developers who have worked on a code base for a long time is that they reach a point where they know it so well that they are oblivious to the types of issues a user who is working with the project for the first time experiences. The developer already knows what comes next, or what to expect, the new user does not. Common responses to new user questions: “Oh that’s easy, just do A, and then B and then C, and if that doesn’t work you can do C first and wait 20 minutes and do B, ok?” To the average user, that is not easy, that is complicated and so they go to another project that just says, hey, do A and then B, and tada you have your result. Don’t make assumptions about the average user. Listen and absorb and if (after you’ve heard their concerns) you still feel it’s not important, let them know why and give them a good reason. End users are just as important as developers and integrators in shaping the overall project and it’s future.
Encourage criticism (as well as praise)
The art of dealing with criticism without harboring hurt feelings is tough when you’ve spent hours upon hours upon days upon weeks working on your project. Much like the mother who bristles at a well-meant comment about their child, developers feel a connection to their project and criticism feels like a lack of appreciation for all the hard work. In reality, constructive criticism can provide project developers with guidance and an objective look at your project. Granted there are times when asking for input just doesn’t make sense, namely things like, “I need to give this python class a unique name, what do you think?”.
It’s the quality of the user, not the quantity that counts. Though for some projects the number of users seems to be more important. Don’t try and draw users in that don’t need what you have to offer. If your project is meant for large enterprise installations and requires a healthy investment of time just to get it up and running in a meaningful way, then say so. Don’t lead the user into the misconception that your project will solve all their problems with no effort if in fact they need to expend some effort to produce results.
I’m a much happier camper if the project tells me, “hey, new user, you are going to have to spend time reading this manual and this won’t be easy for you if you don’t know A, B or C” then I can decide if the project is worth my time and extra effort.
Open Source project communities can often times develop their own “cliques” (remember those from high school) with a penchant for putting outsiders in a class all by themselves. These outsiders are your end-users, the people who adopt and promote your project. So they weren’t there when you launched your project, they didn’t attend the last sprint nor have they contributed to your code base. Even so, these particular individuals, end-users, are the key to success for your Open Source project.
A great article by Ryan Paul on Building Belonging is the secret to Open Source Success