Why forking Drupal into Backdrop is a bad thing
Please note the date of the article - it may not be current nor does it necessarily reflect the author's current opinion on the matter. See this comment.
The ability to fork is a wonderful thing.
In the open source community, the ability to fork software projects is a wonderful thing, as it allows taking a software snapshot in a completely different direction from what was intended by its current maintainers.
Projects get forked for reasons that can be categorized in political (changing ownership rights, controversial decisions made by the project maintainers, etc.), technology related (where maintainers disagree about the direction of development and implementation) and personal.
Forking is a bad thing.
Wait... did you not just say forking was wonderful?
The ability to fork is wonderful, as it gives great power to the community. But forking itself is bad for the project, as it results in two projects with weaker development and support, a weakened potential to grow and a divided and confused user base. It leads not only to separate code bases, but also to a divided developer and user community and should be considered last resort.
In the best case scenario, forking is choosing the lesser evil.
No matter how much effort is put into collaboration between the fork and the original project, in the end it always ends in lack of compatibility and refusal to provide support to confused users in the different camp. This is why the Backdrop creators' reassuring statements about cross contribution should be taken with a grain of salt.
Why is forking Drupal into Backdrop a bad thing.
I will not spend much time summarizing the motivations behind Backdrop - go ahead and take a look here. The problem with these motivations is that, using my previous attempt to categorize reasons for forking, they are very technology related. In essence it seems the main reason is conservatism and fear of all the new things that come with Drupal 8:
Drupal 8 is using many new libraries and established technologies instead of further developing its own ones - bad.
Drupal 8 is utilizing OOP - what is it and who needs it? Writing loose functions in hooks has been working fine so far, why change that?
Drupal 8 is not backwards compatible (quelle surprise). Maybe I should have stayed with Wordpress. Nah, Iet's fork Drupal instead.
Drupal 8 forces established developers to learn something new. Obviously it's more convenient to do the same thing over and over instead.
Why fix if it ain't broke? I hear all the time.
In IT one should change something as soon as it is out of date instead of waiting until it breaks. Drupal has established itself as a bleeding edge CMF and bleeding edge often means utilizing new technologies, a scalable programming paradigm (hello OOP) and breaking backward compatibility. It also means that one has to relearn stuff sometimes. If I do not want to relearn stuff, I do not go into IT and certainly not Drupal.
Let me quote Dries' opinion on embracing change from his blog post:
The reason Drupal has been successful is because we always made big, forward-looking changes. It’s a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.
It is impossible to assess how harmful a fork will be for the future of Drupal, if Backdrop succeeds in attracting even a small fraction of our developers and users. A lot of potential may be wasted on a project whose existence is not really justified. More probable however will be the fork's natural death.
What action should be taken instead?
When publishing your first Drupal module, it first has to go through a tough process, in which among other things, the community thoroughly tests whether it is duplicating functionality of other modules. Quotes get thrown at contributors like 'collaboration over competition'. The process takes a long time in which many projects are discarded and often rightfully so.
Dear creators of Backdrop, why not apply this 'collaboration over competition' philosophy to the bigger picture, and instead of forking Drupal, be more present in the discussion groups and steer the development of Drupal 9 into the direction you feel comfortable with? If you find that the bigger part of the community is not interested in having it your way, how about contributing an api module, so that the minority in question can profit? You can create a community around a module inside the Drupal ecosystem and be successful with it. If time shows your ideas to be of great value, they will be ported into core.
Backdrop is not about users, it is mainly about developers refusing to adapt and invest their time to further improve the Drupal platform. My appeal to them is not to hide behind claims like 'no backwards compatibility' or 'too complex to learn' and instead of dividing the community, start contributing to the bleeding edge Drupal platform we have learned to love.
Feel invited to discuss in the comment section!