How to build a business around an open source project?
How do I make the case to my company that this is a worthwhile investment? I'm curious in particular about the open source piece (I know that getting traction with an app is not easy but that's a separate discussion). What if we release the app and it takes off, but then some folks decide they don't want to pay and they set up their own instance?
I understand that there are real costs involved in supporting and maintaining a web app. But support and maintenance are different than funding new feature development, and this is what I'm curious about. Feature dev costs a lot of money. We are not interested in rent-seeking (earning more than the cost of the services we provide plus a modest profit), but we don't want to get undercut and lose our shirt either.
Let's say it legitimately costs $1k/month to just keep the app running and answer customer questions. Then let's say we need to spend $5k/month on feature dev. If we charge our users enough to cover the $1k + $5k + a modest profit, what's to stop someone else from setting up their own instance (open source!), charging just enough to cover the $1k in support costs, and simply slurping up every new release our people push to master?
Is this why folks like GitLab are "open core", but keep certain feature sets proprietary?
How do folks like Discourse, who are totally open source, make it work? In fact I see that there is discoursehosting.com which sells instances starting at $20/mo while Discourse themselves charge $100/mo. Why does anyone pay the $100? I am baffled.
Thanks for the discussion!
6 comments
[ 3.3 ms ] story [ 22.6 ms ] threadBy helping them to understand how all of the following will work: * User acquisition * Ongoing costs * "fit" with the larger business * Making lots of money
> what's to stop someone else from...
The incredible pain of building, iterating and growing a real business. Unless you are spectacularly successful, so much so that your success is visible to lots of people, no one is going to bother. If you are so successful that someone copies you, you can tackle that very fortunate problem at that point. The chances of getting to that point are very low.
> Why does anyone pay the $100? I am baffled.
Because the company that creates the software, writes blog posts, speaks at conferences, does the marketing for the product and leads thought leadership has earned customer trust. Trust that they know the software, understand how important it is to your business and can be relied upon.
That's one of the best things that could happen, because you'll have very different sets of people using your application in what would seem to be very twisted ways (different hardware, different architecture, different needs). These people will probably hit issues, find bugs and identify improvements: If you can get that feedback you will be in a good position to make your paid (hosted?) offerings even better.
You see these people as potential threats or detractors to your business, but they might be quite the opposite. A project that's going through that would be Wordpress and they seem to be doing quite well.
> In fact I see that there is discoursehosting.com which sells instances starting at $20/mo while Discourse themselves charge $100/mo. Why does anyone pay the $100?
If it was me, it would be one reason: Support. discoursehosting.com might not have the skills to deploy code fixes when the shit really goes down (Disclaimer: I don't know, this is just hypothetical, I'm sure they're a bunch of very clever and knowledgeable people). If I could pay someone $100/mo for peace of mind I would do it in a breeze, it's less than the hourly rate of many freelance coders in the US and they probably need several hours to get familiar with Discourse's code before helping me with a fix.
https://www.patreon.com/evanyou
And Taylor Otwell with Laravel. He makes money off Laravel Forge, Envoyer which are SaaS and a Paid Package Spark.
laravel.com
These are frameworks which sounds a little different from what you are working on.
You mentioned your company, be careful about who owns the IP/Code. Are you working on this at work, review your contract.
You're talking about answering customer questions. If this is a web app providing value and you are providing support you should be charging for this. Even if the code is MIT, keep in mind a competitor can take your code and create their own SaaS.
You could keep the basics of the app open source and keep the billing, admin etc closed source that you are running with the app, so if people want to setup their own or contribute to the base code they can but you have a larger barrier to entry to someone just duplicating your app and competing with you.
Good luck with your open source app.
- https://www.indiehackers.com/businesses/action-pages
- https://www.indiehackers.com/businesses/amon
- https://www.indiehackers.com/businesses/smg-music-display
One thing to keep in mind is that, as a developer, you feel very comfortable dealing with code and writing things on your own. This tremendously devalues having other people host/setup/maintain your software in your mind. However, most people are not programmers. They look at code the same way you might look at tax law -- you just want to hire some decent attorneys who you're confident will do the job well and be done with it. That's why people will pay more for a trustworthy name.
How to build a business around software (involving puppetry)?
Would it make sense for an outsider looking in to suggest that maybe you should put that whole puppetry bit on the back burner and instead double down on the Software part, since that's a much easier road?
Maybe after the Software and Business parts are ticking away nicely, you could start adding some puppetry in on the fringes, or as a separate thing even. But maybe not start off right away mixing the two.
Because that seems a lot more difficult.
A similar way might work for your web application, by making two different products, each with their own audience.
My tip as founder: start testing the viability of your product/business first. Consider the reasons why people would or would not pay. Ask people in your field who might use it and if they would be willing to pay (and how much).