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.
The Problems
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.
A Solution
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.
References:
https://www.idgconnect.com/abstract/29497/alfresco-founder-commercial-open-source-old-stuff-free
https://www.wired.com/2016/03/former-open-sourcers-ask-companies-pay-fair-share/
Top comments (4)
Great debate topic. Here's my perspective.
AGPL is the most restrictive and business-oriented license I am aware of. Because the business has the freedom to re-release the software under a different license to suit whatever needs they might have in the future. But "community" users are utterly caged and shackled by its terms. And if the project should be abandoned by the owning company, that leaves the code essentially unusable -- too much liability/restriction for someone else to pickup the torch, since they don't have an actually-free license or relicensing freedom.
The AGPL ensures a closed system of contributions for the business. So even with exceptions, it seems inaccurate to characterize/use it as a community license. And let's be fair, the whole reason you would choose AGPL is to mitigate business risk -- nothing to do with a community. If you want people to be actually free to use and modify something, you would choose a different license (BSD, MIT, Apache, etc).
Totally agree on the AGPL, it's an antiquated license designed for old models of software distribution. There isn't an approved OSI model that fits SaaS distribution without giving up all IP rights. While I'd like to live in a world where we don't need to get paid for our work, that's not reality.
If we want to have options to build open source software and distribute it without working for an Oracle or RedHat we need a license that allows us to share and work openly for the sake of innovation while still retaining some way of selling that software without giving up all the IP. It doesn't have to be the only license option, BSD, MIT and Apache are great for pure community building but we need another option that's approved and monitored by a body like the OSI.
I do not agree. Sure there are plenty examples where the open source/community edition is an afterthought. But there are also a lot of products where the open source/community edition is the base of the product and the propriety version includes additional modules and/or hosting.
Take for example JFrog's Artifactory, Sonatype Nexus, SonarQube. The proprietary versions are just bundled with additional modules.
I think those are likely outliers. If you look at a vast majority of enterprise SaaS or even developers tools. The community edition is the first row on the left with smallest feature set, then it moves on to the small, medium and then enterprise functionality, often even a different code base. There are some exceptions but I think if we can align an open source license with reuse on a specific platform then you have an opportunity to build open source, benefit from collaboration, and sell a product.