AlmaLinux makes its choice: The friendly fork

The AlmaLinux project, after taking some time to think it over, has decided to pursue RHEL compatibility but is no longer aiming to be 1:1 “bug-for-bug” compatible with RHEL. Be sure to read their announcement from Chair of the Board, benny Vasquez. Board minutes are also available.

What now for AlmaLinux?

A number of folks are asking why you’d choose AlmaLinux over CentOS Stream, if they’ve dropped the goal of 1:1 binary copying.

For one thing, this gives AlmaLinux leeway to evolve beyond RHEL and be its own distribution. According to the post this opens the door to “a ton of exciting developments and partnerships” that will be announced in the future.

Just for starters, the aim of RHEL compatibility without being 1:1 would open the door to AlmaLinux shipping with packages not found in RHEL. They could opt for “roles” not offered by Red Hat in RHEL, or to offer additional kernels. They might move faster on bugs or other issues.

Alma could become the “community enterprise Linux” in a way that CentOS Linux, as a 1:1 clone, couldn’t. AlmaLinux could become a standard in its own right, if the larger community and industry is willing to make it so.

The friendly fork

It’s too early to tell, but I’m eager to see where AlmaLinux goes. I feel like they’ve made the right decision, and one that allows them to grow their own community and chart their own direction.

It wasn’t too long ago that “fork” was a dirty word. A company or project had to have a good reason to “fork” an upstream without appearing hostile. Building something on top of an upstream project was met with “isn’t that just a fork of $project?”

But the Alma community has chosen to be the friendly fork. Rather than throwing stones at Red Hat and trying to drag another member of the open source community down, they considered the options carefully and came up with a solution that looks like it can be good for everybody.

After all the stone-throwing and heated rhetoric of the past week or two, it’s refreshing to see a project that wants to steer people away from rage to “something positive.”

My current employer, Percona, takes a similar tack with MySQL. Oracle has a community edition and enterprise edition. The enterprise edition is not fully open source. Rather than demanding that Oracle release all its source code and allow us to build a 1:1 clone of MySQL to support, we take the available code and add features. We fix bugs that are reported to us, and try to submit them upstream – but also turn those around to our customers in a reasonable timeframe whether Oracle takes the patch or not.

We want to be compatible with MySQL but aren’t claiming exact “bug-for-bug” compatibility. This gives users and organizations a choice.

In October, Oracle will stop supporting MySQL 5.7, but we offer extended support – which is possible because MySQL is (not counting enterprise edition) open source.

The MariaDB folks took another path, which started with MySQL but has evolved in its own direction. Substantially similar, but not trying to be 100% compatible either.

Maybe Alma will follow Percona’s path of staying very close to the upstream while adding value of our own. Maybe Alma will evolve off into its own branch of enterprise Linux. Who knows? Maybe it will overtake RHEL and CentOS Linux in usage.

Either way, I applaud the approach they’re taking. Kind of feels like what Ted Lasso would do, if Ted Lasso decided to get into the open source business after football.

Update 16 July 2023: Changed “similar tact” to “similar tack” after a kind reader noted I’d gotten the word wrong there. Thanks!

Leave a Reply