Open source software has been around for decades. Open source is free to use, and the code is generally open for the world to modify. It's often overlooked as a distinct strategy for accelerating a SaaS product's time to market.
Most software is built using some amount of open source software. Often times it's just a matter of happenstance--maybe a developer used something open source and no one even realized it. But, there's value in being proactive about your open source strategy.
Open source software can be a huge advantage when building your SaaS product, and this article we'll discuss what that could mean for you.
It's important to acknowledge the ways open source software can be used to help a team that is buiilding a SaaS application. There are a few ways you can approach open source, and they aren't mutually exclusive.
Your engineering team should regularly seek to use open source libraries or frameworks. These days this is generally considered a best practice, with few potential exceptions. In fact, your engineering team is probably already doing this!
An open source library is a piece of software (some code) that performs a set of related actions that may be required within the context of a broader application. They aren't really standalone products an end user could make sense of, but they offer buttoned up ways to solve common developer problems.
Examples are endless, but some easy ones to think about include:
These are things that are common needs for a software engineering team, but writing the logic from scratch is just impractical. Instead, you can simply plug in one of these open source libraries to help.
Open source frameworks, while functionally similar, are helpful in slightly different ways. These offer foundational elements to speed up software development. They help you stand up APIs or build out complex user interfaces faster. They may help you process certain types of data more effectively. They may help you deploy software more often.
Using open source building blocks for your software product reduces the amount of code your team has to write. They focus on writing code that delivers your core value proposition, not the tedious, undifferentiating pieces of functionality.
You could take the open source concept even further by literally building a commercialized product on top of an existing open source product. With most open source licenses, this is totally fair game. (Disclaimer: Talk to your lawyer.)
While libraries and frameworks provide you building blocks for building software product, they aren't fully usable products on their own. However, many open source products that are fully useful on their own do exist.
If you find one that accomplishes most of what you intend to with your product, why not start building right on top of it? You may be able to avoid writing as much as 80 or 90% of your code based by doing so!
There's certainly a big "if" when it comes to finding one to build on, but if that's available to you, there are many advantages to doing so.
Shameless plug: we make heavy use of Open Integration Hub in this capacity.
Every dollar you spend on something that isn't building, operating, or marketing/selling your core value proposition is arguably a dollar wasted. This is something you have to pay even closer attention to if you've taken venture investment. Investors don't really like when you spend their money on things that aren't what you pitched them. Some of it's necessary, but you want to minimize it.
Maybe you've built your product mostly from scratch (other than using open source libraries, which YOU SHOULD BE DOING). If you come across larger roadmap items that don't fit into what your product is at its core, you could complement with an open source product.
For an example, let's say you are building a marketing automation platform that requires some amount of content creation and management functionality. You could build all of that from scratch, but you could also bolt on one of many different open source content management systems that already exist. Why reinvent the wheel for something that is adjacent to your core value proposition?
To what extent you embed the open source product within yours will vary by use case. But, again, try to find ways to not pay to build things that aren't representative of the core vision of your product. Open source products that you can bolt on might help you do that.
Certainly there are many ways you can use open source in your product, but you can also contribute to open source projects. You may even go as far as open sourcing pieces of what your team builds.
This allows you to be proactive and securing the advantages (see below) of using open source. It might take a little more work though, especially if you have to govern the project yourself. However, if your project is filling a gap that the community sees value in or you are contributing bug fixes and new features to existing projects, you're putting a lot of good out into the world.
This is a great way for your engineers to build their skills and to get their names out, and it's a great for your company to build some brand equity too.
There are a number of advantages to using open source software when building your SaaS product. Here are a few to consider...
When done with a clear eye and experienced engineers, using open source software generally speeds up delivery of software features. Your team writes far fewer lines of code, which also means they have to test and maintain fewer lines of code.
Faster delivery means accelerating your revenue opportunity. It also helps you to keep your engineering team budget down, because you get far more out of fewer engineers than you otherwise would. Engineers tend to be expensive team members, so this is a big deal.
Most importantly, faster features means you deliver value to your customers sooner. You have more opporunity to deliver reliable features to them too--not just hacked together MVP features. At the end of the day, this is typically what your customers want from you above all else.
By adopting open source software in your product, you aren't just writing fewer lines of code. To some extent, you're extending your team with the communities that build and maintain those open source projects. But, they aren't on your payroll!
Let's say 50% of your code base is actually inside of open source libraries and frameworks that you've used. Likely all of those open source libraries are being maintained, updated, and bugs are being fixed by some group of people around the world.
That means you've got people that you don't have to pay or manage helping to maintain 50% of your code base!
Now, this is certainly not the same thing as hiring an engineer. These are typically strangers, even anonymous or psuedononymous strangers. You also have no idea to what extent they'll break or abandon the library. But, nowadays the practices for open source project management are fairly well established, and some reasonable due dilligence will mitigate these risks well.
When done well, using open source means enlisting an army of passionate engineers to help you with aspects of your product. It's a huge advantage.
Using and participating in open source projects aligns you with other people in the world that have like problems, work on like applications, and may be quite like you. This participation will help you find and work with new partners and possibly even competitors.
Using open source software is a way to immerse your team and their expertise in the ecosystems in which you're present. This is useful for recruiting, marketing, and general awareness of who you are and what you do.
All of this is especially true if your product is highly technical and/or you sell to engineering personas.
Engineers don't just like working with open source software. They kind of expect it--at least to some extent.
However, many of the best engineers see a lot of value in working on teams that fully embrace the principles of open source and who use and contribute to open source projects. This can be a big advantage when it comes to attracting and retaining engineers--something that is increasinly difficult to do.
Much like how artists maintain portfolios of their work, engineers tend to keep a record of the software they've contributed to. It helps them demonstrate their abilities and shows that they make the effort to expand their skills. They typically can't share the internal proprietary software they work on inside companies, so contributing to open source projects scratches that itch.
Open source software communities are just that--communities. Engineers, like anyone, like to be part of a community. If you make that part of their daily work, and not just their side hustle, you'll tend to attract the better engineers on the market.
Capital efficiency is a term that describes how much value a company creates for the dollars invested in it. You can almost think of iit like return on investment (ROI). This is important to investors because capital efficient businesses are generally better stewards of an investors' money. They also tend to be fundamentally stronger businesses.
Using open source software in your SaaS product means you deliver more value in less time with fewer dollars. It means you expand the team (sort of) beyond your payroll. It means you build in innovation that was developed outside of your company.
All of these things contribute positively to the capital efficiency of a business. While investors usually won't care about the nitty gritty details of what open source projects or why, they'll like that their capital goes farther.
Using open source software is not without risk. You still need to approach it responsibly, so that you can take advantage without adding pain elsewhere. Here's what to look out for:
If you keep these cautions in mind, you'll be set to successfully use open source software to make your product better and to deliver value to your customers faster.