Unmasking the Imposters: How to Spot and Avoid ‘Fake’ Open Source Software

In the landscape of open source software, unmasking the imposters is an ongoing battle.

By remaining vigilant, demanding transparency, and cultivating a culture of scrutiny, we can protect the integrity of open-source projects and maintain the trust bestowed upon this community.

Open source software has become the norm in nearly every industry. From Android phones and smart doorbells, to WordPress websites and Java applications, it’s hard to use any form of technology that isn’t in some way powered by open source.

And given how it allows companies to be more innovative, agile, and flexible, at a lower cost – it’s easy to see why. The vast repository of shared code, libraries, and frameworks enables developers to stand on each other’s shoulders to prototype, iterate, and create at speed. Modularity means this can be achieved while keeping precisely aligned with specific business and customer needs.

While open source can have incredible advantages, it’s important that businesses remain clear-eyed about the options available to them. Not all open source is created equal, and companies must know how to identify imposters or risk missing out on its transformative potential.

Understanding ‘fake’ open source

Licensing conditions are the litmus test for legitimate open source. ‘Real’ open-source software will have its licenses approved by the Open-Source Initiative (OSI), whereas ‘fake’ open source will not. The latter will be captive, and won’t enjoy the benefits of OSI approval, which guarantees that software can be freely used, modified, and shared.

However, some database vendors no longer use OSI-approved open source database software licenses for their core projects and instead have resorted to creating their own licenses. This poses an issue as often developers don’t want to take the chance on a proprietary platform that could potentially be scrapped in the future. With open source database software, the code is fully accessible, so even if the primary vendor shuts down, the code is still available for another group to pick up and extend.

The dangers of vendor lock-in

Although it may be possible to inspect the source in software with non-OSI licenses, they remain only source-available, not truly open source. Users have limited rights to use, share, modify, or even compile the code. Companies that adopt captive open-source software are thus susceptible to vendor lock-in. They not only run the risk of their chosen vendor controlling license costs, but also that the vendor may restrict features such as advanced security and scalability to select users who are willing to pay the price.

What’s more, these features may disappear should the vendor go out of business. Crucially, enterprises then lose out on the benefits of community support that comes with true open source, since only one commercial entity is controlling and contributing to the whole project.

True open-source projects, such as Linux or PostgreSQL (also known as Postgres), create a thriving environment for developers to flourish. Being a true example of open source means that if a database vendor building on Postgres went bankrupt, Postgres would continue unaffected. More than 140 companies contributed to the latest version of Postgres. As such, enterprises stand to benefit greatly from a large talent pool, lower costs than proprietary software, and no risk of vendor lock-in.

Spotting fake open source: A checklist

Companies must be able to spot the signs of captive open-source projects, so they don’t waste their time and resources on software that simply doesn’t give them the flexibility and benefits they need.

  1. Is the software license OSI-certified? This is the easiest way to discern whether an open-source project is genuine. Without OSI standards, reconsider or proceed with caution.
  2. Is the project community driven? Many of the benefits of open source come from vibrant collaboration. Do your due diligence and choose software that is backed by a robust community, not driven by a single company. It’s important to be wary of Postgres look-alikes – they’re often years behind in innovation because they’re owned and operated by a single company.
  3. What’s in the project’s release notes? There should be many—we’re talking dozens—of contributing companies mentioned and referenced, indicating a vibrant, independent community behind the project. Look at which companies and developers are contributing to the project: do you know any of them? And importantly, do you believe in them? If in doubt, it’s wise to go with reputable providers to avoid business discontinuity that may come from departures on a fringe project.
  4. What’s the rate of innovation? How often are new releases and features coming out? Regular updates are a good indicator of an innovative project that is constantly undergoing improvement and is being fed regular feedback from users.

Open source has transformed the world of software development and unlocked new opportunities. Businesses that are wary of the pitfalls of captive open source will reap the rewards of true open-source software. By channeling the collective intelligence, inspections, and influence of a global community, open source will propel businesses forward to meet fast-moving challenges in a wide array of industries.

About the Author

Marc Linster is Chief Technology Officer at EnterpriseDB. EDB provides enterprise-class software and services that enable businesses and governments to harness the full power of Postgres, the world’s leading open-source database. With offices worldwide, EDB serves more than 1,500 customers, including leading financial services, government, media and communications and information technology organizations. As one of the leading contributors to the vibrant and fast-growing Postgres community, EDB is committed to driving technology innovation.

Featured image: ©ZinetroN