I came to work with open source after an experience in college. We used a system called Usenet,a world wide distributed discussion forum. At the university, there wasn't an email client I liked, so I wrote one and just gave it (including the source code) to whoever wanted it. This experience introduced me to a community of people who made things and shared them; it also introduced me to a job at my alma mater as a Usenet administrator.
In that position, I was an administrator for one of the (at that time) top 10 Usenet servers in the world. It was running open source software: InterNetNews (INN). Running this server taught me how to support bug reports and send patches to the maintainer. Then, I took over maintaining the FAQ document and did that for some years.
Later, I began working for a company running JBoss Application Server 3. We created some of the required artifacts using XDoclet. We had some pain points with both, so I wrote patches and enhancments for both. After some time, I got access to the source repository and I was then able to directly check on the fruits of my labor and I became more in tune with the inner workings of the project. Working with XDoclet, I incorporated the patches others submitted, answered questions, and submitted bug reports. Eventually, I got the rights to do releases, which felt very special.
The thing about open source is that a lot of it starts with having a pain point, like using software that was given to you to use that you don't like. If you are lucky and that software is open source, you can have a look at the source code. And, if the "pain point" is big enough, you can debug it and create a patch. Or, if you have some questions about an aspect of that software, those questions may get answered by someone on the development team, or you might figure it out for yourself. Then, when the next person comes along and asks that question, you know the answer and can help the project as a whole by answering it.
Answering questions and submitting patches
When you're getting started with open source projects, answering questions and submitting patches will earn you credibility within the project, and at some point it's like that the folks in the "inner circle" will ask you if you want to have the rights to directly commit your patches or to edit documentation pages. With greater permissions, comes greater responsibility... and greater possibilities to make an impact on the project.
If you can't code, remember that there are so many ways to get involved in an open source project beyond coding. Like, fixing typos in the documentation or translating it. Many projects also have a bugtracker. Use it to view an old bug report, then try it with the latest version of the software and report the result back in the tracker so that the development team can better judge when and how to fix it.
Here I shared 10 ways to get involved in an open source project without writing any code.
When you contribute, don't be disappointed if folks are too busy to look directly look at your contribution. This isn't personal! Try to make it easy for them to consume your work by applying a small patch that explains what is broken and what can be done to fix it. Just saying "does not work" without further data, gets everyone nowhere. Similarly, if you create a change in the source code, make sure it applies nicely and does not break any tests. Strive to be a team player and it will earn you credibility which will result in faster feedback and greater accessibility to the open source project.
View the complete collection of Beginners in Open Source Week articles.
Comments are closed.