Do we need a new open-source license? Amazon Vs. Elastic Part II

(4 Min read) Apache 2.0 vs SSPL vs ?? Which is right for protecting OSS future.

You can find Part I here. As promised, here are the open questions from the previous post.


Is SSPL really the right answer?

Elastic is not the first company to change its license to SSPL. Mongo did this back in 2018. I couldn’t find any information on how changing to SSPL helped Mongo grow their business. Maybe it did, maybe it didn’t. Only Mongo knows. MongoDB (MDB) stock price is not a good indicator. 

That said, I still don’t think SSPL is the right answer. If the goal is to make more money, is changing the license the only answer? I doubt it, especially if you care about open-source. It seems like SSPL is going to create a bigger divide between what’s in the open-source version versus what’s behind the company walled garden.


Can Amazon scale? 🙀

Wait!!! Hear me out. Amazon, in their post, mentioned that they would fork ES and kibana. Amazon will invest in delivering new features, fixes, and enhancements. Yes, they have money, but is this a scalable model? 

What happens if Confluent (Kafka) or Astronomer (Airflow), or other open-source managed service companies decide to do this? Will Amazon continue to allocate resources to fork and support every one of them? If yes, will it scale?


What does this mean for the next generation of startups?

If the companies continue to go down the SSPL path and Amazon continues to fork and support OSS, then the next generation of companies will suffer big time.

Let’s walk through three scenarios on what it means for the next-gen startups. The startups I am referring to are the ones who are using these open-source software and are not Amazon or managed service company.

  1. As a startup, you decided to use the SSPL version. Life is fine until you have to scale. Scaling needs more operational overhead, but being a startup, cannot hire a team to manage it. The only thing you can do is go to the managed service company. Hopefully, their version is not too different from what you currently have deployed in production. If it is, you are screwed. You don’t want to migrate. Remember, you are a startup. Even if the company migrates you, you are still screwed. They can continue to increase the prices of service offerings as they know you can’t change vendors. There is no other vendor. And they know you can’t go back to managing it yourself.

  2. As a startup, you decide to use a forked version of AWS. The same reasoning as above, but now the only option you have is AWS managed solution. With versions figured out and migration complete, now you are on AWS managed services. Things are fine until AWS decides that the managed service is no longer profitable. Now, you can’t go back to managing it because you are a startup, and you can’t change to the managed service provider because the two versions are not compatible. What do you do?

  3. You decide to migrate from the SSPL version to AWS forked version or vice-versa. You have my condolences. I feel sorry for those engineers. I would rather be on a spaceship to Mars than on the team that migrates.

Now you may be wondering if the problem exists today?

Yeah, but in a tiny way. All OSS is mostly backward compatible with some minor breaking changes. But what you don’t have today is the vendor lock-in problem. 


Why is it important for Open-Source projects to turn into businesses?

This is a big question. It deserves a full-length post by itself (sometime in the future).

When an open-source project is new, it attracts developers. But over time, developers move on to build new things. Every successful open-source project needs a company to back it up. Google has done that with Kubernetes.

If we don’t let developers convert these open-source projects into companies, no one will support and promote these products. Overtime (<5 years), each project will become stale and abandoned. There will be more software in the open-source graveyard.

We, as a software industry, heavily rely on open-source for growth. The biggest challenge when adopting open-source software into the company is ensuring that the OSS will be supported by the community in the future and not get abandoned.

Relying on any single company to support all open-source is just not possible.


What does this mean for open-source? Do we need a new type of license?

To me, SSPL or Apache v2 doesn’t seem like the right kind of license for open-source in 2021. APv2 is heavily biased towards the developer community as SSPL towards the business.

It seems like we need a new type of license that can

1/ Keep the open-source community open and prevent fragmentation of software.

2/ Enable some of these projects to become a business one day, and

3/ Prevent cloud giants from monopolizing the market.


So what next?

Honestly, I don’t know. As an engineer and open-source supporter, I don’t think SSPL is right for the OSS community nor forking it the answer. I truly believe that this is a big change that can potentially change the software industry forever.

I still have a couple of more things to share on this topic. Things like:

  • What can Elastic do (possibly) if they don’t switch to SSPL?

  • What can Amazon do to show they care about open source?

  • What kind of license will help open-source projects?

  • And many more.

Stay tuned for part III.


If you have ideas, opinions, views, comments, suggestions, please share. Let’s collaborate to create a new-open-source license together.

If you find this post interesting, please share it with an open-source enthusiast. We need all the support we can get.

Share

Till next time, take care and be free… ✊