Ask HN: Are there downsides to making all our source code publicly available?

[davidpolberger]

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:

* As a matter of principle, I like to err on the side of openness.

* We have great code, fully documented and with lots of unit tests, and I'm hoping that others could learn from it.

* It might help with recruitment, if we can talk publicly about our code and about interesting problems we are solving.

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

Are there any downsides to doing what I describe above?

[necovek]

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.

Then again, even that might be ok if you are covering a geographic area, for instance, and already have good penetration there.

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?

[night-rider]

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

Yeah and it doesn't have to be all-or-nothing. OP doesn't have to release the whole codebase. Maybe release small modules or little libraries that could help others get things done faster?

[davidpolberger]

The service is named Calcapp, an app builder for spreadsheet-savvy users (https://www.calcapp.net). The codebase weights in at half a million lines of code and documentation, with lots of generic utility libraries I have written over the past ~20 years, in Java and JavaScript.

I don't think that releasing the user-facing app creator and runtime libraries under a permissive license would be smart. However, I would still like that code to be out there, and for the utility libraries to be available for anyone to use under a permissive license.

The one downside I can see myself is that by making the source available, we might reveal security vulnerabilities. Sure, security through obscurity is not a good idea in and of itself, but revealing that we haven't updated a key, vulnerable library might still be problematic.

[necovek]

Thanks for the details.

I am on my phone so couldn't really test it out, but it sounds sufficiently niche that it could both benefit or be harmed by releasing the code.

Usually, the hardest bit is getting the infrastructure set up, so if you do have dozens of intertwined components, just pushing the code might not really help anyone.

Still, I think it depends on the business you have and market you are covering, more than the app itself. Eg. if your market is huge, somebody will want to jump in. If it's tiny, nobody else is probably going to bother even if you made it trivial to deploy and run. And there is a huge continuum of options in between :)

One thing I've seen was default to AGPL after, say, 3 years after release. Depending on the development pace, you might make that 1 or 5 years. In general, this means you could AGPL the version from 5 years ago today.

[houseatrielah]

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.

[ipaddr]

But he cannot compete on marketing and all other aspects. That single developer can just copy your product if you release code or not.

The least important part of your saas is your product.

What are you gaining from thr release

[davidpolberger]

A would-be competitor, in a country not respecting intellectual property laws, might get a few customers by launching our product and charging only a fraction of what we charge. However, what will this competitor do when their customers request new features or report bugs? Obviously, we'd be a lot more nimble in responding to such requests, so maybe this shouldn't be such a big concern after all.

Also, if this does becomes a problem, we can just stop releasing new versions publicly, at which point the competitor's offering would stagnate, while our offering would continue to improve.

[didgetmaster]

No. Worst case scenario is that the competitor has more resources than you and can be even more nimble at adding new features and fixing bugs. Because you made all the source code available, you lost all the 'head start' you had against such a competitor.

[davidpolberger]

Good point.

[caprock]

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.

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.

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.

[ezekg]

I did it (https://keygen.sh/blog/all-your-licensing-are-belong-to-you/). 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.

[ActorNightly]

Don't do things in business because they feel good (a.k.a your first 2 points), do them because of right reasons.

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

[KeithBrink]

I disagree, there's nothing wrong with a business owner doing things because it makes them happy.

[brudgers]

The absolute downside is it is a distraction from running the business.

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.

To put it another way, if it was obviously a good idea, you would not have a question.

Good luck.

[davidpolberger]

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.

[jajajsjsjjd]

Do you expect to get any tangible benefits to your codebase?

[davidpolberger]

No, it just feels like the right thing to do, and I'm hoping that others could benefit from the work. While I would like to release some libraries under permissive licenses, I really have no plans to shepherd collaborative open source projects (which I think might turn into a huge time sink). Others would obviously be welcome to fork and maintain these projects, but I would prefer for them to simply be read-only versions of what we're using in production.