The world is moving fast, even more in a world eaten by software. Like most developers, you are probably up-to-date on the latest frameworks and their quirks. Mostly inspired from the open source world, my experience come from real codebases, nailing down the skills a book won’t teach you. Let me tell you how my encounters with open source made me better.

I as a developer a decade ago

I started my career thirteen years ago, joining a team in charge of developing and maintaining a software used by a lot of employees at my company. When I recall that time, there were some good coding moments, but unfortunately I also recall hard times. Spending a lot of time analyzing and correcting issues. During busy seasons like Christmas, issues tended to pile up. We spent full days addressing them and correcting data instead of solving the root cause.

A reason that seems obvious to me today is that our development process was poor. We focused on delivering business evolutions more than improving our documentation and reducing our technical debt. As a consequence, it was more and more difficult to deliver corrections in a reasonable lead time. Then one day we had to stop business evolutions for a while… Something that is unthinkable today, in a world where time to market matters more than ever.

Meeting the Open Source world

It is amazing how much we can learn from the open source world. I will never forget my first contribution because it was refused by the community. I was so surprised. The reason was not linked to the feature itself, which was expected and warmly welcomed. It was because of the lack of documentation I provided. After some discussions with the project owner, the answer was:

Thanks for you interest in our solution and to your contribution, but please read carefully our contributing.md. We expect you to update documentation by providing what this feature enables and how to configure it. We support this solution so we need to be fully autonomous to correct potentials bugs or make it evolve without depending on you. That is why documentation and test coverage are part of our contribution policy.

My first thought was “Oh my god! They rejected my contribution due to a lack of documentation!”. I noticed that their priority was to ensure quality and stability of the source code and documentation. As a developer, I was so happy to see those values coming from open source project. It made sense: Source code is their business, they must ensure its quality. Instead of knowledge being communicated through people, an open source project’s knowledge relies only on documentation and automated tests. I started thinking about how I could apply this development process lesson in my daily job.

Applying an Open Source Mindset within Organization

My first conclusion was that the open source world was more professional than what we do in my team. I understood how developers all around the world could build so strong solutions together. I could clearly see how Linux was able to compete with close source solutions. My company has the same configuration. We have multiple teams located in multiple countries and cities. Why should not we apply the same mindset and rules to our organisation, that is what is Inner source.

How many times had I found a bug in a project and wanted to make a contribution but? I could not because I did not have access to the source code. Imagine how painful it was for me to wait for a new release of the software while I was able to do it by contributing directly to this project.

To manage Inner source as open source project, you first need to set up a single source code repository for the entire company. This synergy around a single repository will promote contributions. Any developer can make pull and merge request, instead of having to create issues to the product owner, wait for him to prioritize, correct, test and deliver patch.

Mindset Benefits

By opening your source code, you are opening your work to feedback from all your developers. You won’t give yourself a pass when everyone is looking. Your ego will force you to do a better job, like me right now writing this post. The open source community will push you to apply rigor, as they did on my first open source contribution.

Another benefit comes with peer reviews and egoless programming. Developers are learning from the reviewers and reviewers are learning from the code. They are not just reading. They need to understand how the developers thought about issues and resolutions. Peer reviews are experience boosters. They improve developers skills. They offer a better learning curve.

A recurring question about Inner source is : “Do you think teams will contribute to projects they do not own” or “Are all developers technically able to contribute?” That’s where the magic is. It is not only source code contributions. We can all contribute by:

• opening issues to suggest some improvements
• report bugs and documentation mistakes
• answering to issues (even before the official team)
• improving documentation and set it more emphatic to developers

And, yes, if we master the technical stack, we can contribute to the source code, too. The overall quality of your project will benefit from these contributions.

Do you know the feeling of deep ride you get when you contribute to a community? When you receive some comments or questions about what you have done; when you realize that people are looking to your code; when you check to see if you can help them — it makes you feel like a respected member in a community.

Another benefits is the collective knowledge. The power of a network that will always be stronger than individual efforts.

Conclusion

These are my thoughts and feelings about contributing to open source software. I learn so much, so fast when contributing. That’s why I would like every developer to contribute to open source as soon as they start to learn. I would also like this mindset to be widespread in my organization, as I deeply believe it will make a big difference. Open source is not about free vs. paid softwares. It’s about sharing.

From my point of view, applying this sharing mindset is key to a successful project. Microsoft, famously a closed source company, uses Linux (Azure cloud service) and has become today one of the biggest companies contributing to Open Source. They have also made 60,000 of its patents open source to help linux avoid lawsuits. There are also some good examples outside software development. Just take look at collaborative platforms like Kickstarter, Mymajorcompany and Eyeka. Uber and Airbnb are part of the sharing economy platform. All of these take their power from networks and collaboration.

Disclaimer: These opinions and experiences are mine and may not reflect my company and/or teammates ones.