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.

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 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).

https://nixos.org/

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!

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 :)

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 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.

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!

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.

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!

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.

* 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

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.

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).

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.

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...

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.

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 :-)

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.”

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.

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.

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)?

Controller of site safety doesn't exactly fit the bill..

It's likely "Commercial Open Source Software"

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.

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.

What goal are you trying to achieve?

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.

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

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.

It would be great if you could give us feedback, use it or even contribute.

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 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.

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.

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 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.

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.

A lot of people are interested in owning boring low-growth businesses. If that’s not you that’s okay.