Open Source adoption can be affected by the fact that many businesses prefer in-house solutions rather than leveraging existing Open Source options. Even when a robust ecosystem supports those options. Oh, they do have reasons! But almost all these reasons can be cast back. Let’s discuss when it’s more strategic to use Open Source and when it’s not.

The reasons for the “not invented here” syndrome are strong:

Security and compliance requirements: More control is required in specific industries like finance or healthcare. They need to meet specific security and compliance standards.

But: Many emerging Open Source projects already adhere to stringent security standards and compliance protocols (or companies can fork and modify them to meet all regulatory requirements).

Bug hunters also often target popular Open Source projects, reporting vulnerabilities developers could not even imagine. With their solutions, companies have to involve security specialists.

Specific needs: You can find no OSS fully tailored to your needs.

But: The Open Source community can also contribute or consult on specific features, saving development time and effort. Moreover, existing Open Source can be a strong basis for homegrown solutions. Popular OSS maintainers usually witness many forks of their projects that contain just small company-specific changes.

Also, businesses often ask an Open Source project they use to develop a feature they need. This is also beneficial: a promising feature appears in the project and becomes available for all other users much faster. (This often happens with our Open Source project, AnyCable.)

Long-term control and maintenance: In-house solutions ensure full ownership and companies can dictate the roadmap, provide long maintenance, and prevent the problem of “abandoned” OSS solutions.

But: this creates a “bus factor” — if key developers leave the company, knowledge can be lost, leaving behind unsupported code. In OSS, the codebase remains open for modification.

A well-maintained OSS product can grow and evolve without most of users being involved. There’s a big chance that the required feature has already been added to the adopted OSS solution. Last but not least, mature OSS products have already overcome most of the “teething problems” a homegrown solution may not have even faced yet.

Many companies publish their homegrown solutions as Open Source to acquire all these advantages. A good example is Ruby on Rails, a Ruby framework initially developed as a base for Basecamp. After being published as OSS, it acquired a huge community that heavily contributed to its development.

(Intriguingly, it was the Ruby on Rails community that, in turn, became the force that helped quickly adopt GitHub, today’s hub and universe of Open Source projects.)

Integration with proprietary systems and infrastructure: in-house solutions can be more effective and integrate seamlessly with existing systems.

But: OSS solutions often come with flexible APIs and modules that can be adapted to work with custom infrastructure, which can be more cost-effective.

Competitive advantage: “If we use what everyone uses, we are no better than everyone.”

But: This reason may be valid when a company develops a unique feature that other solutions lack. Yet many such cases are simply the result of the “we can do it better” mindset. Ultimately, companies can spend months or years trying to catch up with existing solutions.

Scalability and performance demands: in-house solutions can grow easily with the product, because they adhere to specific performance optimizations.

But: With contributions from major tech companies, performance-optimizing plugins or forks available, adapting an Open Source tool to meet high demands can be a cost-efficient alternative.

It doesn’t fit our approach: Sometimes, existing solutions do not solve problems in the way companies want them to. Adapting an existing solution to the desired approach using mud and straw may result in unstable work and overcomplicated architecture.

But: There’s a huge chance that the existing OSS product’s approach is better than the one an organization tries to implement.

This is a classic “XY problem”: people think first of a solution that comes to their mind, not of the core problem itself.

Let’s take our OSS solution for resizing and converting remote images, imgproxy, as an example. Many companies use an old-school pre-processing approach to orchestrating image processing. That’s why they don’t even dare to try imgproxy or similar solutions, as they are hardly adaptable to that approach.

Dozens of companies adopted imgproxy and its approach, finding it simplified their product architecture and avoided potential problems from their previous methods.

There’s a paywall: Some authors adopt the Open Core model to monetize their Open Source projects. And businesses can reasonably expect that one day, they will have to pay for a feature they need.

But: When developing a homegrown solution, companies start paying for it immediately: their developers’ time is not free, delays in feature delivery reduce income, etc.

Keep them busy

There can also be “managerial” reasons like “We have a large engineering team, so let’s keep them busy” or “homegrown solutions always have more quality than the ones from unknown authors.” But here’s the kicker: developer time is seriously expensive.

Let’s estimate all actual costs of in-house development. It not only includes “pure” finances like building and maintaining custom software (and updates, debugging, and new feature requests!) but also risks of a “bus factor,” and missed opportunities for innovation (because OSS projects often boast worldwide contributors).

You can generally predict the costs of bringing the Open Source into your project (well, in most cases). Internal projects? They often bloat budgets and stretch deadlines, sometimes by two or three times. We’ve all seen it happen.

Development pitfalls are often unpredictable, ranging from legacy code issues to expertise gaps within the team.

What Open Source can offer

In Open Source, you have existing frameworks, community support, and documentation. Previous users are sharing their use cases, which can include yours exactly.

The Open Source community is a real power because it can inspire the generation of various ideas that would not pop into the mind of one person.

When we created PostCSS, one of Evil Martians’ most popular products, used by industry leaders, we did not even think about many solutions like RTLCSS or Stylelint that are now a part of the OSS ecosystem and extremely popular. No, without them, we would not have been able to create any ecosystem at all.

So, choose wisely!