Challenges to Expect When Open Sourcing your SaaS Business

Moving your SaaS business to an open source model is challenging, but the ROI could be worth the effort. Here's what you need to know.

In my previous article, I walked through scenarios to help you determine whether to open source your SaaS solution, and discussed the cost-benefit analysis that goes along with this decision. From an open source point of view, there's no point in just chucking code over the wall, slapping on an open source license, and calling it a day. You want to create an inviting community where people want to collaborate and spend time-even socialize!-with you.

John Mark Walker Chucking code over the wall accomplishes nothing, besides giving others insight into how you do things. Although that may be interesting and beneficial for them, you don't get much benefit unless you create the pathways of collaboration and communication that unlock a thriving community. Thus, you have an inherent interest in doing this The Right Way™.

I have good news and bad news for you:

• First, the bad news: This is really hard! And you should have done this from the beginning.
• Now, the good news: It is rewarding, and you get back a lot more than you put in (I have data that proves this).

One of the biggest problems with open sourcing an entire software stack engineered for SaaS is that dev teams are accustomed to working from a single code repository. In fact, they often laugh at our enterprise software colleagues with their multiple branches scattered hither and yon. One of my biggest problems with DevOps philosophers is that they usually assume that this single branch or repo is all you'll ever need. And if you're using tiered branches from a parent repo, that's considered antithetical to agile development.

Suggesting that you can simply live off of a single code repository or branch sounds appealing, but this can be inherently problematic for a collaboratively developed piece of software. Here's the supply chain of a typical SaaS project:

There are two primary problems with the above diagram:

1. Core code from upstream open source projects is forked and forgotten, then carried forward and maintained with the rest of the code until a painful rebased is required in the future. The reason it's forked is because…
2. A SaaS project never needs to worry about managing incoming code from third-party sources. The whole process is designed to take from the outside, automated on the inside, never to be merged upstream. It's designed to be used and thrown away, not optimized for ongoing management and maintenance. So the dev team is shocked when they realize that collaborative projects require managing incoming ideas-and code.

The inherent conflict between your core team and incoming contributors who don't necessarily have the same use case can be painful. Those third parties want to have shared ownership and stewardship, which isn't always in keeping with the use cases of the project originators. The core team just wants their solution to work and would rather not bother with incoming contributions, even though it's necessary to overcome the resource constraint issues I raised earlier. The only real solution that allows a SaaS project to move beyond its original team is this:

This is a healthier example of an engineering process made for open source collaboration. To ease the conflict between developers, the primary source repo is split into upstream and downstream versions. Upstream is where everyone contributes their code and ideas. It's where the base innovation happens. The downstream code is where your team optimizes what they pull down (the 80-90% referred to earlier) from upstream, and then add whatever is needed that's specific to your specific use case or implementation (the 10-20%). And because this is now a functional community, there are additional resources to help keep your incoming upstream components on the left up to date. It takes time to get to this point, but if you're willing to put in the effort, there is a payoff.

What is the expected ROI?

Am I providing ammunition for my competitors to put me out of business? The answer is usually no, although it would be wrong to suggest it's never true. Considering the amount of effort required to transform SaaS into open source, the decision to go open source should not be taken lightly. This leads to the question of what you can expect to get in return for this sacrifice in productivity. Going back to the supply chain diagrams above, the implication is that your team will be able to collaborate with outside teams on core code, resulting in much greater efficiency. This is not just an academic or theoretical exercise; we have data to back it up. As I described on the OSEN blog, the World Bank conducted a study of its investment into the Geonode project, determining that the ROI on its engineering investment was 200%, which is significant.

This means that whoever is leading a SaaS engineering team will need to do the following calculation: How much time will it take for the gains in efficiency to eclipse the amount it costs to re-architect a given project or set of projects?

Part of that calculation must include available resources to perform this work. For example, if you're able to hire engineers en masse and have the resources of a Google, Facebook, or Amazon, you're probably going to be less cost-conscious, and the idea of becoming more efficient on the engineering front is probably not so compelling. On the other hand, if you're facing diminishing or flat engineering resources, and your competitor has more resources at the ready, going the open source route could allow you to be more innovative and to focus on adding higher value in a competitive market.

Cannibalization and losing the competitive edge

Finally, we come to the question most often asked when discussing this idea: Am I providing ammunition for my competitors to put me out of business? The answer is usually no, although it would be wrong to suggest it's never true. However, if you're a SaaS business, your primary competitor is most likely not using your solution and would be highly unlikely to gravitate to your solution even if they had the chance. Your competitor, like you, has built into its solution a series of decisions, custom configurations, and workflows designed to work specifically for the purpose of running its business. The chance that your software could be dropped into their solution without skipping a beat approaches zero. The idea of re-engineering a solution to fit a competitors software platform is so slim that I can't think of an instance of it ever happening, whether we're talking about proprietary on-premises software or a SaaS solution. This risk was already low for on-premises software, and it's lower still for SaaS.

While this risk is non-zero, it must be balanced against the risk of not open sourcing your software. The risk of not open sourcing your software components includes never achieving the velocity of innovation required to add enough value to reach your goals. Which risk is more likely? If you have nearly unlimited resources, then your risk profile skews in the direction of not providing potential ammunition for your competitors. If, however, you face limited resources in your future, consider the possibility that the risk of not open sourcing your software is greater than the risk of open sourcing it.

Conclusion

Although the effort is significant and the decision is not to be taken lightly, dedicating the time and effort towards open sourcing your SaaS solutions is likely to provide a significant return on your investment. The amount of time that passes before you see that ROI depends on a variety of factors:

1. How monolithic your software base is
2. How much code refactoring is required to make it generally reusable
3. How much upstream code can be substituted for your current code base
4. How well your team adapts to an open governance model
5. How quickly you're able to gain traction with your open source efforts
6. How many of your engineers participate in upstream communities

Eventually, the benefits overtake the costs. The key is to be patient as your engineers learn how to collaborate in open source communities in a way that produces value that's greater than the sum of its parts.

You'll find that most SaaS shops don't do this-yet. This is in spite of the fact that the majority of SaaS code is unremarkable. There are multiple reasons for this, but I think the biggest is that investors in these ventures have been sold on the idea that SaaS-based businesses are a great way to keep all the intellectual property and not share it, even though they use a lot of open source code in the process.

Unfortunately, this puts many of these shops at a disadvantage: Over time, unless they have the revenue of Google, Facebook, or Amazon, their business growth will quickly outstrip the ability of their engineers to keep pace. It's at this point that many SaaS businesses hit the wall and are sold for pennies or simply vanish.

Unless you have the resources of Facebook or Google, design your engineering workflow for collaboration and reap the rewards. If you start out that way, you won't have to face the messy task of re-architecting your engineering process.

About the author

John Mark Walker is the community lead for Open edX, the founder of the Open Source Entrepreneur Network (OSEN), and the author of Building a Business on Open Source. He has led many open source community efforts, including ManageIQ,...More about me