Sharetribe Go becomes source-available after being open-source for 8 years
Today, we are changing the license of Sharetribe Go from MIT to Sharetribe Community Public Licence. For 99.9% of the users of self-hosted Sharetribe Go, this doesn’t change anything: the code is still available online, and you can download the code for free and run it on your servers to power your own marketplace business. You can also modify the code the way you wish while doing so. You can also make money offering setup or customization services on top of this code. The only practical change is that it’s no longer allowed to provide the Sharetribe Go codebase as a SaaS offering.
This limitation in the license means that Sharetribe Go is no longer open-source according to the official definition. Instead, the new license turns Sharetribe Go into what is nowadays commonly called source-available software.
In this post, I outline the reasons behind this decision and what it means in practice. First, some background on why we originally chose the open-source approach.
Sharetribe was founded in 2011. The codebase that powers Sharetribe Go today has gone through many transformations, but its origins are in the open-source project that existed already on the day the company was founded, and the project has remained open-source ever since. From the very beginning, we were inspired by WordPress, who democratized publishing through their open-source project. Our ambition was, and still is, to do the same to online marketplaces and the sharing economy: to democratize them by allowing anyone to create a successful online marketplace business that they own and control. Today, our mission is more important than ever: we want to offer a real alternative to the gigantic “death star” platforms that are dominating the sharing economy.
Given this mission, the open-source approach felt natural. As I outlined in a blog post from 2016: “We think that offering an open-source platform is the best way to achieve true democratization of the platform/sharing economy, as described in our purpose.” It was crucial to us that our customers would not have a lock-in. They should not be limited only to the features of our hosted codebase. Instead, they should be able to extend the software to build any features by themselves, if their business would so demand.
There was another reason for keeping our code open. At the time of writing the 2016 blog post, we were structured as a traditional, VC-funded startup. Internally, we talked about being open-source as “insurance against turning evil”. If we would be tempted to start maximizing profits at the expense of our customers, a more ethical company could fork the code and become a more responsible steward.
In 2018, we concluded that we needed a better way to ensure that our company would always prioritize its purpose over profit maximization. We transitioned into a company structure called steward-ownership. This change is permanent, and it forever removes any incentive from the company’s management to maximize its profits. After this change, the returns that the shareholders of the company can get from our profits are capped. Once this cap has been reached, Sharetribe is bound to spend 100% of its profits in activities that advance its purpose. This might mean additional investments in product development, investing in other companies with similar missions, or even donating the profits. Putting the profits into the pockets of owners or employees is not allowed. The structure also guarantees the company will always remain 100% controlled by its team, as outside investors are not allowed to command voting power.
Given this transition, it might seem even more puzzling that we would want to limit the use of our codebase in any way. After all, we have no incentive to extract the maximum amount of profits from the software we make. Why, then, the license change?
Before addressing this question, let’s look at what has happened in the open-source world in recent years.
The exploitation of open-source
The past five years have seen the rise of Platform Cooperativism, a movement aiming to create a new breed of platforms that are owned and governed by their users. I’ve been involved in this movement since its infancy. In the discussion groups of platform cooperativists, its relationship to open-source has been an important theme.
On one hand, it seemed obvious that platform cooperatives should be powered by open-source software. I myself wrote a blog post making this exact case back in 2017.
Different voices emerged, too. Nathan Schneider, one of the thought leaders of the movement, published a post in 2016 titled Platform Cooperativism as a Critique of Open-Source. In the post, he notes that the biggest benefactors of the open-source movement are large corporations like Google and IBM.
Some more traditionally structured open-source startups have made the same observation. Jay Kreps, the founder of the large software company Confluent that builds distributed data systems, observes that public software giants (he mentions Microsoft, Google, Amazon, and Alibaba) proceeded to bake Confluent’s open-source software into their cloud offerings, posing a challenge to Confluent’s sustainability.
Kreps points to a worrisome development from another field of software, NoSQL databases. “Dozens of NoSQL databases emerged in the 2009–2010 timeframe. — — Only systems that remained relevant through to today are those that, whatever their origin, managed to develop a stable commercial entity that helped sustain ongoing investment. Those that didn’t — — have all fallen by the wayside, despite early popularity.”
Essentially, his conclusion — which I agree with — is that in order for an open-source software project to remain relevant and active over the years, this project needs to be stewarded by a financially sustainable entity.
Emergence of alternative licensing options
In recent years, a phenomenon called source-available software has gained popularity. The term is used to describe models where software code is freely available for download online, but certain restrictions are put in place in terms of how it can be used. Typically, these restrictions are put in place to ensure the sustainability of the project’s steward. Sometimes, these restrictions mean that the code can’t be officially considered open-source.
Confluent chose this route. In his post, Kreps describes the terms of their new license: it essentially allows any other type of use except building a SaaS offering for it to compete with Confluent.
Some platform cooperatives have also decided to make their software source-available. CoopCycle, a software solution for creating bike delivery platforms, has licensed their code with a Copyleft license, which permits commercial use of their software only to cooperatives. An initiative called Co-op Source Foundation has developed a Co-op Source License to help other co-operatives transition to similar licensing schemes. Nathan Schneider points to CopyFair licenses, which “aim to subject commercialization of knowledge commons to some form of contribution to that commons”.
These licenses are, purposefully, not open-source according to the official definition. Schneider writes: “In capitalism, commons that don’t challenge capital will end up serving capital.”
Sharetribe and source-available
Over the years, several people have asked us whether we’re worried about others exploiting our software. I’ve always shrugged their words off, noting confidently that I’m not worried about copycats, as I strongly believed that people will want to support the original creators instead of copycats. However, in hindsight, I think my confidence has been strongly fueled by the fact that nobody has made a serious attempt to prove me wrong. Until this year.
In the spring of 2019, we started getting contacted by people who had noticed that there was a company that operated under a different brand but was clearly selling a software identical to Sharetribe Go, but with a lower price. They were puzzled by this observation.
After investigating the issue, we concluded that the company was not doing anything that would be against the terms of our permissive MIT license.
The fundamental underlying problem was not this particular company. The problem was that if we continued with our current approach, there would certainly be lots of other similar companies who would build this kind of offerings.
Right now, we are spending more than 50% of our budget in R&D. It dawned on us that eventually, it would become challenging to compete against these kinds of players and continue our current level of investment in development.
To really democratize the sharing economy, we need to be able to help the users of our software to compete head-on with platform giants that have large engineering teams of their own. We want to see a world where thousands of independent, mission-driven marketplace businesses thrive. To get there, we strongly believe that the core marketplace software powering all these businesses must have a steward that is both able to build a sustainable, independent business around the software, and committed to not extracting more than it needs from the community it’s serving. We think we are well-positioned to be that steward.
Our transition to steward-ownership last year ensures that we will never end up extracting more than we need to sustain ourselves. Now, we are taking action to ensure our sustainability as a business in the long term, while preventing extractive organizations exploiting the solutions we are building.
Today, Sharetribe Go’s license changes from MIT license to Sharetribe Community Public Licence. The new license is a lot like the previous one, except a new addition that prevents other companies from offering Sharetribe Go as a SaaS solution.
Licenses are tools. We needed a license that allows us to continue making Sharetribe Go available for anyone to download and run on their own servers for the purposes of building marketplaces of their own, while at the same time allowing us to invest heavily in the development of its codebase. Our new license has been built to achieve this purpose.
Despite all this, we are making this decision with heavy hearts. There’s always been pride in our voices when we’ve been able to say that our code is open-source. That is no longer the case. However, we believe this is the right trade-off to make.
Answers to questions
Here are some answers to the questions you might have related to this change.
Can I download, modify, or redistribute the code of Sharetribe Go?
Yes. The code is available for a free download in GitHub, just like before.
Can I use the codebase of Sharetribe Go to build a marketplace and charge a subscription fee from the members?
Yes. In this case, the service that you’re offering is not the software itself. Your users are paying to be part of your community and connect with each other.
Can I set up hosting for my customer who wants to run Sharetribe Go on their own server, and charge them for setup and customization services?
Yes. You can build a service business around Sharetribe Go’s codebase, and installations and maintenance can be part of that offering. The only thing that is forbidden is offering the codebase as a SaaS solution.
What about Sharetribe Flex?
With Sharetribe Flex, our other software product, our strategy in terms of licensing has been a bit different from the beginning. Sharetribe Flex consists of two parts: the Flex “Core”, which offers a set of services most marketplaces need, and template apps, which describe the actual user interface and workflow of a marketplace.
The template apps are fully open-source: anyone can download them and modify their software code. They rely on Flex Core for handling business logic and data storage.
Flex Core is a solution built specifically for offering a host of SaaS services for a large number of different marketplaces in a flexible and scalable way. It hasn’t been built to run the backend of a single marketplace, and we believe it would not be a good tool for this job: it would be quite complex to maintain and run it for such a purpose. The equivalent would be running the codebase and infrastructure of the entirety of WordPress.com (Automattic’s proprietary service offering) just to maintain your own blog.
Flex doesn’t suffer from the same lock-in issue as Go since, with Flex, you can always extend your marketplace the way you want by building your own backend and connecting it to Flex Core via APIs. There’s no limit to how much additional functionality you can build to your Flex-powered marketplace.
For these reasons, we have so far chosen not to invest in making the codebase of Flex Core available for download. We may decide to make that source-available at some point if we deem such a move to be aligned with our purpose. However, since we believe Core is only suitable for offering SaaS services for other marketplaces, something that our new license specifically doesn’t allow, this doesn’t seem likely.
Over to you
We know that source-available is a controversial topic that has sparked a lot of healthy debate both in the open-source and platform cooperativism communities. This post is our contribution to this discussion. We are looking forward to hearing your thoughts on this change, and engaging in many fruitful discussions on how to build sustainable, mission-driven, non-extractive software businesses.