The costs of forks

And, yet, the Linux kernel project, which is overwhelming dominated by corporate contributors, doesn't have this sort of rubbish, even in isolated incidents. The sprawling, isolated, self-aggrandizing, profiteering nature of OpenStack development is unique among all past and present open source projects. Projects spin up with unclear definitions, and they expand to consolidate as much political power as possible. Isolating source code repositories, and more importantly, contributor relations and permissions to individual projects was a terrible mistake by OpenStack with expediency, once again, being the prime culprit. In OpenStack, so-called "velocity" seems to be the real development goal.

Here's a few genuine questions that I've alluded to in several of my comments:

1) Why isn't Fuel a strict consumer of modules in PO? Why was the code ever forked?

2) Presumably the answer to #1 includes something about lacking functionality or bugs. Why weren't they just fixed in PO?

3) Why are OpenStack developers so siloed in their own projects? Why don't they contribute across projects instead of forking?

4) As a follow-up to #3, why do OpenStack projects have these sorts of incompatibilities and diverging goals? (In particular, it's one thing to have differences while in development, but OpenStack seems to always have them in released code.)

5) Fuel seems to fundamentally be an expansion of what PO set out to do. Why was a separate project started, and why is it trying to "drink PO's milkshake?" Was there any consideration to expanding the goals of PO, rebranding it, and essentially making Fuel without the need to duplicate so much work?

6) What's the corporate alignment behind Fuel and PO? Who's sponsoring major portions of development? Which corporation(s) started Fuel? Did they have a beef with the corporation(s) behind PO, or more generally, what's their "angle?"

I guess my fundamental opinion is that it's always improper to do this sort of forking within a project. Whether it's the Linux Kernel mm and netdev maintainers or OpenStack Fuel and PO developers, they're fundamentally colleagues and should work towards a unified purpose. If the project in charge of Puppet modules isn't providing the modules the way the consumer wants, then either the consumer is doing it wrong or the producer has a fault design/implementation. The correct decision was always to do work directly within PO, and if the PO developers didn't want to follow your design, Fuel should've been modified to handle that. There shouldn't be Puppet module development in Fuel at all; it needs to be directly contributed to PO. That avoids all the fragmentation, all the stupid merging problems (changing folder structure? that's a paddlin'), and negotiation.

> Best of all, this interest is also very practical: in the space of 6 months Fuel has jumped from not being listed at all to #3 deployment tool used to install OpenStack, Fuel 6.1 contains 1995 bugfixes (compared to 232 in PO during Kilo cycle)

The very last thing I'm interested in seeing from the any OpenStack project or as a whole at this point is, "look at how much our expediency is paying off in the short-term!" This gets back to the political tensions and infighting: Is the goal to entirely displace PO? It sure seems like it, and you bugfix numbers suggest so. This seems like exactly what happened with KHTML. It's forked by Apple and renamed Webkit, which over a much longer timespan, saw essentially all (and overwhelmingly new) development go into Webkit and nothing flowing back to KHTML. I guess, at least, it wasn't another KDE project that ate their lunch and kicked them out of the club.

But, hey, I'm sure they'll be some new project (probably called Gasconade) that will usurp Fuel come the next blue moon.

Of course those bugfixes tilt in Fuel's favor: They're not freaking contributing their changes of forked PO code to PO! How many of those bugfixes would be more correctly categorized as fixes to PO?

A project with a Torvalds, van Rossum, or Poettering would never tolerate this sort of behavior. A submodule implementing their own incompatible fork of something contemporaneously provided is flatly unthinkable. They'd step up and require people to contribute to the lacking submodule directly. The difference is that those projects (and the vast majority of all open source projects) either maintain some independence at the top (eg. Torvalds is employed by the Linux Foundation) or strong commitment to sound engineering principles. Unfortunately, OpenStack is led by a cabal of corporations with extremely selfish, inimical goals.

I do want to end this comment by saying that, while I do use direct language and descriptive words, I do like OpenStack. I just wish that they'd slow down a little bit and congeal the whole project together better. It's getting so big, and you can tell that it's just the corporate sponsors behind development trying to differentiate what their spin can do and outmaneuver their fellow corporate sponsors. Overall, it's just disappointing that the project seems to be turning into a cesspool. I can say pretty confidently where many open source projects will be in 10 years, but I don't know whether OpenStack will establish a more solid base between projects, be a phoenix reborn as something else entirely, or be the abandoned shopping mall where you grew up.