The Problem with Community Editions and Open Source Licenses
Greg Lind Sep 6
Community editions, open source versions of proprietary SaaS projects are similar to the out of date editions of a tech books in the discount bargain bin. A loss leader to get you in the store and buy the expensive stuff in the back. Yes, they can be interesting from a historical standpoint and something to learn from but they rarely help you or your customers get any real work done. The problems are many and solutions are few and the complexity or open source licenses offers little respite.
For starters developers rarely have time or a decent strategy to maintain a community edition. The UI and UX is an afterthought and the libraries are extremely outdated. On top of that you never find a hosted and supported instance of a community edition. All the bad stereotypes for open source software as a service comes from the community editions; slow, complex, difficult to learn and out of date.
So how do we ditch the problems of the community edition and focus on the positives of open source. One way we see is through evolving open source licenses for the varying platform as a service use cases. At Humanitec we share our platform with other developers and IT teams so they can deploy and manage code, reuse our core services and build and enhance existing connected micro-services for free. All developers have to do is agree to continue to build on our platform, share and sell it in our marketplace and contribute that work back to the community as open source. We keep track of every fork of code, and when it’s used in our service they get a percentage of the API call income. Our version of Open Source has become the default for every service we build, we can develop in a completely transparent way with a community based approach and still find a way to protect ownership of the original version of the code while earning an income.
The Definition of Open Source
The biggest remaining problem for us is that we aren’t technically allowed to call this Open Source because the type of license we need to share code but still protect origination doesn’t fit under the traditional monicker of “Open Source” as prescribed by the OSI at opensource.org. Why? Mostly because of this bullet item:
- License Must Not Be Specific to a Product The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution. In our case the “software distribution” is the Platform as a Service we have built and to which we want to tie our version of the Affero GPL license to. Essentially it’s the same as the current AGPL but with a simple preamble stating that if you want to build something on our platform great, just keep it open source and for as long as our platform is around keep it here in our marketplace along with our services and core we built specifically for reusing micro-services.
We want to do it this way mostly to keep our customers, investors and selves happy in the knowledge that the work they did or paid for will be redistributed fairly on the platform. They will get credit for it, and they will get paid for that work when it is reused on our platform but it’s far less likely someone else takes it and distributes it on their platform. They can still benefit in all the same ways from open source but with this added bit of comfort that their work is still their’s if they want it to be.
A New Old Definition
In the sense that open source in its original intention was to allow developers to share and learn from each other and to get help easily when needed we think our version of the AGPL license fits the true meaning and intention. We understand the need to avoid confusion by limiting the number and types of licenses that qualify as approved “Open Source”. However not allowing companies like ours to share innovations and progress while protecting just enough IP to earn a living is keeping them from having an approved open source license that can be trusted. In the end this will just bring on more fractures and confusion as we try to adopt new definitions of open source.