Ask HN: How can we open-source a 7 year old SaaS codebase and build a community?
80 comments
Your other comments sound dispassionate about your product. It makes it sound like you are only interested in growing a company and not in solving problems for your customers. You said you arent interested in slowly growing a business that is currently making you money
This is completely at odds with growing an open source community. Its typically one of the slowest and most thankless jobs you can do in software. nix has been around for 10+ years and only recently are normies like me becoming interested in it.
Your product sounds like its niche, making it open source and getting other developers to contribute sounds like trying to grow a niche within a niche. Add F# and there might be like 5 people in the whole world who might care about your open source project.
Im sure your integration partners say they would like your project to be open source but they arent going to be doing ANY of the work.
I would sell your business as a turn key.
This is completely at odds with growing an open source community. Its typically one of the slowest and most thankless jobs you can do in software. nix has been around for 10+ years and only recently are normies like me becoming interested in it.
Your product sounds like its niche, making it open source and getting other developers to contribute sounds like trying to grow a niche within a niche. Add F# and there might be like 5 people in the whole world who might care about your open source project.
Im sure your integration partners say they would like your project to be open source but they arent going to be doing ANY of the work.
I would sell your business as a turn key.
> Your other comments sound dispassionate about your product.
I really like what we've been able to create. I want more people to use it.
> You said you arent interested in slowly growing a business
I want more users. If the price is that many of them won't pay because it's open source, then that's the price.
> Im sure your integration partners say they would like your project to be open source but they arent going to be doing ANY of the work.
We have a very well-isolated back end (F#) and front end. I don't think integrators will be able to write in F#, but hopefully, they will be happy to refine the front end in Vue.
I really like what we've been able to create. I want more people to use it.
> You said you arent interested in slowly growing a business
I want more users. If the price is that many of them won't pay because it's open source, then that's the price.
> Im sure your integration partners say they would like your project to be open source but they arent going to be doing ANY of the work.
We have a very well-isolated back end (F#) and front end. I don't think integrators will be able to write in F#, but hopefully, they will be happy to refine the front end in Vue.
Funny that you mention Nix, because our infrastructure is actually completely NixOS-based. But that's only because I was (and am!) a huge fan of it, and it keeps the amount of people needed to manage our infra at one ;)
I agree with you, building an open-source community is among the hardest things to do, true both for commercial and passion projects. And you said it, the amount of the developers willing to donate their time to an obscure F# codebase is probably close to zero. So the way I see it, open-sourcing for us is not a way to gain developers of our product, but the developers on our product.
Our "product" is technically a modular JavaScript + CustomQL platform which the partners are coding on to create or customize products for the target business. Similar to the other CRM/ERP platforms on the market, it locks them in with the amount of code and in-house knowledge that they have for the platform. And we are in a chicken-and-egg situation: without an existing base of integrations, partners and solutions for the end businesses, both prospective customers and partners see risks in the support and custom development costs that they are not willing to take.
We hope that open-sourcing (thus also giving the way to run the product on your own servers for free) gives potential partners a really sweet deal compared to the traditional cut-based cloud SaaS offerings, and can help us build a network of these partners and integrations that we need. And being a CRP/ERM platform, potential ways to monetize it are still aplenty (paid-for enhancements, integrations, cloud offerings etc).
I agree with you, building an open-source community is among the hardest things to do, true both for commercial and passion projects. And you said it, the amount of the developers willing to donate their time to an obscure F# codebase is probably close to zero. So the way I see it, open-sourcing for us is not a way to gain developers of our product, but the developers on our product.
Our "product" is technically a modular JavaScript + CustomQL platform which the partners are coding on to create or customize products for the target business. Similar to the other CRM/ERP platforms on the market, it locks them in with the amount of code and in-house knowledge that they have for the platform. And we are in a chicken-and-egg situation: without an existing base of integrations, partners and solutions for the end businesses, both prospective customers and partners see risks in the support and custom development costs that they are not willing to take.
We hope that open-sourcing (thus also giving the way to run the product on your own servers for free) gives potential partners a really sweet deal compared to the traditional cut-based cloud SaaS offerings, and can help us build a network of these partners and integrations that we need. And being a CRP/ERM platform, potential ways to monetize it are still aplenty (paid-for enhancements, integrations, cloud offerings etc).
nix has been around for 10+ years and only recently are normies like me becoming interested in it.
Er, there's people who worked on it at Bell Labs in the 70's who would like to have a word. It's taken 50 years for Unix to become an overnight success for you normies to become interested...
Er, there's people who worked on it at Bell Labs in the 70's who would like to have a word. It's taken 50 years for Unix to become an overnight success for you normies to become interested...
Nix is different than Unix.
https://nixos.org/
https://nixos.org/
A few thoughts:
1. Is your target customer a software developer? It seems like your customer would be a executive, perhaps at a smaller business. You want to get that person's attention. I think open-sourcing is more likely to get developer attention.
2. There are lots of other marketing strategies you could try (content-based marketing, going to tradeshows, cold calling, etc).
3. If you have existing customers, I think you really need to work with them on in-depth case studies that explain why they benefited from choosing your solution. You should also see if you can market to other, similar customers.
4. "customizable by any developer" - That developer should be you. This I have personal experience with. We initially delivered a product and left it to the customer to configure. Later, we discovered that customizing the product for the customer delivered better results, better relationships, and allowed us to learn about our own product and our customers.
Anyway, I would do a lot of sales/marketing brainstorming before I open sourced. It seems you see it as a marketing strategy, but I think you should consider other avenues first. Good luck!
1. Is your target customer a software developer? It seems like your customer would be a executive, perhaps at a smaller business. You want to get that person's attention. I think open-sourcing is more likely to get developer attention.
2. There are lots of other marketing strategies you could try (content-based marketing, going to tradeshows, cold calling, etc).
3. If you have existing customers, I think you really need to work with them on in-depth case studies that explain why they benefited from choosing your solution. You should also see if you can market to other, similar customers.
4. "customizable by any developer" - That developer should be you. This I have personal experience with. We initially delivered a product and left it to the customer to configure. Later, we discovered that customizing the product for the customer delivered better results, better relationships, and allowed us to learn about our own product and our customers.
Anyway, I would do a lot of sales/marketing brainstorming before I open sourced. It seems you see it as a marketing strategy, but I think you should consider other avenues first. Good luck!
Thanks for the thoughts!
Your thoughts on the developers vs business decision-makers, in particular, hit the spot. When we started, we figured that customizing business software by ourselves was something we'd never be able to scale properly. So, instead, we wanted to create a community of developers and partners who know their target audience better than we do. This way, we focus on the core platform and search for these partners, who, for a cut, focus on their areas of expertise. Big competitors like ODOO, Zoho, and various local products use the same model.
Of course, as you mentioned, the pure approach didn't work well. The best clients we know are those we found by ourselves, even when we handed them off to the partners for actual developer work. But the big part was making the product customizable for the developers (including us!) in the first place because we essentially started to offer various products built on top of us that we could mix, match, and reuse.
Open-sourcing aims to attract the attention of these developers and partners by offering them a vast incentive compared to the products on the market: BYOServer and have it for free. With this, we massively cut our ability to profit from the cloud service but (hopefully!) create a community of contractors and companies who develop on our platform as their business model. With this, we create a market for the services based on our platform, and there are still lots of ways for us to profit from it with integrations, cloud offerings, and various value-added services.
Still, we continue to explore the marketing options as well — it's slow, but not as slow as before :)
Your thoughts on the developers vs business decision-makers, in particular, hit the spot. When we started, we figured that customizing business software by ourselves was something we'd never be able to scale properly. So, instead, we wanted to create a community of developers and partners who know their target audience better than we do. This way, we focus on the core platform and search for these partners, who, for a cut, focus on their areas of expertise. Big competitors like ODOO, Zoho, and various local products use the same model.
Of course, as you mentioned, the pure approach didn't work well. The best clients we know are those we found by ourselves, even when we handed them off to the partners for actual developer work. But the big part was making the product customizable for the developers (including us!) in the first place because we essentially started to offer various products built on top of us that we could mix, match, and reuse.
Open-sourcing aims to attract the attention of these developers and partners by offering them a vast incentive compared to the products on the market: BYOServer and have it for free. With this, we massively cut our ability to profit from the cloud service but (hopefully!) create a community of contractors and companies who develop on our platform as their business model. With this, we create a market for the services based on our platform, and there are still lots of ways for us to profit from it with integrations, cloud offerings, and various value-added services.
Still, we continue to explore the marketing options as well — it's slow, but not as slow as before :)
>When we started, we figured that customizing business software by ourselves was something we'd never be able to scale properly
This is the meaning of the badly put advice "do things that don't scale".
Regarding your vision of offloading the work to partners, my experience is that more time can be put trying to convince prospective partners than doing the work yourself if you are not careful.
My feeling is that you are anticipating hyper growth a bit too much. Start by doing all this work yourself, and you'll have no problem to scale with the income you'll earn.
This is assuming you price your product appropriately so that you are profitable on every transaction and customer.
This is the meaning of the badly put advice "do things that don't scale".
Regarding your vision of offloading the work to partners, my experience is that more time can be put trying to convince prospective partners than doing the work yourself if you are not careful.
My feeling is that you are anticipating hyper growth a bit too much. Start by doing all this work yourself, and you'll have no problem to scale with the income you'll earn.
This is assuming you price your product appropriately so that you are profitable on every transaction and customer.
> can be put trying to convince prospective partners
This is so true. Early on, I tried to sell our product through a system integrator channel. I hoped they would "do the sales for us." The systems integrator was super focused on sales, they talked to our target customer all the time, and they seemed super excited to sell our product.
But, it was a total flop. They didn't really seem to understand our product, and they would say anything to close a deal. Sometimes we did a lot of work, then got cut from the deal late in the game. More often, we ended up in the deal, but then had to deal with promises to the customer that didn't make any sense. It was like "the integrator said it would do what?"
I agree that you have to be really careful about selling through partners. Interestingly, the integrator channel was primarily for another, much larger software company. I told the CEO how excited we were to partner with the integrators. He looked at me and said "oh, we wish we could get rid of the integrators, but its too late because they control access to the customers." Luckily, we were small enough that walking away from the integrators worked for us.
If I were you, I would focus on identifying a few verticals where your product works well (say, car dealerships), then try to figure out how to sell to them. What are their concerns? What drives their decisions? How can you contact the right person to pitch your product? etc. If you can build a system around a vertical, you will feel so much better about sales. And once you build a system around one vertical, you can start looking for additional verticals to target.
This is so true. Early on, I tried to sell our product through a system integrator channel. I hoped they would "do the sales for us." The systems integrator was super focused on sales, they talked to our target customer all the time, and they seemed super excited to sell our product.
But, it was a total flop. They didn't really seem to understand our product, and they would say anything to close a deal. Sometimes we did a lot of work, then got cut from the deal late in the game. More often, we ended up in the deal, but then had to deal with promises to the customer that didn't make any sense. It was like "the integrator said it would do what?"
I agree that you have to be really careful about selling through partners. Interestingly, the integrator channel was primarily for another, much larger software company. I told the CEO how excited we were to partner with the integrators. He looked at me and said "oh, we wish we could get rid of the integrators, but its too late because they control access to the customers." Luckily, we were small enough that walking away from the integrators worked for us.
If I were you, I would focus on identifying a few verticals where your product works well (say, car dealerships), then try to figure out how to sell to them. What are their concerns? What drives their decisions? How can you contact the right person to pitch your product? etc. If you can build a system around a vertical, you will feel so much better about sales. And once you build a system around one vertical, you can start looking for additional verticals to target.
> Regarding your vision of offloading the work to partners, my experience is that more time can be put trying to convince prospective partners than doing the work yourself if you are not careful.
That's a good way to put it. We also have an opposite fear: that building and customizing for the end clients requires expertise and focus on a particular market. This way we quickly become "just another CRM consultancy" which happens to have their own in-house product, and limits their growth to the (relatively) narrow market they are good at. Competing for new niches with the platforms that focus on building the partner networks becomes hard, considering all the ecosystem that these platforms develop around them. We have experience at running a successful MS Dynamics consultancy like that before, but this was its limit for us.
Whether our understanding on how to balance these two extremes is adequate is a good question that we keep pondering on. So thanks for the input!
That's a good way to put it. We also have an opposite fear: that building and customizing for the end clients requires expertise and focus on a particular market. This way we quickly become "just another CRM consultancy" which happens to have their own in-house product, and limits their growth to the (relatively) narrow market they are good at. Competing for new niches with the platforms that focus on building the partner networks becomes hard, considering all the ecosystem that these platforms develop around them. We have experience at running a successful MS Dynamics consultancy like that before, but this was its limit for us.
Whether our understanding on how to balance these two extremes is adequate is a good question that we keep pondering on. So thanks for the input!
I would definitely focus more than anything on figuring out what kind of license you want to do. For example AGPL is probably the most sensible if you want to force anyone making back-end changes to share them back, but it also puts off people like me, who avoid that license like the plague, but when something is AGPL and I only care about using it as-is, that's perfectly fine. The caveat there being you could dual-license it so that if someone doesn't want to contribute back, they just pay for a commercial less restrictive license.
As for the front-end I think MIT or even GPL type of licenses make more sense, since everyone can just view that code anyway.
I would consider what kind of licensing you want to do, I would also consider goals in doing this. One huge benefit of an open source SaaS offering is the freedom to take control of what you're getting out of it in-house, or going straight to the vendor.
Will you be offering migration to and from your SaaS service? These are all key things you need to put front and center. Definitely consider what kind of license you want to use, very important.
The way something is licensed makes a big difference.
.NET and Visual Studio Code are both MIT licensed, which is why any time someone cries about "its microsoft they're just gonna take it proprietary" I point out that the MIT is the least restrictive license you could use aside from just public domain, and it makes their point moot.
As for building a community, definitely make a Discord and a forum, places people can come together and get help publicly, figure out how to get a stackoverflow space for it as well.
As for the front-end I think MIT or even GPL type of licenses make more sense, since everyone can just view that code anyway.
I would consider what kind of licensing you want to do, I would also consider goals in doing this. One huge benefit of an open source SaaS offering is the freedom to take control of what you're getting out of it in-house, or going straight to the vendor.
Will you be offering migration to and from your SaaS service? These are all key things you need to put front and center. Definitely consider what kind of license you want to use, very important.
The way something is licensed makes a big difference.
.NET and Visual Studio Code are both MIT licensed, which is why any time someone cries about "its microsoft they're just gonna take it proprietary" I point out that the MIT is the least restrictive license you could use aside from just public domain, and it makes their point moot.
As for building a community, definitely make a Discord and a forum, places people can come together and get help publicly, figure out how to get a stackoverflow space for it as well.
> I would consider what kind of licensing you want to do, I would also consider goals in doing this. One huge benefit of an open source SaaS offering is the freedom to take control of what you're getting out of it in-house, or going straight to the vendor.
We plan to put both back and front under Apache-2.0. It seems like a good enough way to show that the user won't depend on us.
> Will you be offering migration to and from your SaaS service?
Yes, we plan to continue offering the cloud for those who don't want to deploy their own solution.
> As for building a community, definitely make a Discord and a forum where people can come together and get help publicly, figure out how to get a stackoverflow space for it as well.
We're thinking about Discord right now, even started one. That is an interesting idea about Stackoverflow, thank you we'll think about it!
We plan to put both back and front under Apache-2.0. It seems like a good enough way to show that the user won't depend on us.
> Will you be offering migration to and from your SaaS service?
Yes, we plan to continue offering the cloud for those who don't want to deploy their own solution.
> As for building a community, definitely make a Discord and a forum where people can come together and get help publicly, figure out how to get a stackoverflow space for it as well.
We're thinking about Discord right now, even started one. That is an interesting idea about Stackoverflow, thank you we'll think about it!
Are you okay with Amazon taking your code and setting up their own version of SaaS for it? Not saying it'd make financial sense for them, just that… once you open source it they can do what they want.
Also remember that open sourcing something isn't a marketing panacea; you can still struggle to get people interested in it afterwards. It's a useful step if it calms your customers since they don't have to worry as much if you go away, and your value isn't the actual software but support around it or something along those lines.
Also remember that open sourcing something isn't a marketing panacea; you can still struggle to get people interested in it afterwards. It's a useful step if it calms your customers since they don't have to worry as much if you go away, and your value isn't the actual software but support around it or something along those lines.
Yes, I understand the risk, but I really care about trying something new and risky and getting more users rather than running a slow-growing business. If Amazon steals it from me tomorrow, I think I will celebrate for a week :-)
I'll add to the MarkinK's reply: the idea is that CRM/ERP target audience:
* Requires a considerable amount of integrations, customizations, and other "stuff on top";
* Has huge fears about vendor lock-ins and the possibility of unforeseen migrations/support costs.
So yes, the idea is that allowing not only custom deployments, but competitor SaaS businesses built on top of it can raise the market for the added services. Whether that would really work this way or not is a question we'd be dying to know the answer for :D
* Requires a considerable amount of integrations, customizations, and other "stuff on top";
* Has huge fears about vendor lock-ins and the possibility of unforeseen migrations/support costs.
So yes, the idea is that allowing not only custom deployments, but competitor SaaS businesses built on top of it can raise the market for the added services. Whether that would really work this way or not is a question we'd be dying to know the answer for :D
Would it make sense to have a license that gives any contributors a full license as long as they have ownership in the company they want to use it with or if that company makes a million in revenue?
my counter: how would you know if someone is using your AGPL software without paying you and how would you enforce it?
Require an api key that calls the mothership regularly
Which is the first thing the user removes from the code.
Not sure what "users" are you talking about. Most users are not programmers and most programmers are not experienced or skillful enough to alter binaries like that.
isn't most YC open-core products AGPL basically not really open source unless you pay them for it?
AGPL is open source, the issue is, think of the GPL, and how you have to share code if you release a binary. The AGPL goes a step further, so if you try to run a SaaS with your own custom code on top of the existing codebase, it says you MUST share your code. Hence, you would want to pay for the right to keep your own modifications.
isn't that basically a non-compete? we can take other peoples code to build an AGPL project but you can't take our code to become a competitor (this would fail the FOSS definition)
How is it a non-compete? You can take our code, just that if you make any changes, you must share them back to the original codebase.
> and pivoting to adding value with LLMs on top
lol, maybe you could go back in time and add some value with Blockchain or Big Data too!
Is your business profitable? Maybe a small sustainable business isn’t exciting to someone who is seeking a moonshot but it seems like you’re looking for recognition and business fame rather than actually solving customers’ problems.
In my opinion, open sourcing your product won’t magically make it more attractive to more people. It sounds like it already only fits a small niche and that’s probably fine.
If you want it to help more customers I would evaluate your product market fit as well as your marketing efforts first. Have you maxed out your addressable market or do you need more effective marketing, pricing, or something else? Is there enough business pain to justify the existence of your product?
Open source won’t really help you solve those things, it’s just a code license. In my opinion, customers of CRM/ERP products don’t really care about whether the code is open source, they care about whether the product solves their business pain, lowers costs/risks, increases productivity. E.g., if we open sourced AOL instant messenger that wouldn’t make it a more popular product than Discord.
lol, maybe you could go back in time and add some value with Blockchain or Big Data too!
Is your business profitable? Maybe a small sustainable business isn’t exciting to someone who is seeking a moonshot but it seems like you’re looking for recognition and business fame rather than actually solving customers’ problems.
In my opinion, open sourcing your product won’t magically make it more attractive to more people. It sounds like it already only fits a small niche and that’s probably fine.
If you want it to help more customers I would evaluate your product market fit as well as your marketing efforts first. Have you maxed out your addressable market or do you need more effective marketing, pricing, or something else? Is there enough business pain to justify the existence of your product?
Open source won’t really help you solve those things, it’s just a code license. In my opinion, customers of CRM/ERP products don’t really care about whether the code is open source, they care about whether the product solves their business pain, lowers costs/risks, increases productivity. E.g., if we open sourced AOL instant messenger that wouldn’t make it a more popular product than Discord.
I'm not interested in developing a product that's too slow to grow. And if it is, I guess there is no point in keeping the code closed. We are trying big moves and changes. Some of them will work. Will see. At least my integration partners really want my codebase open source :-)
My gut feeling first impression is that your integration partners probably want your code open source so that you give away all the value that you’ve worked to create.
They are looking at their best interests, not yours.
I’m thinking that you’re not looking at how to change the product to solve more customer pain and therefore grow, you’re just interested in dumping your work into open source, hoping it brings more attention to your company like a marketing campaign, and then you want to build a new fad product (AI, LLMs) in the hope that it will be your high risk high reward high growth moonshot.
Just be careful because LLMs aren’t well-suited to every single use case just like Blockchain and Big Data (which is why I brought up those fad technologies that used to make VCs salivate).
They are looking at their best interests, not yours.
I’m thinking that you’re not looking at how to change the product to solve more customer pain and therefore grow, you’re just interested in dumping your work into open source, hoping it brings more attention to your company like a marketing campaign, and then you want to build a new fad product (AI, LLMs) in the hope that it will be your high risk high reward high growth moonshot.
Just be careful because LLMs aren’t well-suited to every single use case just like Blockchain and Big Data (which is why I brought up those fad technologies that used to make VCs salivate).
Yes, I understand. But we've created a value that's too slow to grow. It doesn't make sense.
if I were you I'd seek to sell it instead of open-source it. "pivoting to adding value with LLMs on top" is very expensive from a COGS standpoint; and will complicate your business economics, not simplify them.
You don't seem to have a problem where open-source is the answer; the problem you seem to have is you built a business and a business model you weren't intending to build; and you don't solve that by open-sourcing. You can solve that a myriad of ways, but none of them are readily solved by open-sourcing your product.
You don't seem to have a problem where open-source is the answer; the problem you seem to have is you built a business and a business model you weren't intending to build; and you don't solve that by open-sourcing. You can solve that a myriad of ways, but none of them are readily solved by open-sourcing your product.
I agree, but I don't see any point in selling it. I'd instead post the code and use it in all my other businesses without depending on the buyer. Besides, there is still a market for Odoo and Zoho integrators, and I think we can try to gather some of these people around our product.
After having looked over your product's website (ozma.io), it feels like the issue may be more ensuring you're being seen by your target customer and solving a problem they have that entices them to use your product.
Your product's website is very 'feature' oriented, and not very 'Pain/Dream/Fix' formatted. https://sharpen.page/jtbd/copywriting/pain-dream-fix-and-jtb...
Your product's website is very 'feature' oriented, and not very 'Pain/Dream/Fix' formatted. https://sharpen.page/jtbd/copywriting/pain-dream-fix-and-jtb...
Interesting, thank you!
Going back to the original question of the thread, it’s starting to sound more like a grieving process than an answerable question. How do you open source the code? You flip it from private to public. That’s pretty much it. Well, okay, maybe an over-simplification.
If the business is small and profitable but it’s not growing how you’d like then I’d probably be more interested in selling it if it was me. I am not sure you will be able to sell it if the code is all open source.
If the business is small and profitable but it’s not growing how you’d like then I’d probably be more interested in selling it if it was me. I am not sure you will be able to sell it if the code is all open source.
> it's starting to sound more like a grieving process
Why? No grieving. Many products in the world are not growing as fast as their creators would like – it is OK. We just try new things and see what happens. Like what if you put all the code on the net :-)
Why? No grieving. Many products in the world are not growing as fast as their creators would like – it is OK. We just try new things and see what happens. Like what if you put all the code on the net :-)
I said grieving because it’s like you made something that is “dead” but you think you can save it via open source, when in reality it may just be “dead.” (Or not, I don’t know)
Though, I like what someone else brought up in another reply to you about pain/dream/fix. It’s very similar to what you learn in programs like Force Management training where they teach frameworks like MEDDPICC. Finding business pain, demonstrating negative consequences to build urgency, etc.
I don’t know if this is something you’ve already done or if the sales approach has been more like “if you build it they will come.”
Though, I like what someone else brought up in another reply to you about pain/dream/fix. It’s very similar to what you learn in programs like Force Management training where they teach frameworks like MEDDPICC. Finding business pain, demonstrating negative consequences to build urgency, etc.
I don’t know if this is something you’ve already done or if the sales approach has been more like “if you build it they will come.”
i completely agree, having seen founders over and over again delude themselves into belief that a marketing push will get their product to some escape velocity
I'm usually hesitant to give advice since I'm never in someone elses shoes, but here's some thoughts:
A lot of community building comes down to trust, whether you are developing a commercial or open source platform. As a customer and integrator/consultant/developer, I want to know that the platform is going to be around and supported. The bigger my company the higher the risk is.
Open sourcing your software sends signals to your customers and partners. Some will see it as a last ditch effort to make it successful, with the flip side being that if it doesn't happen, you're won't be maintaining it anymore. Will that make them more or less likely to use your software/help build your community?
So in your messaging you should be very clear in what you want to achieve, and how you plan to build a successful business around an open source or open core model, and how the others companies fit into this. How will you respond if another company takes your code and does the exact same thing you're trying to monetize, only better? Etc.
You should also be careful about positive feedback. Most people like to be nice and supportive, and won't say negative things. The only way to know whether you'll have success there is to see actual commitment (in money or work spent) with your product.
Finally as others have said, you shouldn't expect automatic success/community by open sourcing the code. You might end up attracting the sort of customers / developers that have the least incentive to contribute or pay for additional services, unless you go find those yourself.
A lot of community building comes down to trust, whether you are developing a commercial or open source platform. As a customer and integrator/consultant/developer, I want to know that the platform is going to be around and supported. The bigger my company the higher the risk is.
Open sourcing your software sends signals to your customers and partners. Some will see it as a last ditch effort to make it successful, with the flip side being that if it doesn't happen, you're won't be maintaining it anymore. Will that make them more or less likely to use your software/help build your community?
So in your messaging you should be very clear in what you want to achieve, and how you plan to build a successful business around an open source or open core model, and how the others companies fit into this. How will you respond if another company takes your code and does the exact same thing you're trying to monetize, only better? Etc.
You should also be careful about positive feedback. Most people like to be nice and supportive, and won't say negative things. The only way to know whether you'll have success there is to see actual commitment (in money or work spent) with your product.
Finally as others have said, you shouldn't expect automatic success/community by open sourcing the code. You might end up attracting the sort of customers / developers that have the least incentive to contribute or pay for additional services, unless you go find those yourself.
Hey,
One good case study is Maybe Finance. It was a dead project. They open sourced it. And it went viral. And they raised $1.5m within another few weeks. The virality was on GitHub stars and Twitter.
I run a channel about open source that may give you ideas of what other COSS projects are doing: https://youtube.com/elie2222
My COSS is called Inbox Zero: https://getinboxzero.com.
One good case study is Maybe Finance. It was a dead project. They open sourced it. And it went viral. And they raised $1.5m within another few weeks. The virality was on GitHub stars and Twitter.
I run a channel about open source that may give you ideas of what other COSS projects are doing: https://youtube.com/elie2222
My COSS is called Inbox Zero: https://getinboxzero.com.
I heard of Maybe, I invested in them as well. I'm actually looking to do something similar as a COSS, same niche as well but not exactly, more of a budgeting tool like YNAB rather than a full blown investment tracking tool, all open source. Any tips you have for that and for COSS in general?
I didn't know that about Maybe Finance. Was that what prompted you to os inboxzero?
What are the pros and cons? Aren't you afraid that it makes the SaaS offering less enticing, especially to highly technical people (which seems like might be a big chunk of your potential users)?
What are the pros and cons? Aren't you afraid that it makes the SaaS offering less enticing, especially to highly technical people (which seems like might be a big chunk of your potential users)?
COSS stands for ?
Controller of site safety doesn't exactly fit the bill..
Controller of site safety doesn't exactly fit the bill..
> COSS stands for ?
It's likely "Commercial Open Source Software"
It's likely "Commercial Open Source Software"
I read a bunch of comments and responses from you on this thread. Here's my 2 cents:
I think you're looking with the wrong lenses here. Open sourcing targets the wrong audience, and F# is such a niche language that you'll probably have zero traction, especially in a space like CRM/ERP, which has well established open source solutions like Odoo.
If you want to grow, start to focus on your GTM strategy. You can obviously build a product, and your customers are a testament that you have, at least, some PMF. Do outbound sales -- this space is clearly one that you can afford that --, and invest in marketing. Your website desperately needs some professional work there.
I think you're looking with the wrong lenses here. Open sourcing targets the wrong audience, and F# is such a niche language that you'll probably have zero traction, especially in a space like CRM/ERP, which has well established open source solutions like Odoo.
If you want to grow, start to focus on your GTM strategy. You can obviously build a product, and your customers are a testament that you have, at least, some PMF. Do outbound sales -- this space is clearly one that you can afford that --, and invest in marketing. Your website desperately needs some professional work there.
I don't have any experience building an open-source community, but I do have a lot of experience in marketing. With that context, here's some thoughts – hopefully they're helpful, if they're not, I guess you can just ignore them.
1. Link everything together. If I'm on your github it should be obvious how I can get to your discord/slack/website/forum and vice versa, don't make me work for it.
2. Build a regular rhythm to your comms/emails etc. If people opt-in to hearing from you, you need to hold up your end of the deal and commit to regular, quality updates. This will become the heartbeat of the community.
3. Pick 1 or 2 'brand' assets. Try to make them distinct, and then use them consistently everywhere. Your logo is probably a good one, but some kind of color combination/sound/flair should be distinctively you. Use these assets everywhere so that it becomes a visual shortcut in people's brains.
Ultimately, keep it simple, and just start. Don't overthink everything, you can always pivot and change as you move forward.
1. Link everything together. If I'm on your github it should be obvious how I can get to your discord/slack/website/forum and vice versa, don't make me work for it.
2. Build a regular rhythm to your comms/emails etc. If people opt-in to hearing from you, you need to hold up your end of the deal and commit to regular, quality updates. This will become the heartbeat of the community.
3. Pick 1 or 2 'brand' assets. Try to make them distinct, and then use them consistently everywhere. Your logo is probably a good one, but some kind of color combination/sound/flair should be distinctively you. Use these assets everywhere so that it becomes a visual shortcut in people's brains.
Ultimately, keep it simple, and just start. Don't overthink everything, you can always pivot and change as you move forward.
Thank you so much! I got it written down, and we will check account links separately. I understand about the updates. I heard that regular updates are important for GitHub also, to know which projects are alive and which are dead. Interesting, thanks!
The short answer is that you cannot simply create a passionate and involved community overnight. This development must be mostly organic, starting with community and open-source contributions from the beginning. While it's possible to initiate this process now, building a deeply engaged community typically requires a gradual and natural evolution over time. It's not something that can be switched on instantly.
It's not clear to me why you want to open source. Is your hope that your product is so good people will install it and run it for themselves? As others have said, I doubt you'll get anyone interested in writing code. It's a niche product in a less popular language, and you'd need to get people using the product who can code. Not a lot of people who use CRM/ERP also code.
What goal are you trying to achieve?
What goal are you trying to achieve?
That's all true, but why not put it out there for all to see? This project is useful. People are using it. There are customers with hundreds of users and tens of millions of rows in the database. But the product is not growing fast. What's the point of hiding this code and not putting it out into the open source?
There is a cost to open sourcing. You have to maintain the community. If your goal isn't aligned with that, then you will get upset and probably stop maintaining the community.
Unless you plan to shutter the business, it could harm you more than help to open source if you don't spend the time maintaining the community, which could be a net negative for you.
It's highly unlikely that your userbase will grow or that your product will grow faster if you open source it. So you'll be adding an extra burden and still be in the same place.
Unless you plan to shutter the business, it could harm you more than help to open source if you don't spend the time maintaining the community, which could be a net negative for you.
It's highly unlikely that your userbase will grow or that your product will grow faster if you open source it. So you'll be adding an extra burden and still be in the same place.
That's a counterintuitive and interesting thought, I'll have to ponder that, thanks.
Because of money? Once you open source, you can't go back without paying a heavy penalty. Also, you seem to be obsessed with growth. Saas is not an acronym for fast growth.
Open sourcing it will not necessarily give you signficantly more growth but it will give you more work and if it actually any useful, someone will fork it and make a better version then outgrow you
Open sourcing it will not necessarily give you signficantly more growth but it will give you more work and if it actually any useful, someone will fork it and make a better version then outgrow you
I don't have any good answers for you re building a community as usually people will only come if there's money. So if you could create some kind of marketplace where customers could ask for things to be built and then devs could build and make some money from it then that might work. But starting a two-sided marketplace is hard ... or so they say.
But I mainly wanted to comment and say I started learning F# recently getting a bit into Elmish and think F# is a pragmatic language and would love to learn more but there is a lack of large F# codebases to learn from. So would be interested in taking a peek at how one would construct a large F# codebase targeting the enterprise if this does ever get released.
But I mainly wanted to comment and say I started learning F# recently getting a bit into Elmish and think F# is a pragmatic language and would love to learn more but there is a lack of large F# codebases to learn from. So would be interested in taking a peek at how one would construct a large F# codebase targeting the enterprise if this does ever get released.
If you had a form where I could enter my email address, I'd be interested in at least being notified when it drops, so I could go about taking a look at it off the back of your HN description of what it does.
I will appear later on our GitHub account:
https://github.com/ozma-io
It would be great if you could give us feedback, use it or even contribute.
It would be great if you could give us feedback, use it or even contribute.
Commercial part aside, what works is finding a community that resonates with what you do and announcing your code release there. Maybe something in the F# or FP space? Considering the commercial part though, I think it should be very clear how the project is self-sustaining without add-ons that need to be bought. If you plan for companies contributing, probably collaboration with some foundation that runs similar projects makes things easier
Hi.
I can link you up with a global payment processing fintech. Mid market/smb ERp and CRM are being commoditized. The fintech works with these cominies to bolt on the payment opportunity on the AR and AP side. For example a $10m year biz represents $10-$18m in payments. I.E., about a $100 to $200k profit oppty - recurring.
Open sourcing is a good idea - it allows for platform innovation and adoption - while regulated services becomes the profit driver.
I can link you up with a global payment processing fintech. Mid market/smb ERp and CRM are being commoditized. The fintech works with these cominies to bolt on the payment opportunity on the AR and AP side. For example a $10m year biz represents $10-$18m in payments. I.E., about a $100 to $200k profit oppty - recurring.
Open sourcing is a good idea - it allows for platform innovation and adoption - while regulated services becomes the profit driver.
For anyone else wondering what the product is, it appears it is this: https://ozma.io/
I'm obviously not the target audience, as I have no idea what the product is from scrolling on the front page. For all I know it could be a fake company made up for the purposes of promoting a website template lol...
yep
ozmo.io feels odd. Considering the examples in the screenshots, it seems aimed at some foreign market, but all text is in English and it reads slightly "off".
I think most of website design/copy is about creating the appearance of being legitimate, but that is difficult without being culturally native.
Why not try marketing to actual customers in their own language(s)?
I don't think there any downsides to open-sourcing, but probably no up-sides either.
I think most of website design/copy is about creating the appearance of being legitimate, but that is difficult without being culturally native.
Why not try marketing to actual customers in their own language(s)?
I don't think there any downsides to open-sourcing, but probably no up-sides either.
That's a good idea, thanks!
HN is your best bet to gain visibility open sourcing it. Your product looks great, I would choose it over odoo and the other open source options that look like software from the 2000s.
But the most important thing is, by reading your current mood with the project, open sourcing it will give your integrators the possibility of continuing using it when you totally stop caring about it.
But the most important thing is, by reading your current mood with the project, open sourcing it will give your integrators the possibility of continuing using it when you totally stop caring about it.
We'll see! I'm curious to see what comes out of all this
I don't know when this trend or became common acceptance but its puzzling to me:
Open sourcing for the sake of generating buzz in hopes of more sales ?
Isn't by open sourcing you remove that option to pay you?
What would somebody do with 38k lines of code that captures tech debt/esoteric workflows?
Open sourcing for the sake of generating buzz in hopes of more sales ?
Isn't by open sourcing you remove that option to pay you?
What would somebody do with 38k lines of code that captures tech debt/esoteric workflows?
It's simpler — we're not growing as fast as we want. So, for us, the value of the code is not great. I am interested in putting it out in the open and seeing what happens. It would be great if I could gather a community around it and make more people use it. If not, we lose nothing crucial because only fast-growing products interest us.
(co-founded a commercial startup based on an open source project, invest into a lot of open source/commercial businesses)
Open sourcing as a strategy works when there is a lot of developer interest and (usually) a developer is the beneficiary of the software (that doesn't mean the developer is the end user, but take WordPress, even if it's used by a lot of marketers for websites, it is developers who are the ones using it to produce those websites).
If your product is CRM/ERP, is there a lot of developer involvement in the provision of the software? And if not, what is the enabling factor for your beneficiaries to be able to take a FOSS package and begin to realize value? Don't confuse positive feedback of "this is cool" etc with positive feedback from buyers and beneficiaries.
FOSS B2B software communities work when there is value in not using the commercial version. Why would anyone who needs a CRM/ERP want to use a FOSS product when they would have budget to buy a commercial version and gain commercial support. I would assert that all users of CRM/ERP software have budget - unfortunately they just don't want to spend it on your product and so why would they then want to take the same product for free instead?
I think you need to have a clear reassessment of why your business is where it is (where it isn't) and what would change that. Not sure that open sourcing solves that. Good luck.
Open sourcing as a strategy works when there is a lot of developer interest and (usually) a developer is the beneficiary of the software (that doesn't mean the developer is the end user, but take WordPress, even if it's used by a lot of marketers for websites, it is developers who are the ones using it to produce those websites).
If your product is CRM/ERP, is there a lot of developer involvement in the provision of the software? And if not, what is the enabling factor for your beneficiaries to be able to take a FOSS package and begin to realize value? Don't confuse positive feedback of "this is cool" etc with positive feedback from buyers and beneficiaries.
FOSS B2B software communities work when there is value in not using the commercial version. Why would anyone who needs a CRM/ERP want to use a FOSS product when they would have budget to buy a commercial version and gain commercial support. I would assert that all users of CRM/ERP software have budget - unfortunately they just don't want to spend it on your product and so why would they then want to take the same product for free instead?
I think you need to have a clear reassessment of why your business is where it is (where it isn't) and what would change that. Not sure that open sourcing solves that. Good luck.
Hey, thanks for chipping in! Let me try to answer these questions.
The platform for us is almost as much a developer-targeted product as it's a business-targeted product. It gives a developer a relatively easy but quite flexible way of building business apps of all kinds, and modular, so it can be reused later. And the more one builds on it, the more incentive they have for keeping on the platform and the larger potential costs of migration. We also offer modules for free to build upon.
The CRM/ERP consultancies usually have cuts from the license fees of the SaaS products they develop on (we are currently no exception). What we want to offer instead is for them to effectively collect the SaaS fees themselves if they host, easily offer "cheap" on-prem installations and give assurance both to them and their clients about the vendor lock-in issues. This may bring more and more development companies, which grows the amount of integrations and solutions on the market, which creates a loop. Finally, the end businesses don't pick CRMs; they pick a consultant who picks a CRM for them.
We still see enough ways to monetize the product if it takes off this way. The question is whether our reasoning holds true.
The platform for us is almost as much a developer-targeted product as it's a business-targeted product. It gives a developer a relatively easy but quite flexible way of building business apps of all kinds, and modular, so it can be reused later. And the more one builds on it, the more incentive they have for keeping on the platform and the larger potential costs of migration. We also offer modules for free to build upon.
The CRM/ERP consultancies usually have cuts from the license fees of the SaaS products they develop on (we are currently no exception). What we want to offer instead is for them to effectively collect the SaaS fees themselves if they host, easily offer "cheap" on-prem installations and give assurance both to them and their clients about the vendor lock-in issues. This may bring more and more development companies, which grows the amount of integrations and solutions on the market, which creates a loop. Finally, the end businesses don't pick CRMs; they pick a consultant who picks a CRM for them.
We still see enough ways to monetize the product if it takes off this way. The question is whether our reasoning holds true.
You could begin by switching the existing repo(s?) to public. If secrets in the commits are a concern you can use stuff like GitGuardian (https://gitguardian.com)
Wow, lots of stuff to unpack here, some of it interesting and helpful, most of it noise, and some downright wrong, especially around the licensing. My suggestion is to hire an open source strategy consultant for a few weeks (not me) to help you sort through it all. If you want some recommendations reach out at: linkedin.com/in/opensourcestrategy
Wow, lots of stuff to unpack here, some of it interesting, most of it noise and some downright wrong, especially around the licensing. My suggestion is to hire an open source strategy consultant for a few weeks (not me) to help you sort through it all. If you want some recommendations reach out at: linkedin.com/in/opensourcestrategy
have you considered selling the business?
We thought about it, but it's too boring and not enough money is offered. I want to do something fun and something that people need, not to get a little bit of money.
Selling the business would free up your time to do something else that scratches your itch.
A lot of people are interested in owning boring low-growth businesses. If that’s not you that’s okay.
A lot of people are interested in owning boring low-growth businesses. If that’s not you that’s okay.
Make sure to AGPL it so you can still relicense and sell it later to someone (or more than one someone) who thinks they can make money with it.
I'm afraid that AGPL is not an actual open-source launch test. As a developer, I wouldn't contribute to such a product.
AGPL is the strongest open source there is; it makes sure all derivatives of the licensed product that are publicly accessible, even over the net, provide the core freedoms of open source to all users (reading source and modifying it, using it for any purpose).
I'm Kirill Markin, and my co-founder is Nikolay Amiantov. We've been working on our CRM/ERP product since 2017 and even have paying customers. But our growth is slow, and that's not exciting. We want to create something bigger for more people to use, and open-sourcing is something that both resonates with us and is a way to attract a community.
Our codebase is 38k LoC of F# (including a compiler for our own query language) and 35k LoC of TypeScript + Vue.js. While we prepare the code we have been reaching out to Zoho and ODOO integrators/developers (as they’re our closest competitors), from whom we got a lot of positive feedback.
Our biggest hurdle is figuring out the best way to take the next steps. Does anyone have any ideas on how to launch such a large codebase on GitHub to get maximum visibility? Suggestions on building a community around our open-source product, organizing further work, or any other pieces of advice are welcome.