Ask HN: AGPL – Alternative to Commons Clause for OSS Infrastructure Projects? | Hacker News Reader

Ask HN: AGPL – Alternative to Commons Clause for OSS Infrastructure Projects?

1 pointpritambarhate1 comment

For the last couple of days, there is a heated discussion going on HN about Commons Clause. As per https://commonsclause.com/:

>> For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software.

Though as a user I don't like Commons Clause, it made me think why some companies are opting for it.

For Open Source Infrastructure Projects like Databases, there are very few revenue models. Here are the ones I can think about:

1. Keep certain features Enterprise only 2. Enterprise Support 3. Hosted PaaS platform

If one goes with option 1, then it can become an adoption hinderance. For example, I have never seriously looked into Influx DB, as they kept Clustering a paid only feature. If I am making something a core piece of my infrastructure then I want to be able to scale it without paying enormous fees. I may choose to do it if my business model allows it, but I don't want to be forced into that option.

So to encourage adoption, I wouldn't want to go with option 1.

That leaves options 2 and 3. Enterprise Support model is very hard to scale to billions of USD scale. As it needs expertly trained humans to scale. But still, it can lead to substantial revenues. However, with open source core, it can take decades to reach the billion dollars scale with just enterprise support.

[Ran out of space. Please see the comment below: https://news.ycombinator.com/item?id=17829847]

[Continued from the Post]:

I think Hosted PaaS platform is the most scalable of the 3. Once you figure out core features needed by the vast majority of your users, you can automate these nicely and build a company worth 100s of millions of USD relatively quickly. This gives you substantial revenue to become self-sustainable. From this point onward, you can take the long-term enterprise support approach to scale it further. The bigger users who can't fit in Hosted PaaS model can always go for option 2.

This is the reason I think Database companies like RedisLabs and Dgraph have chosen the Commons Clause License. They essentially want to keep options 2 and 3 to themselves while giving away the full set of features for those who want to master the operations of the software only for their in-house use.

I think VCs have seen that the Open Core model is very hard to scale for core infrastructure projects. Bigger cloud players can put a lot of money to provide hosted PaaS for "popular" infrastructure projects. Since these cloud players have years worth of reputation going for them, users trust them more than a small VC funded startup (or an untrustworthy one like Oracle). We have seen this with MySQL (RDS and Aurora, and other cloud players) and Docker (Kubernetes Vs. Swarm).

However I think, Commons Clause is the wrong way to approach this as it prevents "consulting" companies to earn from the software. In Enterprise, generally new infrastructure software is introduced via consulting route. So it can help to create evangelists for your product.

It seems Mongo DB is executing things successfully with AGPL. As per this link: https://investors.mongodb.com/news-releases/news-release-det...

>> First Quarter Fiscal 2019 Financial Highlights Revenue: Total revenue was $48.2 million, an increase of 49% year-over-year. Subscription revenue was $44.6 million, an increase of 53% year-over-year, and services revenue was $3.7 million, an increase of 14% year-over-year.

There are projects like Cockroach DB (Core) and Kafka who have gone with Liberal Apache License. Only future will tell how it affects them.

What do you guys think?

Reply on news.ycombinator.com