The decision to open source code requires a fair bit of planning if you want to do it right, especially when it comes to user support and documentation. In the case of SaaS, the required planning is different, although it shares some factors with any open source effort. In my series, How to Make Money from Open Source Platforms, I focused on software that exists solely to be deployed on a computer, whether on a local machine, in a data center, or in a cloud platform (yes, I know the last two are redundant).
There was a simple reason for this focus: It was what I knew. In my career, I have always worked with software, of commercial and community origins, to be installed somewhere. Now I work directly with engineers who take software designed to work solely on their website and with their particular infrastructure, automation, and orchestration. The fact they have been able to take this software and offer it to others in a way that is not only usable but can actually power other businesses is a testament to their commitment to an open source world.
This article attempts to summarize their experience and point out lessons to draw from it. I'll also try to identify how open source efforts relate to business and product strategy for SaaS models.
Software engineering is not all the same
As I've mentioned numerous times, the source code is essentially worthless. Sure, it's the basis on which everything is built, but without a way to manage it and automate the process to turn it into a working solution, it's not something I can charge money for. I can get millions of lines of code for free from projects and communities around the world, but turning any of it into a manageable solution would require a massive effort.
Most open source projects emphasize usability. This is true whether the project is produced by an upstream community or a vendor that simply wants to get its software into more hands. In fact, this is the purpose of these software communities: To produce usable software that someone can deploy on a variety of platforms and operating systems of their choice.
Not so much with software engineered for a SaaS solution. In that case, the software was engineered for only one specific use case, in one specific environment: that of the SaaS solution it was designed for. In such cases, there is little thought devoted to other use cases, other environments or platforms, or even determining whether there is a general use case for the software produced.
This is perhaps the primary reason why, when software is open sourced by a SaaS provider, it is for a specific task that isn’t the primary business of the software maker. Netflix, for example, can open source a project for application clustering that is fairly discreet from its primary software stack and operations. Facebook can open source React, but it won't open source a "Facebook enterprise" solution that mimics its web experience. That would not only potentially erode its primary value proposition, but it would also be incredibly difficult to support, manage, and maintain.
This brings me to the obvious question: Should a SaaS provider open source its primary platform, and if so, what is the best way to do it?
My thinking has evolved over the years. I previously believed that open sourcing a platform would be much easier for a SaaS business because its primary value was in the efficient operation of its business, which is very difficult to copy. The thinking was that nobody else can run a software stack from a SaaS provider as efficiently as the originator of the technology. This is especially true when you realize that the source code of these solutions is only a small part of the operations and management of that solution. The rest of a SaaS solution involves a number of custom-built configuration management modules, integrations with various management and security frameworks, and a wealth of digital bailing wire that makes a reliable SaaS experience possible.
The other reason I felt that open source was viable for SaaS is that the open source software can be easily separated from the commercial solution. In a traditional enterprise software world, both the open source and commercial solutions are deployed on a platform owned by the operator of the software. This leads to an endless cycle of vacillating between "we’ve open sourced too much" and "we haven’t open sourced enough." Because both of these are deployed on premises on the platforms of the users' choosing, there is a visceral fear that end users will get plenty of value from the free stuff without feeling the need to pay for it.
In a SaaS world, only the open source solution would be deployed on a platform owned by someone outside of the software's originator. The commercial solution, the one that runs solely on a single website, can by definition be deployed only on the highly customized platforms owned by the software's originator. I assumed this meant that it was only a matter of time before the floodgates opened, just as they did with enterprise software, once the economic trends tilted in the open source direction. But in the SaaS world, those floodgates have not yet opened, and now I think I know why.
Should SaaS be open sourced?
This is not an easy question to answer. The answer, unsatisfying though it may be, depends on the ultimate goals of your project. This requires a thorough evaluation of your particular software platforms and frameworks:
- What, from your solution, is applicable to those on the outside?
- Is it the entire solution, or a portion of the solution?
- How much effort is required to support an honest open source effort?
- And finally, does releasing this as open source jeopardize some portion of your core business?
I include the last question only because I know it's the one everyone will ask, but to be candid, it is the least interesting of the three.
To address this question adequately, let's go back to my favorite visualization tool: the software supply chain.
The basics of a software supply chain funnel are in the diagram above, flowing from left to right. Start with the raw bits that make up your software solution, and then add customization, integration, and other configuration and management steps as you flow to the right. Ultimately, you end up on the right side of the funnel with a "finished" product. Of course, as everyone knows, you are never finished in the world of SaaS. Imperfect though that may be, as long as you understand that this is a continuous process, this diagram helps you understand how to optimize your process for efficiency.
In the above diagram, I superimposed representative shapes of various pieces that make up the supply chain. On the left are raw bits you use to build your solution, such as the Linux kernel, Kubernetes, etc. A lot of the integration work is done for you, as I doubt you’ll build a Linux distribution from scratch (although you might). In this case, you can substitute one of the platforms you build on, such as Ubuntu, Debian, CentOS, Fedora, OpenSUSE, Alpine, or some other flavor. As you go from left to right, draw an imaginary dotted line between the middle piece (which I’ll get to soon) and the finished product on the left.
Everything to the left of the dotted line should be community-managed code. Everything to the right should be code maintained by your internal teams. Everything to the right is technical debt. Everything to the left is not owned by you. Ideally, stuff on the left will make up 80-90% of the code you use to build your solution. Stuff on the right should consist of the remaining 10-20%. Note that even though the arrows are pointing in one direction, this does not mean that your team never fixes bugs or contributes code on the left side of the line. In fact, the above scenario works best when they do. Also, just because software is community-managed doesn’t mean your team isn't making significant contributions to it. Again, it's usually best when they do.
This is where the fun starts, with a simple question: How much of your current solution could you legitimately push to the left of the line, so that your team is maintaining only 20% or less of the code base?
The answer is not always straightforward. Perhaps your initial thought is that less than 50% of your code has enough general applicability to be maintained by an outside community. In practice, I find that if you break up your total SaaS solution into separate components, you'll be able to more easily dedicate a higher percentage to be community-maintained. The answer is generally one of two things: Either you haven't broken your solution into enough components, or your solution is so specialized and unique that it simply isn't relevant to the outside world. The vast majority of the time, it's the former.
It's a lot of work
In most cases, the software that makes up a SaaS solution was never meant to be used, or even viewed, outside of the environment in which it was created. In contrast, an open source project springs from the creators' minds with the intent of being shared and used by those outside the original project. This means that the workflow for development in SaaS is completely different and unsuited to the task of building an open source community.
In many ways, the predicament I describe is similar to that of a traditional proprietary solution that developers are attempting to turn into an open source project. Unless you start from the beginning as an open source project, the task of transforming it from proprietary to open source requires a lot of workflow changes on the part of the primary development team, resulting in great frustration for the developers and, at least temporarily, slower development speeds. This transition period is judged to be too much to bear with too little to be gained in return, which is why many of these efforts fail or only partially succeed.
There’s also the question of whether the components built by your team are the ones you should use. Can they be replaced by others produced by open source communities outside of your organization? Perhaps your team used some software projects as the basis for your solution, but then they decided to fork it and build on those forks, thus saddling you with the technical debt of maintaining them in perpetuity. You would have to rebase these forks on the upstream code bases and then add code to those upstream communities. This is no small effort, especially if none of the core contributors to said projects are on your payroll and your team has no credibility in those communities.
Between the architectural changes required to break up any SaaS solution into a workable set of components and the overall effort required to build communities around these components to reduce technical debt, you can easily see why this is the road less taken. Adding the complexity of rebasing forks to their respective upstream code bases increases the chance that your team will be less productive in the near term.
In Part 2, I’ll show you how to create open source magic with your SaaS code.
1 Comment