In the open-source community the so-called “Linus’s Law” by Eric Raymond is often cited as one of the reasons why open-source projects would be so much better and more bug-free than closed source alternatives. But is that actually the truth?
Let’s take a look at said “law”:
Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
This statement itself is obviously pretty much accurate and disputing it would be hard. However the real interesting question is whether there actually really is a “large enough beta-tester and co-developer base” scrutinizing other people’s stuff and actively helping to fix any problem.
Open-Source projects live from the contributors that sacrince some of their spare-time to help making software better for themselves and everyone else on this world using the software. As an open-source project every contributing person is important and should get treated that way.
However, the reality is that most people don’t contribute back and are “just” silent users of the project. (which itself is absolutely okay! – You don’t have to contribute back to everything.)
Why do people not contribute back?
When talking to users and asking them why they don’t want to contribute you often get a huge range of replies, basically coming down to the following two key points:
- People not knowing how to contribute back. (or that this is something you can do!)
- People don’t like the code-base or the government model of the project.
While the second point is more about a political issue and the fact that you can’t make everybody happy, the first point can indeed be tackled by every single person. As a user you can start contributing and as upstream developer you can help making this experience as flawless and easy as possible.
What does contributing back really mean?
Contrary to the belief of a lot of people contributing to open-source does not mean you have to be a programmer contributing to the source code. There are tons of other also very important ways to contribute back to open-source projects. You too can be one of those hidden heroes ensuring that open-source rocks the world.
Design: Let’s be honest, most developers love checkboxes and configuration switches. Because obviously isn’t the most fun thing when setting up a new system the configuration?!? Turns out, actually the regular user is much more concerned about an easy-to-use interface with sane defaults. Finding an easy-to-use interface in combination with sane defaults is something where Designers can help.
Documentation: Every project that wants to get used by not-so-tech-savvy users should consider having a complete and throughout user documentation that covers how to use the software.
Helping: People usually encounter problems when using a new product and you can help them by volunteering some of your time into the project forum or IRC channel. Another great and fun thing to do is to triage bugs.
Security: While there are a lot of security researchers out there using open-source projects the reality is that there are actually only in very few cases security researchers involved in open-source projects to ensure a in-depth defense against all possible threats. From personal experience I can tell that a lot of open-source projects would be more than thankful to accept some help. However, be aware that telling developers “their code stink” is probably not the best way to contribute back. It’s always better to be pragmatic and explain the risk and how the problem can be avoided in the future.
Testing: If you ever encountered a bug and wondered why it wasn’t fixed before the reality is often that it haven’t been reported before. There are a lot of possible deployment scenarios for every open-source project and if you want to ensure that the next major release will run flawlessly on your environment the best way is to test beta and alpha versions and report back any bugs to the upstream developers. Ensure to add as many details as possible to make it easier to help you!
Translating: Did you ever wonder why your favourite open-source program is even available in Finnish or Bengali? That’s because people like you spend some of their spare-time and translate the software into their native language. In most open-source projects this does only require you to be able to understand English and be able to use a web browser.
Obviously there are also ton of other ways to contribute back to a project. These are just some ideas to give you some input how you could help in your favourite open-source project.
A lot of popular open-source projects will have some page explaining how to contribute, for example we ownClouders have this dedicated contribution page for new contributors that explain what becoming part of the ownCloud Community and contributing back means.
Some closing words for new open-source contributors as well as for open-source projects:
Be pragmatic: As an open-source project it’s important to offer easy ways for people to contribute back. If your
translation process consists of manually editing
.po files you might consider switching to a web-based platform such
as Transifex. Having a part component of your infrastructure not relying on open-source is
for such cases absolutely okay.
Be welcoming: Always be nice to the people that you encounter and help them if they have any problems when trying to contribute back. If somebody has trouble setting up their local unit test setup this might be potentially a new contributor and it’s important not to scare them right away with “RTFM”.
Be friendly: In the online world things might come over more rough than you intended to. It’s usually easier for everybody if all stay friendly to each other.
Be ready to learn: We can’t know everything and we have to accept that. If somebody else comes up with a different approach or suggestion you should not be mad on the commenter and instead learn from your mistakes and do it better the next time. Mistakes happen to everybody of us!
I recommend everybody to take a look at ownCloud’s Code of Conduct which is a nice write-up about handling issues in open-source communities. (and was also input for some of above points)