8 ms·
Selling open-source software
- debarshri 3y agoOne 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.
- TommyDANGerous 3y agoGreat response!
- phendrenad2 3y agoI don't see anything specific to open-source here. You could switch the title to "Selling software that has a free tier" and it would still fit.
- RcouF1uZ4gsC 3y agoI 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.
- nirui 3y ago> 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.
- anilgulecha 3y ago> 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.
- lolinder 3y ago
- shaburn 3y agoVery compelling arguement for closed source.
- hgs3 3y agoFolks 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.
- generalizations 3y agoI’d be interested if you elaborated. Open source is definitely a tough starting point, though sometimes it can have some competitive advantages.
- tomhallett 3y agoAre 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)
- extragood 3y agoI think n8n qualifies. Also TrueNAS
- pydry 3y agoElastic
- deleted 3y ago[deleted]
- XCSme 3y agoI am building one such "source available" product: https://uxwizz.com https://uxwizz.com 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.
- tomhallett 3y agoJust 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.
- yu3zhou4 3y agoI’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?
- saulpw 3y agoThis 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?
- convolvatron 3y agomaybe 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
- yu3zhou4 3y agoSure, happy to share more: Config: 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 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!
- omeze 3y agoThe 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.
- throttlebody 3y agoDoing 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
- JohnMakin 3y agoA few problems with your comment - 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.
- ncrmro 3y ago3. Managed solutions usually aren’t as configurable.
- crop_rotation 3y agoSometimes 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.
- tcmart14 3y agoI 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.
- deleted 3y ago[deleted]
- benjaminwootton 3y agoThat'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.
- RyanHamilton 3y agoYou 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-saas-companies/ https://ryan-h.com/2023/07/22/the-end-of-open-source-tech-sa...
- datadrivenangel 3y agoThe 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.”
- asow92 3y agoA 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".
- deleted 3y ago[deleted]
- zkirby 3y agoAs 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
- chefandy 3y agoThis 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.