Drupal Public Data, Statistics & Silver Linings? An Exploration #6

This is the final installation of a multi-part article that examined Drupal public installations data in search of actionable insights. The previous parts can be accessed from the following links: Part 1 | Part 2 | Part 3 | Part 4 | Part 5.

Preamble

Previously, this article presented and analyzed Drupal installation data.  It introduced ideas from economics, statistics and mathematics to help compose models to "fit" that data. It touched upon the remarkable "Drupal 7 situation" confronting the Drupal Project.  It introduced models drawn from Economics, Finance, Philosophy and Psychology to help explain and contextualize its approach.  In this segment we bring the article to a close by introducing and discussing the choices that the Drupal Project faced in 2024, and the likely reasons why it chose the denouement for Drupal 7 that it did.  The article concludes with a brief discussion of the repercussions of that choice, and some broader lessons for Free and Open Source Software stakeholders. 

2024

After years of begging, cajoling and even quasi-threatening its customer base, the Drupal Project found itself in 2024 still facing its "Drupal 7 Situation" with no end in sight.  By that point, it had become crystal clear to the Drupal Project that a large contingent of its Drupal 7 customers, in the absence of something momentous, were not willing to migrate to a more modern version of Drupal.  

What may also have started coming into play by that time, especially among the more commercially sensitive, educated or self-aware contingent of the private/public agglomeration known as the "Drupal Project", was a psycho-social realization of the realities of the various models ("sunk cost", "5 stages of grief") introduced in this article.  Regardless, the two options remaining to the Drupal Project at that point had been reduced to:

•    Teleportation
•    Abandonment

Perfect Teleportation Model

In the "Perfect Teleportation" model, the Drupal Project would have taken an active leadership role in terms of facilitating the move of legacy Drupal 7 websites to the latest version of Drupal by investing its own talent, time and money into the effort, resulted in hundreds of thousands of Drupal 7 websites being "teleported" to Drupal 11.

Figure 11:  95% of Drupal 7 Installations "Teleported" to Drupal 11

Here's what things would have looked like if the Drupal Project had been able to "teleport" 95% of Drupal 7 installations to Drupal 11 (with only the most stubborn "Drupal 7 clingers" staying behind):

This is a really beautiful adoption curve.  Any project would love an adoption curve like this.

How Feasible is "Perfect Teleportation"?

While the "Perfect Teleportation" model does indeed produce a really beautiful adoption curve, it is entirely unrealistic.  We know this because we know about the Innovation-Adoption Curve, which informs us that, at any given instant in time, only 50% of any population is willing to adopt a new technology, regardless of how great it is.  

Realistic Teleportation Model

Given our understanding of the Innovation-Adoption Curve, let's utilise it to frame a "Realistic Teleportation" model that reflects the dominant constraint for innovation adoption (human nature, or "pull") rather than the one used by the Drupal Project (technology readiness, or "push").  Using that perspective, we understand that, at best, only 50% of the Drupal 7 community would have been tempted to be "teleported" from Drupal 7 to Drupal 11 at any given time—even if the Drupal Project were responsible for everything involved (time, effort, cost).  

Figure 12:  50% of Drupal 7 Installations "Teleported" to Drupal 11

Here's what things would have looked like if 50% of Drupal 7 installations had been "teleported" to Drupal 11:

This is not a beautiful adoption curve, even though the Drupal Project (theoretically) had invested a massive investment of time, effort and cost.

How Feasible is "Realistic Teleportation"?

Unfortunately, the "teleportation" idea is also pretty unrealistic, due to the following considerations:

• It demanded money that the Drupal Project may not have had
• It demanded time that the Drupal Project may not have had
• It demanded talent that the Drupal Project may not have had
• It demanded technology that the Drupal Project may not have been able to create
• It demanded an organization that the Drupal Project may not have been able to produce
• It would have created problems that the Drupal Project may not have been able to resolve 

Abandonment Model

With the "Perfect Teleportation and "Realistic Teleportation" models dispensed with, we arrive at the last and final option for the Drupal Project, the "Abandonment" model.  Given the constraints and challenges faced by the Drupal Project, this model was very likely always the inevitable choice.

On the upside, picking the "Abandonment" model opened many new options for the Drupal Project:

Business Model Options 

• The Drupal Project could choose to drop all costs related to Drupal 7
• The Drupal Project could choose to adjust its reach by ignoring the Drupal 7 community

Policy Outcomes 

• The Drupal Project could choose to officially cut Drupal 7 away via EOL announcement
• The Drupal Project could choose to issue periodic warnings to motivate defections
• The Drupal Project could choose to allow market forces to play out

Community Outcomes

• The Drupal Project could leave "Drupal 7 clingers" to figure out their own survival strategies
• The Drupal Project could officially nominate 3rd parties willing to offer Drupal 7 LTS support

How Feasible is The "Abandonment" Scenario?

The "Abandonment" model was ultimately chosen by the Drupal Project.  It became the new reality.

Evaluating the New Reality

Recalibrating the Drupal Project

Abandoning the Drupal 7 community afforded the Drupal Project with the opportunity to recalibrate its growth model:

Figure 13:  Recalibrated Growth Model (Drupal 7 Removed)

Abandoning the Drupal 7 community afforded the Drupal Project the opportunity to compare its actual installations against its new growth model:

Figure 14:  Recalibrated Growth Model vs. Actual Installations

Abandoning the Drupal 7 community enabled the Drupal Project to exceed its growth model starting with Drupal 8, with Drupal 10 actually doubling expectations.  While it is still early days for Drupal 11, it is not unreasonable to assume that it will continue to meet or beat model expectations.

The Big Picture

Did the Drupal Project Make "Good" Choices?

This following graph that depicts all recorded Drupal installations over time, along with a trend line:

Figure 15:  Drupal Installations Over Recorded History

Using the graph and trend line as sources of information, certain findings become apparent:

• Drupal installations grew very rapidly until about Q2 2015
• Drupal installations peaked (on trend) in Q1 2017
• Drupal installations peaked (in absolute terms) in Q2 2018
• Drupal installations have been shrinking since mid-2018
• Drupal installations in 2024 fell below those of 2012

These findings would not lead many people to state that Drupal has always made good choices.  In fact, after integrating the findings, some might be tempted to state (with some justification) that:

• Drupal 7 was (and remains) "peak Drupal"
• The decline of Drupal corresponds with the life cycle of Drupal 8
• Drupal has been in a state of constant, slow decline ever since Drupal 8 was released 

Ending on Positive Notes

Here are some of the positive notes, (or "silver linings") that this article has been able to find:

Excising Drupal 7 Results in Good Numbers for the Drupal Project

Looking at the Drupal installation data reporting with the Drupal 7 install base removed reveals a positive story.  The Drupal Project has consistently outperformed growth expectations, albeit upon a smaller footprint. But reframing the Drupal Project this way has instantly transformed it from a "Project with a Problem" into a model-beating leader in the CMS industry. The value inherent in a perspective shift such as this cannot be understated. 

Modern Drupal Will Probably Experience Strong Growth in 2025

Drupal 11 is very likely to experience strong growth in 2025. One of the reasons why is Drupal 7 defections to Drupal 11, which will be arriving from "outside" of the newly calibrated growth model. The Drupal 7 EOL announcement, which occurred on January 05, 2025, is likely to further spur the movement of installations from "invisible" Drupal 7 to "visible" Drupal 10 or Drupal 11, acting as a tailwind to what would otherwise could only be organic growth.

LTS Options are Becoming Available to the Drupal 7 Community

Long-term support Options for Drupal 7 Website Owners have popped up, and will continue to do so for so long as there is an economically viable Drupal 7 community to serve. The Drupal Project approved vendor, TAG1, is an obvious example, and many other options are sure to emerge should the Drupal 7 community prove to be persistent and economically viable.

Some Final Observations

For My Audience:  Thank you 

For those who have stuck with this article through its many twists and turns...thank you for your time, patience and consideration.  This article was originally proposed at something like 1,500 or 3,000 words and about a month to deliver.  As the article was developed, it grew to well over 10,000 words and spanned several months, continents and seasons. My gratitude and thanks go out to everyone who helped make it happen (especially the people at The Drop Times), and the audience who patiently awaited its happening. I hope you feel it was worth the wait. I certainly do.

For Software Producers:  Realistic Adoption Models Please

One of the more important concepts explored in this article is human nature and its dampening effect on technology adoption. Software Producers should heed the lessons learned by the Drupal Project when confronting its "Drupal 7 Situation", because it parallels the "Windows XP Situation" and "Windows 7 Situation" that Microsoft faced in the past.  

As we know now, the "technology push" model:  A 2-year "live cycle" followed by a 2-year "support cycle" that is currently being championed by major software houses, bears little actual resemblance to the "technology pull" reality of how people consume technology. For 95% of any population to abandon a legacy technology, a substantial amount of time must be allowed for every category, except for the laggards, to exit. This duration of time can be measured in decades, especially when the technology being replaced is mature, feature-complete and continues to be useful.  

This is a very important consideration for those tasked with spurring innovation adoption: While cumulative adoption rates of more than 50% are entirely possible, they are typically achieved over very long timeframes, only once the replacement technology has been proven to be demonstrably better, and only after the legacy technology is more expensive to keep than replace. Many Drupal 7 websites remain 100% functional and "fit to purpose" to this day, so any claims on the part of the Drupal Project that modern Drupal is "better" can legitimately be challenged with the questions, "Better for whom? You or me?" Because the Drupal Project never had meaningful answers to those questions, the Drupal 7 community didn't budge, resulting in the "Drupal 7 situation".

What new technology promoters need to appreciate is that the "Drupal 7 Situation" could very easily happen to them if they fail to respect human nature, the many different dimensions of which have been reflected in the various models introduced by this article.

What to Do When Open Source Projects Are “Abandoned”

The "Drupal 7 Situation" has brought to light an increasingly common situation in Open Source—what is a Free and Open Source Software stakeholder to do when the project they rely on has been abandoned?  

Several ways and means have emerged:

• Some people choose to "transfer" the project from "old" maintainers to "new" maintainers, which seems like the ideal way to keep a project alive with the least amount of complications.
• Some people choose to "fork" the project, which can lead to a confusing balkanization of the project where consumers do not know which "fork" to stick with or adopt, not to mention the "with us or against us" type politics that often accompany a project fork.
• Some people choose to "take over" the project, with the mechanisms used to accomplish that takeover relying on the arbitrary exercise of power on a common hosting service or repository.

In many cases, the legal rights of the individuals who originally contributed to the project may be compromised or even violated, although very few cases involving these circumstances have been tested in a court of law.  The overwhelming majority of cases are simply not brought. I suspect this because the cost of bringing a case exceeds the financial benefit of winning it.

We face a slow-moving crisis in Free and Open Source Software because the original framers were primarily concerned about protecting the interests of the producers of Free and Open Source Software, rather than the rights of the consumers. There is little recourse available to a consumer of Free and Open Source Software when faced with disinterest on the part of its producer. 

It would be great if some of the thought leaders of the Free and Open Source Software community could reflect on this situation and propose a considered, planned, and common policy for the community to discuss, adjust, and potentially adopt.