Live data from Hacker News

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

news.ycombinator.com

1–10 of 18 posts

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

#1
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?

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

#2
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?

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

#3
post #2

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…

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.

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

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

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

#5

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.

Good point.

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

#6
post #2

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

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

#7
post #2

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…

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 s…

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.

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

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

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

#9

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.

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

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

#10
post #9

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.

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

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.

Post reply on HN