Open source software has never been so popular. With GitHub becoming the “Facebook for Developers” we see a growing amount of new projects every week. Some are initiated by big companies and others by individual passionate developers.
But what happens when they get massive adoption? And how does support fit into it all? Here are three developers who shared their views on the value of support in Open Source projects.
Michal Papis – Open source developer and maintainer of Ruby Version Manager (RVM)
When I was starting my journey with RVM, as a user I was impressed with the level of support Wayne E. Seguin (the original author) was giving for RVM, he was available on IRC for discussions and the tickets were handled really fast. So it felt natural for me to continue this level of support for RVM users when I first became a developer for the project and later on took over maintenance.
The majority of time spent working on RVM is in IRC discussing issues and in issue tracker handling tickets. This gives me a unique perspective to what is needed and what problems users have. Knowing what is broken and what problems users are facing allows me to understand what is expected of the tool and how it can be improved for the users to benefit.
Use automation to solve common issues
In the beginning working on support for a big project like RVM was consuming a lot of time. A lot of problems were answered always in the same way. Being tired of repeatedly debugging and solving the same problems I have started adding automation into RVM. In the beginning these were small things like an extra warning and setting default values for environment. With time the changes started to be bigger automating whole processes.
Using automation solved problems users had. Adding automation to handle a big array of possible problems also introduced new problems, smaller, fewer, but still. It took some time to fine tune the automation to make most of the users happy. The problems reported stopped to be of a common nature but it took more fine tuning code to behave properly.
Tobias Pfeiffer – Open source developer and user, contributor to Shoes
In my experience, support is one of the make it or break it points for open source projects – especially for getting contributions in. I believe that responding to pull requests is one of the prime responsibilities of maintainers and committers. When a person has put that much effort into providing a fix for a problem or a new feature then you should really honor that. Otherwise it is terribly demotivating.
I’m speaking from painful experiences here. When I tried to get my first open source contribution going I almost dismissed contributing to open source entirely due to such a bad experience. Basically when I commented that I would want to work on an issue nobody commented. Then it took me a day to patch it up and send the patch in. No reaction. Two months after that the issue was marked as the duplicate of another bug which was marked as won’t fix. Easy to say I never considered contributing to that project again. I still got outstanding pull requests without a comment from maintainers/committers for some projects – open for months to years. I don’t even bother to contribute there anymore.
Be responsive
But how did I get back into open source? Well as part of Mendicant University I was forced to contribute to an OSS project – so I gave it another shot with Shoes. The experience was very different. I got replies in a timely manner, which I’d define as in under a week (mostly faster) – most of us have jobs. People were excited and happy about my contributions. I stuck with the project ever since and try to recreate the same experience for new contributors.
This not only goes for pull requests but also for opening issues. If my issue seems to be ignored for a month or so I’m much less likely to open another issue for that project. I mean – nobody seems to care anyway. For projects that respond rather quickly and also get to fixing bugs I’m much more likely to report even minor issues because I know that my input is valued and of significance.
My point is this: Value contributions. Give feedback. Let them know that their contribution has an impact on the project. People might repay you with ongoing contributions ultimately making life as a maintainer easier and leaves people happy instead of frustrated.
Ron Dahlgren – Open source user
Recently, I’ve been doing some work with the Rust programming language. I’ve found that their community has been extremely responsive and helpful via their IRC channel. This level of assistance has kept me from abandoning my efforts and allowed me to get past the rough spots involved in learning a language that is still evolving. I really can’t say enough about how great this community is.
Great support helps develop an active community
On the other hand, I have certainly had instances in the past where I’m greeted with a void when trying to interact with an open source project. Whether it’s from languishing pull requests, unanswered emails/forum posts, or neglected issues – this really makes a difference. More than a few times in my career, I’ve made the decision not to use a particular piece of software solely because the support was lacking!
More painful to me is when a particular favorite piece of underappreciated software, for instance pork goes dark. If I had the time available, I’d take over and care for dying projects that I appreciate, but without the available time, they are destined to end up in obscurity, as a bullet point in a list on Wikipedia.
I’ve got some minor level of perspective on the challenges of being a FOSS maintainer. I’m the sole developer on a couple of very, very low usage projects. Nevertheless, when I find myself unexpectedly dealing with newly discovered issues or user’s requests, it catches me off guard. It would be very taxing to work a full-time job while maintaining a popular FOSS project.
About the Developers
Michal Papis: Open source developer, maintainer of RVM (Ruby Version Manager) tool to install and switch between different ruby versions. Michal is currently working on version 2.0 of RVM that will extend its scope other development languages. You can Michal on GitHub, Twitter and http://niczsoft.com
Tobias Pfeiffer: Open source developer and user, contributor to Shoes – toolkit to build graphical user interfaces in ruby. Tobias also organizes the Ruby User Group Berlin and is a coach at Rails Girls Berlin.
You can find Tobias on GitHub, Twitter and http:/pragtob.info/
Ron Dahlgren: Open source user. Follow Ron on Twitter and check out his personal website http://www.dahlgren.so
