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!
Comments
You are making some great points in this article. Hopefully the fork won't do too much damage to D8. Counting days to D8 release!
I still use the backdrop to advertise
As a drupal developer I can say that I really tried for many days to do a port of an existing v7 module to version 8 and that it failed. Lack of good documentation, guidelines. I even bought some books about drupal 8 development, and yes it helped but not enough to get it to work. Readability of code in v8 is bad, it's more like a spaghetti of files, far from logical. Anyway I'm looking at Backdrop now and yes it's pretty easy to move my existing code to it.
To me, Drupal 8 is like learning a total new CMS. On the outside it was Drupal but on the inside it was something else. It's a pity that they mad the jump to v8 that big as I really liked Drupal....
Apart from the old hook system that has been kept, module development now requires the knowledge of object oriented PHP, the Symfony framework composer and a few other technologies centered around PHP.
I realize this is a lot of new stuff for someone who was doing exclusively procedural D7 programming, but saying that the Drupal APIs and the things I listed above are not well documented might have been right at the time I wrote this article, but not anymore.
If you are serious about being Drupal developer, I encourage you to invest time and look into some OOP PHP tutorials as well as check out how core modules and example modules are written. lynda.com has a few great courses on Drupal 8 module development. These new skills will enable you to take on projects outside of Drupal and will make you a more versatile programmer.
Is the module you are converting a contributed module?
Please excuse if this rant comes off as a bit "defensive", but I personally do not appreciate the tone of the article. Having said that, I do realise that it was written 4 years ago, and many things have changed since. I understand that we do not see eye to eye on this matter, but I wonder if you have taken the time to read https://backdropcms.org/philosophy and try to understand what this means for the various categories of Drupal users (site builders, developers, site owners). Just please try to keep an open mind, and you will realise that there are two sides of this story...
You are very wrong here, but at least you did say "it seems" :D ....well no, that is by far not the main reason; if fact it is not a reason at all. There is no "conservatism" as you say when it comes to features for the end user. There is no fear of ALL things that come with D8 (in fact Backdrop has had CKEditor, CMI and Views in core since version 1.0.0); what does exist though is simply fear of the cost in time and $$ of the change from D7 to D8. If you care to find out more about this, the I suggest you take a read at this article: Change My View: D8 isn't the best upgrade path for 1000 D7 EDU sites ...which explores saving $$ in cases of large-scale installations. To see what this means for use cases on a much smaller scale, also try to consider the impact to groups of people like small business owners (very small budget or no budget), people that have limited knowledge of advanced dev skills but who still want to give Drupal a chance and contribute, as well as devs working in less privileged countries that have only low-end hosting and low-end computers available to them.
My point is this: the fork was NOT a mere capricious move on the part of 2 or 3 people. It was NOT a "Don't go D8" obsession. It is a "Please do not kill D7 while you go D8" cry of many.
Also curious to see what you think of the slow adoption rate of D8 by the way, and how you explain that fact. My personal take is that it is a manifestation of the resistance of many to what seems to be an attempt to create niches/elites of highly skilled developers. But I might be wrong, or this might not be entirely intentional; not by everyone at least ...and at least, although I just stated that it is my personal belief that this has some dose of truth in it, I will never go on saying that this is the main drive behind all the "radical" changes that are (intentionally or unintentionally) excluding a big portion of the Drupal community.
I would not call it attracting, rather than effort to retain those that have already been considering leaving Drupal-land to jump over to WordPress or other CMSes. It is an effort to provide a "home" to people that feel that the "ambitious experiences" are not for them. People that see that Drupal that they have grown to love over the years is actually being steered towards "Enterprise". Consider Backdrop an alternative choice to D8 if you like. I would also ask you this: considering the amount of change in code, would you consider Backdrop to be the fork, or perhaps D8? ...to me personally, D8 is a whole different "product". Mind you that because Backdrop values backwards compatibility, it had an upgrade path from D7 since day one of its existence. D8 on the other hand, is still to this day struggling to get a migration path in place.
This comment in specific made me smile :) ...I know you do not mean bad, but after 4+ years ...well, guess what?
Personal disclaimer: I am not one of the "creators" of Backdrop CMS; I was not making $$ out of Drupal, but was an active member of the community for 6+ years (a total of 9 years, but my contributions during the last 4 years have shifted to Backdrop); Drupal has been my hobby and personal way of contributing to a worldwide community for good; I am now employed by an enterprise-focused digital agency, so I am making $$ out of my Drupal knowledge; Still not making $$ out of Backdrop; I am honoured to have been nominated to become a member of the Backdrop CMS Project Management Committee, and have been serving my role as such, Although I have skilled up over the last couple of years and now speak D8/composer/docker/what-have-you to various extends (still learning), I am still representing the non-dev site builders of the community (point-and-clickers), because that is how I have started; Each time I contribute to Backdrop, I do not think of how it would benefit me personally (not in a "material" way anyway - still getting my thrills about it though); ...what I always have in my mind is how to lower the barrier; how to make it easy for the "small" guy/gal to get into learning Drupal/Backdrop without having a hard time; At the same time, I am trying to convey to them that despite what they might be being told, their skills ARE good enough, they DO NOT need to follow "industry-proven" standards that require more skills, more time, more $$. Backdrop CMS is fun ...same fun as "humble" D7 ...not so much as the "ambitious" D8, but if you start low, and given time, you will evolve from that average Joe/Joette to become the highly-skilled person who at some point will realise that this is actually collaboration, and what they have been forcing on you was actually competition. They just got things wrong ...that is the big picture ;)
I could only find 11 results for 'Drupal 8' on lynda.com, and none had anything to do with module development. Do you know of any others?
Sadly, Drupal 8 and 9 despite their being touted as "Enterprise" CMS solutions, are not really ever going to be secure enough to earn a PCI compliance rating without some extensive hands on systems development and specialized hosting. It can't be deployed as-is securely. Backdrop is more secure due to it's simplicity.
https://www.pcisecuritystandards.org/documents/PCI_DSS-QRG-v3_2_1.pdf
Many years have passed. Drupal even got into joomla. The numbers say what they have to say. Institutions have been moved to WordPress. I tried to upgrade my Drupal7 site several times and failed. I had to remake the blocks. Backdrop cms is on my way. I've moved my site and I'm using it. It was as if I came across an old friend of mine in a foreign country. I'm a Turk. I tried to contribute by translating in Turkish. I did this ninety-two percent. I founded the backdrop cms turkey group on Facebook and the drupal user friends who experimented there loved the backdrop. There is no need to turn this into an ideology. If these are tools, I will turn to whichever is more practical and useful. Drupal is now a system with too many external dependencies. Since the Symfony version will be upgraded, if I say Drupal9 will expire in two years, what I mean is better understood. Also I don't like composer.
I wrote this article 7 years ago. Now we know Drupal 8/9 did not suffer because of the fork that in turn became a home for all of you practical composer avoiders. ;)
I do appreciate that Backdrop serves its niche and in the end any open source contributions should be applauded. Always use the right tool for the job!
That's pretty amazing that I ran across your post and then on the same day found https://github.com/mglaman/retrofit-drupal. It does exactly what you were saying.
@General Redneck This is really interesting, I'm going to look into it. Surprised you found an 8 hour old repo shortly before stumbling upon this here post. One that I now hate by the way; my opinion on things has changed (or in other words: don't listen to past me).
Add new comment