cnr.sh

Comparing Apache, CNCF, and Commonhaus

I've used open source projects for over 30 years and contributed for about 20 of those. My first interaction with an open source foundation was with Apache when I began working with Apache Hadoop in 2008. Since then, I have contributed to many Apache projects, created Apache Samza, and was mentor and project champion for Apache Airflow. I'm also on the Apache PMC. I have less experience with CNCF, though I did apply to donate SlateDB. I later withdrew SlateDB's CNCF application and donated the project to Commonhaus instead. I'm frequently ask for guidance on which open source foundation to donate a project to. I've decided to share my thoughts in this post.

Open source foundations offer a wide range of services. Such services commonly include legal guidance, trademark management, a governance structure, a code of conduct, software infrastructure, funding, grants, community support, marketing, conferences, and a lot more. Some, like CNCF and Apache, are quite expansive. Others, like Commonhaus, are more minimal. Which foundation is right for you depends on your project's needs.

Apache

Apache is the most well known of the open source foundations. It offers most of the services listed above. It's also home to many successful projects, including Apache Kafka, Apache Flink, Apache Hadoop, Apache Spark, and Apache Airflow. The foundation adopts The Apache Way, a set of values and principles that guide operations and decision-making.

I'm fortunate to have worked with Apache as my first foundation. I learned how to effectively manage a large open source project. There is much to consider: licensing, release process, governance, trademarking, issue management, security, communication, and so on. Apache provides you with a framework to manage your project.

Apache's framework is rather rigid, though. The Apache Way requires consensus decision making, open communication, earned authority, oversight from the ASF board, and so on. Even if you like The Apache Way, the requirements often get entangled with burdensome implementation details. Board oversight, for example, requires quarterly board reports that must be submitted through a bizarre versioning process. Open communication has become synonymous with forced mailing list and JIRA usage. (They have begrudgingly adopted some Github support, but not without a lot of friction.) Release process requirements are also annoying. Xuanwo wrote about this in, What did ASF do wrong?, which I highly recommend reading:

What aspects of Apache infra do you find problematic? The requirement to use mailing lists? The LDAP account system? Static-only websites for projects? etc.

What are the pain point(s) that you see with the ASF Infra?

(genuinely curious; I'm part of Infra there)

— Greg Stein (@gstein) July 27, 2024

One of the paradoxes of Apache is that it does such a good job educating developers that they eventually outgrow it. Once I became more adept with open source project management, I found that I wanted to customize it to my project's needs. I was educated enough to decide which license was appropriate, how communication should be handled (using Discord, for example), how consensus policies should work, whether companies should be involved in roadmap planning, and so on.

Learn the rules like a pro, so you can break them like an artist --Picasso

BDFL

Apache simply doesn't allow you to make these choices. As my work on Airflow died down, I swore I would never do another foundation. Instead, I committed to being a benevolent dictator for life (BDFL) for all future projects. The BDFL model was popularized by Guido van Rossum, creator of Python. Many successful projects have BDFs including Ethereum, Clojure, Django, Zig, Ruby, and even Linux.

My commitment to BDFL conflated two things, though. A benevolent dictator is a governance model, not a foundation. Even Python, which pioneered the BDFL model, has the Python Software Foundation. If you go with the BDFL model, you still need to manage and promote your project--the stuff I listed above.

Rohan Desai (co-founder of Responsive) and I bumped into this reality when we started SlateDB last year. I had planned to be BDFL for the project. I was independent of any company and was committed to keeping the project open source and not for profit. As the project grew, I realized I wanted two things:

I explicitly did not want The Apache Way. In particular, Apache outright denies any direct company involvement; The Apache Way says, "individuals participate at the ASF, not organizations." This is a farce. Many of their projects are dominated by a single company. I wanted SlateDB to welcome companies as a partner, not treat them as a threat. Moreover, I didn't want to deal with the frustrating infrastructure requirements I listed above.

CNCF

I began to investigate CNCF.

Anyone out there have experience with CNCF? Would recommend? Thoughts vs. Apache?

I'm lookin for a home for SlateDB. Ideally something with a lighter touch than Apache. Main goal is a foundation to own the code and a governance model so multiple companies can commit.

/cc @wm

— Chris (@criccomini) July 27, 2024

William Morgan, co-founder of Buoyant seemed to have some good things to say about it. Nick Schrock also recommended it. Chris Aniszczyk even messaged me to offer his support.

Very positive. Bring your own governance is real. Apache is ridiculously heavy. They force you to use Jira!

— Nick Schrock (@schrockn) July 27, 2024

Though CNCF is vendor neutral, they at least acknowledged that companies and their open source projects both exist. The CNCF also offers excellent templates for project governance and guidance on security. These templates and guidance seemed much more flexible than Apache. I filled out the sandbox form.

Unfortunately, I found much of the same bureaucracy that Apache suffered from. There are a dizzying amount of acronyms to learn (TOCs, TAGs, and so on). There are four different stages to a CNCF project's life cycle: sandbox, incubation, graduation, and archive--more than Apache has! We were asked to present on the project at a CNCF TAG meeting, which we were happy to do. But much of the meeting and sandbox process focused on bizarre questions like whether SlateDB was "cloud native." The sandbox application took much longer than I expected (it was still ongoing after 3 months). I've also heard (though did not experience) a pay-to-play atmosphere.

My takeaway was that CNCF is Apache with better infrastructure. There's nothing wrong with this, but it's not what I wanted. I decided to withdraw the application and look for another option. I also gave my feedback to Chris.

👍 mostly I found the nit picking about whether slatedb was cloud native to be a huge turn off. Sees patently obvious to me. Gave me strong Apache bureaucracy vibes. Exactly what I was trying to avoid.

— Chris (@chris.blue) Nov 27, 2024 at 9:42 AM

My feedback regarding speed is that CNCF some how managed to have more project maturity layers than Apache, yet sandbox feels just as heavy as Apache's Incubator. IMO, sandbox should be way faster and lighter touch. Save more of this stuff for Incubator.

— Chris (@chris.blue) Nov 27, 2024 at 9:48 AM

Commonhaus

Gunnar Morling had been pushing me toward Commonhaus. When Debezium joined, I decided to give it a closer look. I loved what I found. Their two first principles are:

They also encourage, "minimum viable governance." While Apache had a heavy process and poor infrastructure, and CNCF had a heavy process and good infrastructure, Commonhaus seemed to have a light process and no infrastructure. This was what I was looking for. A foundation that could help with my legal requirements, own trademarks, and give me guidance when I asked for it. They also offer license flexibility; they'll support any OSI-approved license. Vendors that want to use AGPL or GPL are welcome. License flexibility wasn't a requirement for us, but it's worth noting. I applied for SlateDB and was quickly accepted.

It's not all roses, of course. Commonhaus is very young, so it could grow a lot of bureaucracy. Some of this is inevitable; trademark ownership requires some measure of control over the project. The foundation also seems fairly dependent on Red Hat. They need to figure out sustainable funding. Where Apache became synonymous with Java and big data, and CNCF explicitly focused on cloud native technology, Commonhaus might evolve some specific focus that doesn't suit SlateDB. Thus far, it's been a great experience, though.

tl;dr

So, which foundation is right for you? As staff software engineers say, "it depends". I started to write out a full decision tree, but there are too many variables to consider. Instead, here's some vibes-based guidance:

This list is non-exhaustive. I'm sure there will be much to quibble over. I also acknowledge that these foundations are run by volunteer community members. I really do appreciate their work and sincerely wish them success. I hope open discussion will help facilitate their growth.

Changelog