First of all, thank you. Yup, I was talking to you.
People like me tend to get the credit when things go right, and the axe when things don’t, but in the open source world it’s you who ultimately decides the fate of a project. Engineers and managers and designers work hard, this is true. None of that matters unless we have an involved community simultaneously pointing at the shiny object up in the clouds while holding our feet firmly to the ground.
If you’re confused, please allow me to explain. Engineers, managers and designers tend to have a critical failing: being creators has a tendency to go to our heads, and we assume (when not told otherwise) that our way of doing things is The Right Way. Sometimes, we need to be deflated. It can be oh-so-tempting as an engineer to throw yourself head-first into an exciting new feature, but it’s our community that reminds us when this just isn’t the best way to spend our time. Sometimes it’s not the most glamorous work to play bug whack-a-mole instead of working on the shiny feature, but this doesn’t make it any less important. So having a community that’s active (rather than reactive), following our progress and reminding us where our priorities lie is an invaluable advantage.
Similarly, the existence of a proactive community can bring thoughts to mind that we might never have dreamed of on our own. In the last six months, we’ve had people throw some fantastic ideas at us for the SSSD. Some have appeared in the 1.1.x release and others in the 1.2.x series. We originally approached the SSSD from the perspective of a laptop user being able to maintain a single consistent user account whether connected to their corporate network or not. Thanks to some tips from our community, we’ve realized that we also have a place in the datacenter, helping servers ride out the occasional internal outage.
These are examples of the true power of open source. It’s easy to come out and say "well, it’s better because more people can look at the code and find fault with it." The true power of open source is that people can look at the code and make of it anything that they can dream. In a closed development style, the product is always going to be limited by the imaginations of the engineers and product management team in the company, with maybe the occasional support call having some effect (though not often, in my experience in the closed source world). Not only does open source welcome such ideas, we encourage them and nurture them. If we don’t have the time to implement a feature, we’ll try to hold your hand and guide you to do so for yourself.
Now, that last topic I need to discuss in a bit more detail. It’s all very good to say “we appreciate our community” and “we welcome patches”, but sometimes it can be hard to hold to that. There are times when it’s difficult to include a community-member’s ideas. Sometimes the reasons are obvious: the community member wants the world, on a silver platter, with the crusts cut off. Providing us with our next great idea is a wonderful thing, but sometimes people expect miracles. We’re only human (or in some cases, extremely sophisticated shell scripts).
Then there’s the flip side. Sometimes you have a community member who is so driven to see a feature that they want included that they will spend the time and do the work themselves. Proud with the work they’ve done, they volunteer a patch. Unfortunately, as I mentioned above, sometimes being creators has gone to our heads. There may be no disagreement that the patch would solve a problem or provide a great new feature, but sometimes it’s just not feasible to accept a patch as-is. Sometimes this is an innocuous thing: maybe the patch fails to meet the project’s style guidelines. Sometimes it might get ignored for an extended period because the main team is working under time constraints by someone that’s paying them for their work. Sometimes the patch may truly be flawed, and no amount of massaging can make it into anything usable (in a reasonable amount of time).
At times like these, communication becomes the key. As I said above, an open source project lives or dies by its community. It’s all too easy to alienate people, especially with the aforementioned hubris we developers often suffer from. It should be understood that while contributions in general are always welcome, sometimes specific contributions are not (or at least are not ready for the mainstream). At times like these, it becomes more important than ever to have established a good relationship with your community.
I’m going to admit here that I don’t have the answer to many of the difficult questions like “How do I deal with an unresponsive upstream?” or “Why does this person keep submitting the same patch that I told them doesn’t work?” It’s a learning process for everyone involved, on both sides. And come to think on it, maybe thinking of it as sides is part of the problem.
Originally posted at Stephen Gallagher's Open-Source Blog.
2 Comments