|
|
|
|
|
|
by davidpolberger
1009 days ago
|
|
|
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. |
|
|
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.