Why Most Software Engineers Don’t Contribute to Open Source?

People contribute to open source for different reasons and with different agendas in mind.

There are different philosophies and theories about open source products. Some claim that there is reciprocity if you use something for free. Others demand a regime similar to socialism and Marx’s slogan – “From each according to his ability, to each according to his needs.

That doesn’t resonate with everyone. People are somewhat selfish by nature and solving global problems isn’t always at the top of their minds. That’s the reality we live in.

Some do genuinely support the philosophy and spend a significant amount of time on contributing back in exchange for no direct compensation. I’ve probably spent over 2,000 hours on open source contributions – not accounting for any free applications or plugins that I’ve built separately.

Therefore, I’ll pinpoint several factors that open source contributors consider and often utilize (as compared to developers who don’t contribute back).

1. Community

WordCamp Europe 2014 in Bulgaria with 900+ participants in 4 continents.

Co-organizing WordCamp Europe 2014 in Bulgaria with 900+ participants in 4 continents.

I have met contributors who are active members of a specific community. The communities range from being a platform, a framework, a technical stack, a general dev forum, a hackerspace, to a competitive programming group.

Communities project a certain sense of commitment as there are a global mission and a form of empowerment. You can meet advocates, evangelists, or core contributors to well-known projects. It’s quite motivating, to say the least.

And that doesn’t have to be an exclusively technical community. There are wonderful meetup groups and conferences by Firefox, Eclipse, OpenOffice – different products actively used by regular folks. These volunteers may be in charge of organizing community events, lectures at schools, translating the products, helping out with beta testing, answering support forum tickets and more.

Those who are more engaged and proactive in open source communities tend to contribute more frequently since they regularly interact with other members.

2. Company Contributions

There is a limited number of jobs allocated to community contributors. This is common in certain fields and slowly gets more popular in others.

Think of evangelists and brand ambassadors. Company contributors may be sponsored employees. They get their payfor giving back to a platform or a technical stack.

Again, those are not limited to development – a paid translator or an event organizer may also be involved. Larger organizations invest in contributors for various reasons – making an impact, having a stake in the ongoing development, influencing the roadmap of a product, showcasing their expertise and more.

I had a technical partnership with a hosting vendor several years ago who paid for some of my patches and sponsored my trips to conferences in the US and Europe. We had worked together for nearly two years and they have grown by 200% or so since, currently employing several full-time contributors and plenty of volunteers.

3. Learning

Regardless of your expertise, there’s a lot you can learn in every project at work.

But that’s often limiting. You work with a (small) team (even if that’s thousands of colleagues), serving a smaller customer base.

Contributing to a popular open source project is a completely different game.

  • You dive into a massive project for tens of millions of people, or even more.
  • A minor change of yours could impact millions of web applications overnight.
  • You work with incredible talent dispersed around the globe, profiling in different verticals of the technical stack.
  • Each technical change has to consider backward compatibility, hosting limitations, how that would affect different languages, impact 3rd party vendors, technical agencies, non-profit communities – you name it.

It’s mind-boggling. Thousands of people review a single line of code who come up with feedback and improvement suggestions, accounting for user experience, accessibility, security, performance considerations, business impact, governmental regulations, data privacy laws and whatnot.

Fascinating. And extremely valuable in terms of becoming the best software engineer you can be.

4. Portfolio

From a hiring standpoint, I always consider open source contributors higher when reviewing CVs.

Our technical lead Stanko Metodiev has even decided to contribute daily for a year or more. He managed to continuously submit patches that landed him several commit permissions to open source projects.

I’ve received applications from developers working in Fortune 500 companies and numerous popular startups worldwide. Often times, they apply as they were laid off due to poor code quality, productivity, or something else.

That’s not a rule of thumb. But how could you verify their coding skills or whether they are a great team player? That is quite transparent for open source contributors.

Moreover, companies that support open source can benefit from hiring more contributors. It’s a good selling point and showcases experience and background in certain technologies.

5. Top 1% Consultancy

Generic service providers and organizations working with proprietary technologies have little to no incentive to contribute to open source.

Otherwise, you probably work in an organization that provides technical solutions on top of an open source platform or use open source libraries, frameworks, tools. The more you specialize and go upscale, the more challenging problems you solve.

Which leads to certain flaws and limitations of the core products. Those can be overcome only by those extremely familiar with the code base – people who can submit a patch or find a workaround that’s replacing a core module with their own.

Moreover, understanding the core philosophy and the roadmap is crucial for ongoing business. Your solutions should be in line with the long-term goals of the product. You have to make decisions based on community decisions. In addition, you should test and mitigate any possible risks and regressions during ongoing updates.

Basically, it’s almost expected to contribute actively once you work with large corporations building massive platforms.

6. Direct Compensation

And here’s the main culprit to the question.

  • Starting a job means getting paid for every hour spent at the office/working on a project. It’s simple as that.
  • Contributing to open source has no direct/measurable impact on your profit. Many have spent years without making a living off their contributions.

Except for developers who can figure out how to monetize their skills.

  1. Different ways to earn more for open source contributors:
  2. Become better and more knowledgeable and get promoted at your company.
  3. Build extensions, add-ons, plugins and charge for them.
  4. Provide consulting to businesses looking for top expertise.
  5. Write documentation, tutorials, case studies for industry magazines (paid).
  6. Give talks at conferences.
  7. Provide ongoing consulting (code reviews or external CTO) to businesses looking for excellence in that technical stack.
  8. Get monthly support through Patreon or other low-cost crowdfunding platforms for reputable contributors.

All of those are viable ways to grow your revenue or switch to a consulting model that would be more rewarding than a full-time job.

7. Intentionally Embrace Open Source

Even within the realm of a full-time job, most organizations (especially startups and smaller teams under 200–500 people) are open to restructuring their technical stack or introduce new tools or libraries.

Developers who would like to join a community can still suggest an open source product for an upcoming project or an ongoing one. Newly introduced features and enhancements can be pushed upstream as pull requests – progressively improving the code base and participating in the global development effort.

Whenever we use smaller libraries, we occasionally do a complete code review and submit fixes or improvements to the core products. It makes more sense in the long run. Alternatively, we can fork the core product, extend it, invite the original contributors and welcome other open-source fellows, too.

A few years ago, I wrote a Contributing Manifesto that I’ve shared with some of my consulting clients looking for development work. I’ve launched several small products to the public as a result – which grows my portfolio, helps others, and receives additional improvements for free by other technical users of my products.

Your thoughts?