At All Things Open, a conference about new open-source technologies and pertinent topics held annually in Raleigh, North Carolina, Syncfusion’s VP of Business Development Marissa Keller Outten attended the session, “Managing the project-product tug of war.” The session was presented by Emily Omier, an independent open-source software consultant. Here are some of Outten’s takeaways:
The concepts of product and project often blend together, but according to Omier, product is what the company sells to generate revenue, and project is the open-source project that is usually related to the product.
The core challenge of open source in commercial software companies
Tension exists between running a commercial software company and offering some of your software as open source. Just because your open-source software is freely available to use doesn’t mean that it is free to create, update, maintain, or improve. Companies must generate revenue to keep their doors open and to keep up with payroll for the engineering teams.
Open-source software is free in the sense that anyone is free to access the code and contribute to it. It’s not free as in free to produce.
So, the challenge lies in how to keep revenue flowing while also consistently investing time and resources into the open-source project.
Solving the core challenge
Various solutions to this challenge are present in the industry. Some companies make all their projects open-source software, and their services become their product. Red Hat is a great example of this. Other organizations release a subset of their product as open source and offer a premium version that includes high-value features people will pay for as their product.
Regardless of the approach, it is important to clearly communicate, internally and externally, why your organization is investing in open-source projects. You must have a plan for financial sustainability as part of your project strategy.
Failing to rise to the challenge
What does failure look like? Failure for commercial software companies is easy to define—they don’t have enough revenue and must close their company. Failure for an open-source project is less clearly defined. Does it mean that the project was abandoned? The best metric for failure could be the psychological aspect: do the people involved think it’s a failure?
Although there are many models for running an organization that offers both commercial products and open-source projects, unfortunately, the tension cannot always be resolved. In such cases, companies may abandon the open-source license of their project. If they do so, it is vital that they communicate everything they tried and why they can’t maintain their open-source plans. If this is delivered clearly, they will have a much less negative reaction from the open-source community.
To learn more about this topic, visit Emily Omier’s website or check out her podcast, “The Business of Open Source.”
