I’ve been working for and with Open Source projects for more than 8 years now, and I wanted to share with you guys some of my experiences so far. It has been such a rewarding journey that sometimes it goes unnoticed, mostly because it gets difficult to write a long blog post summing up the last 8 years. On this blog post I will be sharing some of my personal opinions about what things I love about Open Source communities, projects, organizations and the ecosystem in general. I will also try to share some advice about how to join and get involved with different communities if you are interested in doing so. After all the advantages that I will be describing here, i hope that you will gain some interest in it. I’m also adding here the the slides from our talk (Maciej and myself) at the @JBCNConf closing Keynote.
JBCNConf Closing Keynote Slides
Book recommendation: Open Organization by Jim Whitehurst
Benefits of working for Open Source Projects
In contrast to work for a company that produces propietary software for their customers, when you work in Open Source projects all you produce is free for everyone to use. The first thing that you realize is that now, your code will be much more valuable and used, not only by your company but by any person, company or other project that needs to solve the same problem. Then, why to reinvent the wheel and not sahre it with the rest of the world? The second big thing in working for Open Source project is that, you usually do something that really matter to you personally, you don’t need an extra motivation to do it, because you really care about it.
I imagine that your question at this point is: how do I make money? I need to pay the bills everymonth, so I cannot spend time working on free projects. The answer to that question is: patience and persistence. It will not happen from one day to the other. The main reason behind this is that open collaboration is based on Meritocracy, built on respect of your own achievements. In open source projects there no titles or hierarchies that matters more than your achievements.
Over the years I’ve recognized different levels of involvements to the Open Source communities from both individual and organizations. I had the luck of being involved in each of these levels, where I met and share discussions and ideas with a lot of really smart people.
Open Source Involvements Levels
You need to understand that working on Open Source projects it is not all about Code.
I’ve recognized the following levels of involvements, starting from the less involved ones to the really involved ones:
- Developer/User: in the java ecosystem, 90% of the time you end up using Open Source frameworks, but a very small percentage really get involved with any of these projects. We need to change this, as a User you can contribute with a lot of very useful information. Starting from: feedback on the documentation, feedback on the API usage, feedback on the communication channels being used by the projects, and more advanced things such as reporting bugs, suggesting features, etc. Every Open Source project will reward you from giving back that feedback and you will reward yourself with very useful knowledge, so everybody wins.
- Advanced User: the more that you use and like a project the more you can do with it. Advanced users are usually Software Architects which have the chance to suggest or pick from different projects to be used by their company to solve certain issues/problems. At this stage you “must” contribute back to the projects that you pick. The simplest way of getting involved is writing tutorials for beginers (so you can also train your co-workers), sharing that you are using the project in your company and recommend the tools when possible. When you are in such position, the more that you implement and use the tools, the more that you can suggest new features and you can also help to prioritize the open bugs.
- Expert User: when you reach this level, you are almost forced to contribute back. You can provide fixes by using Pull Requests and get in touch with the project team members by collaborating on providing solutions or reproducers for the issues or features that you need to get done. At this point you can start giving consulting to other companies that want to use the project that you love, helping them to spend time on implementing and not hitting the walls. You can also give training courses, and if you are already writing blog posts with tutorials, you are not too faraway from providing real value to other people. This is the point where you can start getting money for your knowledge. You can also write articles and even books (and I did that).
- Regular Contributor / Team Member: the more consulting that you do, the more people that you meet that is interested in the same things. Here is where the oportunities arise. You can find yourself being payed to work on the project that you love and care about. Tons of companies outthere are in need of expert people in different tools, there is always someone wanting to solve something that you really know about. What happens most of the time, is that by working with different customers you start producing code that can be added to the project itself, you can contribute that back and own that code/module in the community.
For organizations, things works quite similarly. As individual you also can contribute by pushing the use of Open Source projects to solve specific problems. In my experience of working with different organizations I’ve noticed different levels of involvements as well, but here I will explain how each different type of organization can collaborate with Open Source Projects:
- Companies using Open Source: private companies using OS projects can provide really valuable feedback about how the projects are working for them, they can train and collaborate with their experts to influence the roadmap of the different open source projects that they are using. As a company (manager) you can help by sponsoring Open Source projects that you are using by letting your experts to collaborate transparently in their projects.
- University creating and working with OS projects: several universities push their students to collaborate with OS projects instead of creating internal projects over and over again. Also university students can access to programs such as the Google Summer of Code, where Google sponsors students arround the world to work on different Open Source projects.
- Open Organizations: as described in the recommended book: Open Organization by Jim Whitehurst Open Organizations put down their walls to collaborate with Customers and Providers to provide better, more transparent and more efficient solutions for everyone. These organizations work as open source communities, where mutiple parties share a common goal and they all coordinate resources to sponsor open and shared solutions. If you work in a company that believes in the power of Open Source projects I strongly recommend you to buy and share this book internally.
In all these years one thing that I notice that is a constant is the feeling of keep learning everyday. For that reason, I would like to share some of the key important things that I’ve learned:
- Be Patient: if you find a project that inspire you to be involved, don’t expect inmediate results. It takes time to move up and build respect inside the community.
- Don’t be shy: get in touch with the project members, but remember to do your homework first. Project members will appreciate you reading the documentation and playing with the project first, before you messaging them saying “nothing work”. Also make sure that you contact them via the project channels, and not personally.
- Be Humble, Respect other’s merit (turn off the ego): this is one of the most important things to learn, and it takes time. You are not smarter than the rest of the people, I’m not smarter than anybody else, and the chances are that I don’t know as much about the project as the people that has being working there for more than 10 years. You need to be prepared for critisism, and you need to learn to not take it personal. All discussions and arguments should be open and honest.
- Prepare for redo things( don’t look for perfection ): you will not get things right the first time, probably not the second time either, so you need to be prepared for redo things multiple times until you get it right. Don’t be discouraged if you submit a pull request to a project and you get tons of “negative” comments about your code, don’t be embarassed either, just go over them and establish conversations and discussion about your work. Then change accordingly and submit a new version with all the improvements.
- Be Proactive: don’t wait for people to give you directions, just do things. Nobody will tell you to write a blog post about how to use a project to do a certain thing. Start simple and improve your contributions over time.
Once you start working by following these advices it becomes a way of living, and it is very difficult to go back.
I hope that this blog post inspire someone to join an Open Source Project!
Questions? Comments? don’t hesitate to get in touch.