I run a small SaaS business and our code is currently proprietary and hidden from view, as is the norm (the client-side code is minified). However, I would prefer to make it publicly accessible, for the following reasons:<p>* As a matter of principle, I like to err on the side of openness.<p>* We have great code, fully documented and with lots of unit tests, and I'm hoping that others could learn from it.<p>* It might help with recruitment, if we can talk publicly about our code and about interesting problems we are solving.<p>Support libraries could be licensed under a permissive license, such as MIT or Apache, while our core user-facing products could either be kept proprietary ("source available"), or be licensed under terms businesses tend to dislike -- the AGPL3 comes to mind. (If doing so could spur discussions about licensing our products under a different license, that would be a nice bonus.)<p>Are there any downsides to doing what I describe above?
I think it really is case-by-case: the idea is obviously not to make it easy for someone else to spin up a competitor SaaS by doing far less work.<p>Then again, even that might be ok if you are covering a geographic area, for instance, and already have good penetration there.<p>In general, I do want to believe we can find business models where hiding the code is not important, and we can let our users contribute back, so I wonder how much of the business model you can share here?
If a single dev ignores the license and spins up the code he can outcompete you on price; Then what? Throw money at lawyers to sue someone in a foreign land? The whole idea behind SaaS is that people can't copy-paste your cd-rom and give it to their friend.
Erring on the side of openness is fine as a principle. That doesn't mean the actions to follow the principle won't cost you time and money. Everything has tradeoffs. As a small SaaS business, I don't think public repos would make it very high on my list of priorities.<p>A good balance can be open sourcing an internal library or two, so you get some of the benefit without the work needed to polish the mass of your core code.<p>With regard to recruitment, I think the openness is mostly a benefit to employees, because they can point directly at their work product like a portfolio. So it helps recruitment, but it's about them not about your cool problems.
I did it (<a href="https://keygen.sh/blog/all-your-licensing-are-belong-to-you/" rel="nofollow noreferrer">https://keygen.sh/blog/all-your-licensing-are-belong-to-you/</a>). It's only been a few months, but I've only seen upside. And my enterprise growth has skyrocketed. But if you don't have a definitive reason to do so, e.g. to increase enterprise adoption, then perhaps rethink why it makes sense from a business perspective. You need a goal. Going open source can be your competitive advantage, or it could cause you to lose yours.
Don't do things in business because they feel good (a.k.a your first 2 points), do them because of right reasons.<p>Making your source code open should be done only if its use and modification will increase your user base and thus revenue. This can be in the form of "hey free to try for a company but once we build production, we will need to move to paid subscription", or "hey i can use this on my local computer but I want to set it up in the cloud to be accessible publicly, for which I need to use the paid product".
The absolute downside is it is a distraction from running the business.<p>Money is a better tool to improve recruitment, in all probability there are better code bases for random people to learn from, and your principles are only opinions at heart.<p>To put it another way, if it was obviously a good idea, you would not have a question.<p>Good luck.
Everyone -- thanks for your constructive comments. I think that we'll start off by releasing the libraries under permissive licenses, and see how that goes. Releasing the code of the user-facing products publicly would probably provide little value for others (as the code would not be open source), and there are indeed risks.