Why Having Your Employees Work on Open Source is Good for Sustainability

There’s no easy answer on the best way to fund and sustain open source projects. Open source purists and companies often disagree on how to incentivize contributors and keep projects alive. Some communities like OpenSSL are primarily volunteer-driven, while others like Drupal consist of a mix of volunteer and corporate-sponsored contributions. Potentially the most controversial category is the growing number of open source projects (e.g. MongoDB) that rely on the contributions of a single company. 

Our ProGuard open source project falls under the corporate-sponsored category – it’s primarily operated by Guardsquare. Our business was founded based on the ProGuard app optimizer, which helped prove the market for more advanced mobile application security solutions including DexGuard and iXGuard. Our company’s employees are paid to maintain both ProGuard and ProGuard Playground, as well as run the Guardsquare Community (more on that later).

Corporate-sponsored open source projects like ProGuard are a great model for long-term sustainability. Here’s why.

Avoiding the ‘Tragedy of the Commons’

One of the biggest concerns in open source is that a small group of (largely unpaid) contributors are responsible for maintaining software – fixing bugs, handling feature requests, reviewing code, committing code, and more. That’s a big job for someone who usually has a day job, too. Relying on unpaid maintainers can result in contributor burnout and lead to some serious, large-scale issues such as the infamous Heartbleed bug in OpenSSL. 

Sometimes, open source community members think someone else will take care of an issue (so they don’t have to, which results in no one fixing it), a theory otherwise known as ‘tragedy of the commons.’ Another common issue is the ‘free-rider problem,’ where a person or company benefits from open source, yet never contributes. These two concepts are closely intertwined.

When a project is primarily maintained by a corporation, like ProGuard, it’s easier to assign ownership to issues and maintain the level of contributions necessary to sustain a community. That means more than just contributing code; it includes documentation, community support, and more. Some promising efforts, like Tidelift and GitHub sponsors have cropped up to pay volunteer open source maintainers, but a company-driven project can help create the infrastructure needed to sustain an open source project for the long haul. 

Maintaining Open Source Project Longevity

There’s always a delicate balance between paying employees to work on open source projects and revenue-generating products. However, when open source is at the core of your business, it’s a win-win to pay employees to do both. Case in point: we’ve sustained the ProGuard open source community for nearly 20 years, and built security solutions with open source at their core. In many cases, open source has served as the customer’s freemium entry point to our more robust security technologies like DexGuard. The freemium model is a major motivation for corporate-sponsored open source projects. As MongoDB’s CEO Dev Ittycheria recently said to TechRepublic, “We open sourced as a freemium strategy; to drive adoption." 

In this process, there’s a lot of mutual learning shared between our open source and proprietary software developers. We’ve done our best to extend this learning to the community through resources like ProGuard Playground for keep rules and the Guardsquare Community for troubleshooting and support. We still accept and welcome outside contributions to ProGuard, and our community is much better for it. We all learn from each other, which helps improve the community. This dynamic is a major reason for ProGuard’s success over the past two decades.

Paid Maintainers = Well-Built Software

This idea may seem obvious, but paid maintainers make quality open source software. We understand that the responsibility rests on us to advance ProGuard, and as a result are constantly acting on ways to make it better. 

Even so, for ProGuard, there’s a strong ecosystem of partners and other developers who share code on GitHub, as well as best-practices via the Guardsquare Community. For example, the Gradle Enterprise team recently contributed to the ProGuard Gradle plugin that makes it much easier to use Gradle with ProGuard. These contributions improve ProGuard’s functionality, but many of the core features are still developed within Guardsquare.

In addition, operating ProGuard within Guardsquare serves as an assurance that we’ll have enough eyes on potential bugs or security flaws. As  Linus’ Law says: “Given enough eyeballs, all bugs become shallow.” 

While there’s no one way to run an open source project, we’ve found that corporate sponsorship of ProGuard isn’t just good for the community, it’s good for business. We hope that we see more open source projects follow this operational model to experience their own path to long-term success.