The truth is that people who are fine operating and managing their own ElasticSearch/Postgres/Spark whatever cluster are not the people who will be buying the SaaS offering. Theres no point trying to convert those people, theyll convert themselves once they get tired of constantly upgrading and maintaining a non-differentiated piece of their business, or they’ll just be happy users who bring your tech stack to their next gig, where the buy vs self-host choice gets revisited.
The main problem is that many teams think they’re “that guy (or girl)” who can manage a complicated piece of infra as a small team and will be saving money. If you spend 10% of your time doing devops work, you spend 10% less time on your actual product (you might as well be binging netflix). A majority of these teams convert (IME) to a hosted offering once the right price and SLAs and DevExp are there. The only part of your sales pitch that matters to these teams is “this isnt worth your time to self host when we have a great offering thats cheaper and faster to get setup”. If you have a logo from a big co that has the talent to self host but are buying your product, then your work is done.
1. 10% of your time doing devops work isn't necessarily a waste - if 10% of that time is cheaper than enterprise offerings, then this is probably worth the resources, unless you are very short on talent.
2. You have an assumption laden in this comment that SaaS products eliminate the need for spending time on "devops work." It can greatly reduce that time, but IME even administrating a SaaS product can come with a ton work - look at EKS, a "managed" kubernetes cluster, but often requires a lot of kubernetes know-how to properly configure and maintain.
> 1. 10% of your time doing devops work isn't necessarily a waste - if 10% of that time is cheaper than enterprise offerings, then this is probably worth the resources, unless you are very short on talent.
That's not the right calculation for revenue-generating products (IME). The right calculation is: if your product got this 10% instead of you doing DevOps work, is the additional long-term revenue higher than the cost of the enterprise offering?
What is the X% of your product you're willing to outsource? What % of margin are you willing to give up for that capability? Because the hope/dream of every parasitic SaaS is to grow with their customers...
Having taken part in many build-vs-buy decisions, there are no easy answers. The overriding factors in most decision relate to the specifics of the business. Some very common reason for buy decisions:
- You don't actually know if this feature will be important long term
- You have many urgent needs, the opportunity cost of waiting for "build" to finish is too high
- Your company is, for various reasons, unable to attract and retain the kind of talent who could maintain a system of this complexity (I realize this sounds like "we're not willing to pay market reates", I promise it's more complicated than that)
Both your counterpoints are true, I didnt want to sprinkle the word “marginal cost” everywhere (marginal devops cost of buy vs self host). And ofc I agree, not all saas offerings are the same, EKS is fairly meh as far as setup and time savings.
Every discussion around subscribing to a SaaS vs. operating it is always reduced to costs on HN. There is another, more critical aspect to why we (and many others) operate their own infrastructure, run their own servers, operate their own Elasticsearch clusters: Keeping ownership of customer data for business continuity and compliance purposes.
You can enforce your own SLAs, manage your own downtime, avoid versions changing under your feet, avoid UI changes to critical apps... It is a cost, but it's also a necessary cost to provide the experience you want to deliver to your clients.
There will be companies who prefer to self host and those who don’t, and having an option of paid support or cloud hosted can go a long way especially when the open source project can set itself up as a first class plugin in the Microsoft cloud.
Many of not most companies are already on Microsoft and it ensures a good amount of support for open source so they don’t have to separate features into different tiers.
One of the more interesting open source setups was a product that was licensed both as open spruce and commercial, and the customer (often government or education) would have a policy of commercial only or open source only and they could support it both ways.
Do you mean that us-east-1 is a single data center? OTOH any DCs that comprise that region should be close enough together, and on ridiculously fast links.
Not having the amount of expertise or hours on hand to support it can be another. Shadow labour costs can add up pretty quick and some orgs like offsetting that to the vendor to not overload their people.
Another consideration is how much the tech aligns with your core business. Just because you need it doesn’t mean you should build or run a ticketing system.
Too often there is a lot of SharePoint whiplash and problem “solutions” that grew out of control.
Large orgs don’t always behave rationally and pragmatically when there is self preservation or politics at play instead of being effective at your work.
Yeah. For a lot of SaaS companies, their entire profit margin is about state management (in Kafka, elastic, HDFS, whatever). There's a huge incentive to squeeze that part of the stack for cost efficiency.
Truthfully I think you'll find with a thorough review of most SaaS SLAs that they are more expensive than the toil they say they replace. Otherwise how would the company make money? It's still engineers doing X work. There really aren't that many opportunities for economies of scale with enterprise SaaS when you have SLAs and data sovereignty unless you're cutting corners.
>> It's still engineers doing X work. There really aren't that many opportunities for economies of scale with enterprise SaaS when you have SLAs and data sovereignty unless you're cutting corners.
Not really, SaaS built specialized automaton to reduce the engineering effort so that they can scale better. Therefore, if the users need to spend 1 hour/day on their infra, the SaaS can spend the same amount time to manage infra for 100s customer.
In some extreme cases, the software run by the SaaS is completely different to what the regular users use. For example, Confluence Cloud Kafka service does NOT actually run Kafka underneath, but a proprietary system called Kora that speak Kafka protocol.
Doing your own, requires you to gain knowledge in that area and in my view expanding your knowledge base is really important.
It's not all about immediate possible financial gain.
Obviously there's a line somewhere
One of the key learning lately, selling software to developers/engineers in general has been that the positioning of the product should be such that - it is either too boring for engineers to care about the problem statement or too technically different to even attempt to solve it. If it falls in the middle, you will find developer resistance or value dilutation and it becomes super hard to make engineering teams adopt the product.
Secondly, opensourcing is distribution strategy. Like any other GTM, you have to consider the fact that people who are using your product almost 90+% will not buy the software. They will use it, but they won't pay for it. You have to have an outbound sales motion that reaches out to people, send linkedin messages, asking them to do PoC. Thing is, if the opensource product is popular, the end user receiving the message might have a high product recall value.
Sometimes I feel like most of these Open Source SAAS businesses were also only possible in the 0 interest rate era. If your product is open source then you are competing purely on service offerings, and it will be very hard to compete on support alone, since you have by default higher costs due to maintaining the software itself. Redhat is the exception that proves the rule, and even they are trying to get as less open as possible.
Case in point, it would be very hard for Elastic to develop Elasticsearch and then compete with Cloud providers purely on hosting quality and price. Opensearch seems to receive very very few new features compared to ES, and will have features that will not be opensource, like all the hot and cold storage stuff.
I agree and disagree at the same time. If your just providing the open source software, yes. Where Red Hat and other kind of kick this rule is by providing the open source software + some more (which may or may not be open source). This can also be support. But I look at something like Tailscale, even though it is still young, it looks pretty promising to me. They provide wireguard, but the magic is their tools and interfaces on top of it. So it seems like, you have a good shot at doing open source SAAS, but you also need to provide something like, a better and simplified interface. Which is sometimes all you need. Tons of great FOSS software out there, but a lot of them are not great at user friendliness.
That's quite an insightful take. Open Source Vendor funds the expensive software, but the value they receive back is only accrued in the delta between the Open Source Vendor managing as a SaaS and the end client managing themselves. It's like collecting pennies in front of a steamroller.
Companies like Redhat and Hashicorp are different because they sell huge enterprise deals, but a mass market SaaS only play is a tricky business model.
You are correct and it's in fact worse than even you deescribe. Startup SAAS companies have to pay to create and maintain permissions/login/user setup etc, they have to do marketing and pay to build a brand, let's say that's 30% of their work. Well with Cloud Provider most that work and cost is spread over multiple products. So they can develop and do that part cheaper.
Then because the open source version tends ot also be open community, the cloud provider will pitch to your community on your own chat channels: https://ryan-h.com/2023/07/22/the-end-of-open-source-tech-sa...
> For an open source user to convert to a paid customer, Wright said, one of three things has to happen: They are in production and there’s a major incident, the person responsible for operating the software leaves, or there are changes to their enterprise platform requirements.
I have an idea ("question" really), but not sure if it's legally sound.
I'm working on a side project for quite awhile now. My original intent was to write a simple software and then release it under AGPL. But then I got greedy and it has grown to over 20,000 lines of Go code -- too big to just give it out for free IMO.
I still want to release the software under AGPL, but now I also want to compensate for my time and effort. So I renew the plan to the following:
- I'll still release the software under AGPL as originally planed
- I'll maintain full ownership to the software, and will not be accepting code from other people (or doing anything that complicates my rights of ownership)
- Based on the original code (open sourced under AGPL), I'll create another software which adds extra functionalities for users who might want to pay for it. And this software will be for sale and completely propriety, the "all rights reserved" type.
My reasoning is, since I'm still owning the software, legally I can do whatever to it, including "re-licensing" the same code to myself under a set of different conditions. The open sourced version under this context is there to provide a fallback (say, in case my users no longer trusts me) as well as a default that guarantees the minimum functionalities that my software will absolutely offer regardless if you're paying or not.
Although it's not strictly "selling open-source software" any more, it could be a balanced approach to the conversion problem, IF it can legally be done this way of course.
But then, can it be done through? Is there any legal and licensing trap that makes the scheme impossible? Thank you in advance.
What you're describing is called "open core". It's a pretty common business model for open source companies, including GitLab and JetBrains.
Usually this is done with a permissive license—GitLab is MIT, IntelliJ core is Apache 2—but iText PDF does something similar with AGPL. My understanding is that if you actually retain full ownership and accept no outside contributions, then you're not obligated to follow the terms of your own license. AGPL is just the terms on which you let other people use your code.
> My reasoning is, since I'm still owning the software, legally I can do whatever to it, including "re-licensing"
Only if every commit is by you, or has rights assigned to you (typically via CLA).
If there's other authors, they continue to have AGPL rights on the repo - and can request your future changes to be provided to anyone the software is distributed to.
> I'll maintain full ownership to the software, and will not be accepting code from other people (or doing anything that complicates my rights of ownership)
Ack, makes sense. I was pointing to the fact of this being a long existent project, which typically would mean external contributions already existing.
I understand you want to be compensated for your work, but the world doesn't reward engineering effort by itself. If you want to run a software business, do that. If you want to run an open source project, do that. But it makes no sense to go for some kind of hybrid commercial open core project simply because you've put a lot of effort in and you feel entitled to a monetary reward.
Legally, it's fine. But your plan as described is highly unlikely to work. As others have pointed out, open core is harder than closed source, because you can only charge for the difference between the open source version and the commercial version, and that represents only a small amount of the total effort you've put in. On top of that, your main audience consists of people who really prefer not to pay for software.
I do understand that, but currently my open source projects don't bring any monetary benefit at all, and my user base is too small to provide enough donation to support the development. So under this circumstance, any payment is way better than none payment. Plus, I also designed the system in such way that it allows me to vastly extend it's functionality based on the same base code. So in theory I could make a big enough feature-gap between the two.
> On top of that, your main audience consists of people who really prefer not to pay for software.
I thought about this as well. But doing a pure close sourced product is unlikely to cover these people too. Sure, making the product open source might convert some paying users away to use the open source version, but at least I earned the trust of these users (and hopefully made them happy), still not a bad out come from the open source perspective :)
Are there any good examples on "source available" startups, where the software can be run on-prem, can be easily modified/forked by the customer, but has a commerical license? (Thinking docker desktop style: free for companies with less than X customers, monthly flat license for > X employees)
Copied from the FAQ on the pricing page: "I have strongly considered open-sourcing UXWizz but keeping it license-based allows me to work full-time on it and improve it at a much faster pace than most of the open-source software. By being focused on the self-hosted aspect (instead of providing a "hosted" solution) my interests are aligned with yours: make UXWizz easy to install, easy to update and highly-performant on any server."
People are willing to pay to self-host, especially if the product is better than the paid SaaS alternatives.
In my case, positioning the product as "self-hosted first", attracts a slightly different target audience, either technical people or business people that want to use the product to start their own SaaS. There are still many basic website owners using the analytics platform on their own, for their own website, but it seems a bit harder to get those interested than the web agencies.
Just checked out your pricing. I notice you have a one time price, which gives you a year of support/upgrades. Curious the percentage of customers who opt not to get upgrades and therefore don’t need to pay yearly.
tl;dr: Around one quarter. Currently I am not focused on that, I first want to reach more people.
Until recently, the support period would auto-renew. Many people would forget about it and ask for a refund, so I decided to make it more user-friendly and make the support renewal "on demand". I am adding the update/renewal prompt in the app soon, we'll see how it goes.
As for the current number, it depends on whether the people are still using the product, most of them are. I would say around a quarter or less renew currently. Also, now, the support/updates is not exactly strictly enforced (I sometimes respond to support queries for people without a valid support period), but I am working on integrating a ticketing system that would require a valid support period, which should give more reasons to customers to renew.
Grafana Enterprise is what I was thinking of. It is basically the same stuff as the AGPL licensed Grafana but under a commercial license for those that want to modify it. Usage of Grafana Enterprise as-is is free, no license needed.
A few years ago (pre IBM acquisition) a friend of mine at Goldman Sachs said that Red Hat was the greatest company in the world because they "sold free software".
As the founder of an OSS company (granted we're seed stage), moat is becoming more and more of a concern, especially because:
1. There are more saas companies (read: competition) than ever
2. AI has made it significantly easier to build on-the-fly transpilation
Didn't see that mentioned in the article, but it's worth noting
The gem of a quote at the end captures good sales technique perfectly: “It’s literally saying, What is it you’re trying to achieve, and by when? And yes, I can help you do that.”
I think the biggest issue with selling open-source SAAS, is that companies probably prefer buying the managed version from AWS instead of from a startup.
They likely already have approved contracts and payment set up. They likely already have a contact person. They can be pretty sure that AWS will be around for the longer term as opposed to a startup.
I’m building a marketplace to help devs sell the open source software. Would you consider putting your open source for sale on such platform? Why/why not? What would it take to help you make this decision?
This is interesting. Even more, I would like a software publisher, to package open-source software with an installer for various platforms (mostly Windows/MacOS), set up a landing page, provide invoices/POs to companies that need it, deal with payment and refunds, and just give me a cut. Does anyone know a small company out there who does this?
maybe you could elaborate a little how that works? selling open source software - it doesn't have to be an oxymoron, but making that work isn't straightforward
1. You set up an account on the marketplace - sign up, then connect it to Stripe through the marketplace and decide which software you want to sell (about 15 minutes in total)
2. Copy-paste a new license to your repositories - You relicense your software to use a slightly modified version of MIT license, which requires commercial entities to pay for your software (5 minutes or so)
That's all for config, now your part is done and the rest of work is on buyer's and marketplace's side.
You of course remain owner of your software, you don't move any rights to marketplace or users, except the license for usage, just like you do it now with MIT/GPL/whatever license you use right now. Marketplace is only to connect you with buyers and give you centralized place to sell with automated infrastructure, so you don't process payments, signups, etc. by yourself
Selling:
If a company wants to use your software, they need to pay a monthly/yearly fee - you choose how much you charge
License:
You can customize the license if you want - you can choose whether you allow free usage for non-commercial/scientific/charity purposes and you can also set some other feature flags, so you have a control over how your software is used
And that's basically it
There's an MVP on https://poss.market if you would like to check if that even makes sense to you. Thanks and please let me know what do you think if you made it to this point. I still figure this out and your feedback is invaluable to me!
> 2. Copy-paste a new license to your repositories - You relicense your software to use a slightly modified version of MIT license, which requires commercial entities to pay for your software (5 minutes or so)
Then the software is not open source anymore, i.e. the claim that one sells open source software is fraudulent.
Side remark: In the past Microsoft attempted to establish the term "shared source" for software where you can see the source code, but which is not open source.
The rules about open source aren't mysterious or hidden, and anyone who has spent time rewriting the MIT license and creating a marketplace for open source software is either familiar with them or incompetent.
Thanks for the remark. On the marketplace I call it "paid open source software", so I guess I could be more specific in original comment, sorry for unclearness from my side
1) Simply don't call it "open source software." Making up new definitions for open source is more harmful to it than anything else could be. There's nothing to open source except licensing.
2) The usual way to do this is to AGPL your software (or be even stricter), and sell it by relicensing it for businesses who pay you so they can use it how they wish. You don't have to make up a new "non-commercial open source" license to do this.
edit: It feels like OSS people are haphazardly stumbling through the thought processes that lead to the GPL in the first place. Once you've made an open source license that doesn't allow people to make money using the software, does it matter whether they share their changes or not when they distribute?
What's motivating people to reserve the right not to share changes in the software they distribute for free, other than to maintain a now enforced as worthless (by this particular license and similar variants) distinction from the GPL?
> On the marketplace I call it "paid open source software"
This is still wrong (and likely again fraudulent, but IANAL), since the software is not open source if there are such usage restrictions. Call it, for example, "paid sofware with source available" ("source available" is another common term for software for which one can see the source code, but which is not open source).
There are different variations of a similar idea. The implementation suggested here though, isn't my favorite since a modification in the license shouldn't really be necessary. And, lost of FOSS projects out there can't just simply relicense. So far, the best implementation I've seen is specific to Elementary OS in their distro software center. You can donate to projects directly via the store.
Difficult to enforce externally I think, except when an employee of a company shares an infringement with the marketplace or the creator
My assumption: the reason serious companies will pay is that they don't want to make silly mistakes like license infringement for which they can be sued. If they want to use your lib/tool/etc, because it will speed up their development or help they make money in any other way, they will choose to pay you these $100 per year. If you gain a few (dozens, hundreds, thousands) clients like this, you're able to build a solid source of income, and since they buy a license on a subscription basis, it's likely you will keep the clients for the next year
Basically, yes for now. Also your software becomes visible on the marketplace and you can have a single point of sale on your profile at the marketplace
There are further plans, but I'm still trying to get some funding/help to have a time to continue development
This article mentioned building an app "that people love," but didn't specifically mention one critical factor customers use in evaluating software: usability and design. Get subject matter expertise on your team before building the user-facing parts of your product. Engineering teams know that they're not good at marketing or sales, but don't usually realize how much winging-it with design scares away users.
Folks talk a lot about SaaS but there are other markets too, like in my case the embedded market. In this market most companies use custom toolchains and proprietary compilers with less-than-ideal standards conformance. The only way for companies to know if my software will even compile with their toolchain is if it's published (open source). That doesn't mean I need to publish all the code; unit tests and project-specific development tools can remain proprietary.
The main problem is that many teams think they’re “that guy (or girl)” who can manage a complicated piece of infra as a small team and will be saving money. If you spend 10% of your time doing devops work, you spend 10% less time on your actual product (you might as well be binging netflix). A majority of these teams convert (IME) to a hosted offering once the right price and SLAs and DevExp are there. The only part of your sales pitch that matters to these teams is “this isnt worth your time to self host when we have a great offering thats cheaper and faster to get setup”. If you have a logo from a big co that has the talent to self host but are buying your product, then your work is done.