Like many other Drupallers, I'm in Nashville this week. Unlike previous DrupalCons, I'm less excited about being here than previous year. While my team at the University of Colorado Boulder currently manages 1000 D7 sites, it looks increasingly less likely that we'll be upgrading to D8.
Angela “Herder of Cats” Byron recently tweeted...
OK, time for our semi-annual poll/group therapy session. ;)— webcsillag (@webchick) March 9, 2018
What are the 5 top things you or your clients run into problems with on #Drupal 8?
The last time she tweeted this, we responded with a few specific issues we had at the time. After maintaining a handful of D8 sites in production for a few months and meeting with 20+ developers and designers from teams at all campuses in the University of Colorado system earlier this year, we now have a more comprehensive list to answer the question of why the University of Colorado Boulder isn't moving forward with updating the Express install profile to D8.
We've already written and presented about some of these, but my goal at DrupalCon is to find people who will convince me that we're wrong or point out what we're missing. I can't emphasize this enough that we really want to be proven wrong and pointed in the right direction about some of these so we can stop evaluating options other than D8:
I wish moving from D7 to D8 was an obvious move for us. It would make my job much easier. After watching the normal stability requirements ignored to sneak Umami into 8.5 and realizing that the initiatives DA was promoting for core (automatic updates, project browser, telemetry and in site announcements from the DA) are NOT features we'd use in our service, it's becoming increasingly clear our needs no longer align with what is driving the priorities of the Drupal project. When I evaluate D8 through the Umami demo, it's clear that we aren't even the target audience for what the project wants to highlight to people evaluating it. When we evaluate a framework, product or service, part of what we evaluate is the cost to maintain. When fatal errors are acceptable in a demo after a core update, we question whether we'll be able to easily apply upgrades if the developers most familiar with this framework can't upgrade the demo?
It's not that the entire University of Colorado system is against D8 either. Both the University of Colorado Colorado Springs (UCCS) and Auraria Library are both using D8, but for very different use cases than the Web Express service we offer for free on the Boulder campus.
UCCS is moving from Ingeniux to D8. For those of you who aren’t familiar with Ingeniux, it is a XML/XLST static site generator with limited features for dynamic content. UCCS initial D8 offering has similar limitations to Ingeniux, but they are leveraging Migrate to move sites from Ingeniux to Drupal very quickly. They are also hosting their Drupal 8 sites themselves on the most advanced server architecture within the CU system which well set them up well to add new features in the future.
Auraria Library is another high profile D8 site. This site has more features and functionality than the UCCS sites, but it also has a small development team supporting a small group of content editors and is hosted on Pantheon.
While D8 makes sense for both of these use case, neither of these groups had insights on how we could overcome what we think are D8's short comings for the ~1000 sites we manage for the University of Colorado Boulder.
While I'd prefer to continue maintaining D7 sites while developing new projects in D8, the lack of clarity from the DA around the EOL of D7 is forcing us to invest time in evaluating alternatives now. When I read that Symfony 4.1's router is now the fastest PHP router, I get both excited and terrified. I'm excited since, in some ways, this would prove everyone that pushed to get off the island and collaborate with the larger PHP community right. I'm terrified because I realize that Drupal going from Symfony 3 to Symfony 4 most likely means D8 to D9. If D9 means the end of support for D7 and quarterly justification for running software our security team views as insecure, we have to go all in on a direction other than D8 soon.
We've spent some time trying to answer the question, "if not Drupal, then what?" If we can't figure out how to make D8 work for us, I'll post more about what we found when evaluating alternatives to D8. This week, I'm focused on trying to make D8 work well when hosting Drupal as a Service in higher ed.
If you see me at DrupalCon, PLEASE change my view. I won't be hard to spot.
I've started a thread on r/drupal/ for everyone who's not at DrupalCon.