Why/How Should You Treat Your Open-Source Project As a Business
Your open-source project is no different from a startup. Consider it as one & ensure its success. Here’s a trivial framework to build upon.
The early 2000s witnessed the rise of the software revolution. With it came the idea of “Free & Open-Source Software (FOSS)” after Richard Stallman initiated his Free Software Movement. And in 2020, Open-Source Software is almost the new standard within the software industry.  So much so that recruiters often expect new budding software developers to “contribute to” open-source software projects. Or other times, an open-source software (not necessarily free though) is chosen over a proprietary one by the consumers simply due to the quality assurance & trust factor. But as tech giants like Microsoft, Facebook, Google, etc, are also actively participating in the open-source community, how does your open-source venture compete against them?
The rest of the article will attempt at answering that exact question.
The Initial User Base Will Probably Be Developers, But You Should Diversify
Most developers share their knowledge openly on one platform or the other. So it’s not surprising for developers to share their creations for anyone to access, use, develop further or whatever else they want with it. But this article isn’t just about creating & sharing your code for the community. More specifically, this article attempts at shining light on businesses revolving around an open-source product. In other words, the source code of the product is readily available for anyone to look into, copy, recreate it, etc.
With that in mind, how do you run a thriving business around it, is a question not many developers are aware of. Why? Because, as I mentioned just a while ago, developers tend to share their knowledge without expecting anything in return.
To reiterate on the statement, let’s tread down the memory lane. For those of you who are old enough to experience the 90s era software industry, you must be well aware of the times when consumer-grade software was considered totally proprietary. Giving away the source code of your software to the consumers was unheard of, let alone open-sourcing it to the public. The practice of sharing source code along with the software was an activity popular among academicians, government agencies & perhaps some corporate officials. The effect of the trend still persists to this day, at least to an extent. Although, it appears to be changing as more & more businesses are starting to revolve around open-source products.
Examples of such startups/businesses are: MindsDB, Gatsby, Inc with their GatsbyJs & Gatsby Cloud or even Ghost CMS by the Ghost Foundation. Obviously there are countless more like them, but these are the one which started as recently as 2019.
But the caveat with these startups is: They all provide an open-source software, quality-checked & maintained by a team of in-house developers. But also provided hosting services to their clients. Clients who are not necessarily tech-savvy enough to build/host their requirements on their infrastructure.
Another example would be the case of the two very popular Operating Systems — Windows & the Linux-based distro, Ubuntu. Both Microsoft & Canonical provide customer support with their products, the difference is in the background of their customers. While Microsoft provides support primarily to non-technical individuals, Canonical serves their enterprise customers. All good & dandy, keep serving your niche group of customers & forget the rest, right?
Alas, in the long run businesses can’t focus on serving just one group of customers for eternity. Basic business 101, diversify as soon as you can. Going back to the Microsoft & Canonical example, even they’ve started to diversify only recently. While Microsoft has started to embrace open-source as well developer tools, Canonical is starting to streamline using their products for their non-tech user base.
Suffice to say, the philosophical idea behind the Free Software Movement might entice you, but your project risks going under sooner or later without a financial cushion. So remember while your product might be useful for the developers, initially, you need to think of a way to serve the rest of the market as well. The problem though, non-developers don’t give a flying damn about open-source. It’s just yet another fancy term for them.
So lesson one; build a niche product with the developers-first approach. Diversify from there on, gradually & eventually.
Existing Business Models, Adopt It (For Now) & Adapt (Later)
If you hadn’t realized it already, but I already gave you examples of existing business models around open-source software. If you guessed it, yeah, you are right Microsoft with their wide user base, it’s easier for them to delve into the community. And Microsoft open-source products ARE ACTUALLY GOOD without any doubt. Similar to Canonical’s model of serving their professional & enterprise-grade clients, Red Hat is in the same boat. With their Red Hat Enterprise Linux (RHEL) you can expect a battle-tested Linux distribution which, if breaks for some reason, you need not worry one bit. Because Red Hat will hand-hold you & your business with every little infrastructure details you need to set up RHEL properly. So just like Red Hat and/or Canonical, you could provide professional human resources for your clients.
Understandably, most open-source projects don’t really have the capital to start providing professional services from the get-go. So what’re some alternatives to it then? Ad revenue & corporate tie-ups are a thing lately among open-source project maintainers. For example, Read The Docs provides free CI/CD as well as hosting services for project documentations & they generate revenue by displaying small ad banners on project documentations. Or even better if you can build a partnership with more established businesses like Mozilla’s partnership with Google Search.
But by far the most sustainable model in my opinion would be to provide a SaaS or perhaps tiered services (a free tier & paid tier with additional features). The term “open-source” & “SaaS” appears to be for each other specifically. Matomo & Ghost are two perfect examples which are open-source, but provide their software as a service to their clients as well in case they need managed software. This way the project is open-source, you don’t necessarily need a lot of capital and/or human resources, neither do you’ve to rely on ads which can often be very intrusive. No one likes ads, let’s just face it.
Are they the only models around? Not really, but these are definitely the ones which are battle-tested & reliable enough. Will they, as they’re described in the article, word-to-word work for your projects? Perhaps, yes. There’s a good chance it’ll but in the long run you should definitely change & adapt as per the market demands.
So lesson two; stick to tried-and-tested business models for now. Startups & businesses touted as “disrupting the market” often fall the hardest when or if they ever do.
Be Professional. Period
I’ve been involved with the open-source community for a while now. And one thing I noticed is the lack of professionalism among some maintainers (not generalizing though). I mean, yeah, you shared your project, for free at that! The community is grateful for your contribution, really they are. And when a business needs support for something they can’t help themselves with your project, what’s with the patronizing behaviour?
This rather worrisome situation became more obvious after a recent patronizing disagreement related to a popular open-source web server project named Actix-web. I won’t be disclosing the names of those involved due to bash mob & bullying. But you can Google about it to know more.
Heck, even Python’s creator Guido van Rossum wasn’t safe from this toxic behaviour which is spreading within the community in recent times. Guido eventually resigned from his position as BDFL after years of handling constant nitpicking targeted at him.  In an email where he responds shows his clear sense of disappointment.
Now that PEP 572 is done, I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.
Guido is just of the many disappointed souls whose words have been heard, there are many whose voice of sadness have landed on deaf ears. It’s unfortunate to see how the community is only becoming more & more toxic as open-source projects are becoming popular. This sudden toxic outpouring, in my opinion, can be attributed to the superiority complex most maintainers feel in my opinion. The software industry is divided; at one end some developers go through Impostor Syndrome while the rest has a Superiority Complex.
Suffice to say, if you’re too proud to see through the meaning of building a relationship with your product’s user base, your project will not succeed to its full potential, ever. With that said, should you never feel proud of your creations? There’s nothing wrong to be proud of your creations. In fact, be proud of it, let that pride fuel your motivation to convince your customers to use the product. But pride shouldn’t be mistaken with toxicity.
Lesson three; Keep personal problems & opinions aside while dealing with your project. If needed take a break, you deserve it, maintaining an open-source project is no easy task.
Prioritize Financing Yourself First & Then the Project
As much as we developers would like to keep working on our open-source projects without worrying about finances, it’s just not feasible. We’ve to feed ourselves, often our families as well. Working & maintaining unpaid has been difficult, often resulting in projects being abandoned abruptly.
End-users of open-source software often take it for granted, this software will exist for eternity & will never break as it didn’t in the past. Myself included, thought about it the same way until I recently heard this recent podcast — Resolving Package Dependencies With New Version of Pip by Real Python.
In the podcast one of the guests made a Call-To-Action requesting to fund the development of the Pip project or if possible volunteer for maintenance. Apparently, their funding has run out & after January 2021, the project will be completely maintained by volunteer efforts.
It sounds pretty worrying to me if you ask. I mean pip is the de facto package management system available for the Python programming language. And it not being actively maintained by the official team anymore definitely should bother its users.
Similar to pip countless other developers are forced to abandon their projects regardless they want to do so or not. One primary reason behind it being, lack of a financial cushion.
Luckily, with the advent of GitHub Sponsors the situation is changing. Now the open-source project maintainers can afford to work on their projects full-time while being directly funded by the users. With GitHub’s system the developer needn’t even vocally request for funding anymore.
This raises a question though. By sponsoring the developer(s)/maintainer(s) directly, isn’t it a violation of the core ethics of the idea behind the Open-Source Software Movement?
In a way it is & is exactly why non-profit organizations like the Python Software Foundation, among few others doesn’t assign the role of a Core Developer to more than two individuals from the same company. But again, if you’ve read the article till here, you’re probably looking for ways to make a profit from open-source projects. So to be fair the philosophical ethics of the idea of the open-source movement doesn’t really apply to the project from a business perspective.
So lesson three; Don’t nail your feet to the ground by sticking to the core ideas of the open-source movement. In a hypothetical scenario, if that’s how it was, then Microsoft, Google, Facebook, etc wouldn’t have actively participated in the community. Be shameless in seeking funding for your project. There’s nothing wrong with it.
You decided to open-source your project to the community for anyone to download, use, recreate & develop further which is great! People are using your software & is growing in popularity each day. So you see a business opportunity in your project. Hence the entrepreneurial side of you decides to take the plunge to try & see if your project can be profitable which is great as well!
But now that the product already has a significant user base, you’ve no clue how to turn it into a business. You fear that charging your users out-of-nowhere for using the product might make them lose interest in it. And to be honest, it’s a possibility. But not if you can mould your business around the ideas described in this article. Bear in mind, obviously these are mere suggestions & not set in stone, so you’re free to adapt your business according to market demands.
So here’s a recap of the suggestions described above:
- Open-source projects are more predominant among developers & technically aware individuals. But you should diversify your user-base as soon as you can. Adapt your business and/or your product fit the needs of a non-tech individual as well.
- Existing business models as those employed by popular open-source project supporters like Red Hat & Canonical Ltd are battle-tested. Use them initially, only adapt as per the needs of your market & the user-base.
- Being an open-source project maintainer doesn’t make you an “elite software developer”. You’re no less than the regular 9–5 full-time developer working on legacy infrastructure. Act professional & keeps personal feelings aside.
- Work on setting up a financial cushion. An open-source project is no different from working on your startup.
So these are four suggestions you should keep in mind, no matter what for working on a business around your open-source project. While they aren’t set in stone but should definitely be treated as a starting point for any project.
 Katie Brigham, How open-source software became the new industry standard (2019), CNBC