Gut feelings about Drupal 8

When the question When is D8 ready? was asked during a leadership Q&A session at DrupalCon Prague, the responses were testament to an orchestration of unity. None of the house-trained members of the panel dared to go beyond the “it’s ready when it’s ready” response.

At flink we're not afraid of speaking out for the sake of some great debate.

So here are some thoughts we have. Caution: may provoke. The comment box is open!

The fly in the D8 ointment
As much as we love the initiative and the people behind it, we believe that Backdrop will, for now, not flourish as a viable future platform. Right now, Backdrop appears to lack real backing in terms of people and $$$. Two weeks before the expiry of the funding campaign, less than $5,000 (10%) of the requested fund injection has been pledged. Also, repository commit activity has dropped off.
D8 commits are plentiful with more (although perhaps still not enough) people working on it and some $$$, from direct and indirect sources.
Backdrop doesn't seem to have a contributed module community to go with its core, yet. Mind you, at this stage D8 "embracement" is also mostly by default. Only 3% of D7 modules ported, not very forthcoming...
The colossal merit of Backdrop has been that its announcement --together with its initial credibility— shook up the community.
Result: Backdrop will make D8 better for all of us.

Little harmony in Symfony
In hindsight, the touting of technologies like Symfony, Twig and more OO in D8 ended up like a shot in the D8 foot.
Rather than these being seen as harbingers of great developer and business value alike, they were predominantly received (incorrectly) as the bane of the D7-to-D8 developer. The resulting grumbles from developers and site-builders and the education and pacification efforts in response to this, have taken the wind out of the sails of a sunny D8 roll-out. It has businesses using Drupal around the world wondering about D8 ROI.
It has also resulted in many a “Come learn D8 with us” training course. Is D8 becoming the new SAP? ;-)

 

Not a win-win situation… for now
The interim winner of the D8 tardiness vs. the Backdrop spanner in the works is, sadly, neither of the two. It's old D7.
Since the first of these Tech Debt snapshots was taken on 18th August 2013, today 26th October, 43 ported modules appeared on the D8 scene, versus 478 brand new ones in D7. That's eleven times as many. What does that say about where our communal mindset is focused at the moment?

Spearheaders
Amongst all this, it so very heartening to see real, working D8 sites popping up now. Some of them share on their pages accounts of the D8 journey they’re on. These are just some we came across (let us know if you know more): http://yuriybabenko.com, http://running-on-drupal8.co.uk, http://chertzog.com
Thank you so much guys -- keep sending that beautiful message!

Core doeth not a website make
We feel that “When is D8 (core) ready?” is the wrong question to focus on. Instead ponder this: “When is D8 fit for my purposes?” You will agree that the answer lies in how many of your unmissable contrib modules you'll be able to use on your target date. There is no backward compatibility, no pick and mix with the old. The contrib modules YOU need must be ready when YOU wish to progress to D8. The great news is that there is enough stable D8 core out there to get cranking with contrib. There is no need to wait until the D8 core official release date is announced before jumping into action. Hell, your favorite contrib modules could be ready for use before D8 is released!
It is not an insurmountable task. And it can be accelerated. Initiatives for this exists. We like TSM. But help in whatever way you see fit. Let's get this show, your show, on the road.

                                                                 * * *

Picture: FreakingNews.com

File under: 
Planet Drupal

Drupal 8: to embrace or to brace yourself?

Read More »

Comments

Submitted by John_B (not verified) on Sat, 26/10/2013 - 6:32pm

"When it's ready": Larry Garfield blogged recently it is likely to be six month at least. That rings to true to an outside observer.

Gut feeling: for the larger well-funded sites it could be excellent. For the many people who are still building blogs in Drupal because they have read that it is the thinking-man's Wordpress, maybe not so great.

I think about making my own business site D8. But like many small players in the Drupal industry, who have either blogs or like mine a brochure site, my site is not critical to making a living. Having learned lessons as an early adopter of D7, it will be a long time before I risk D8 on a client site (unless the client if fully informed about pros and cons, and on board with it).

Submitted by flink on Sat, 26/10/2013 - 6:43pm
... love it! Thanks so much for your comment. RdB

Submitted by chx (not verified) on Sat, 26/10/2013 - 7:12pm

It took *six months* after D7 released for contrib to really catch up. What's this talk of contrib now when we are not even at beta and we tell everyone if they port their module, well, things will still change. I can't understand why do you expect a huge amount of D8 modules to appear...

Submitted by flink on Sat, 26/10/2013 - 7:47pm
If you are the chx I think you may be, then I'm gobsmacked. The fact that "it took *six months* after D7 was released for contrib to catch up" is precisely what we all wish won't happen this time round! Of course things will change in core between now and official release, but with an alpha4 out now, I would hope and expect things not to change greatly, just incrementally. Therefore, say, 90% of the effort put into contrib now, would be well-spent and not wasted. I find it strange that someone who actively works on core advises us NOT to start using it to help make D8 a success in real-world websites sooner rather than later.

Submitted by Naheem (not verified) on Mon, 28/10/2013 - 2:06am

Chx is acknowledging reality.

While it can be differentfor Drupal 8, its not something that will happen by itself. (I dont think I have seen a upgrade "pledge" initiative like there was for many modules for Drupal 7 - that would be a great start.)

There are differences like major contrib modules moving to core, but at the same time, there are probably 10x as many modules in contrib than there were when Drupal 7 was released.

Submitted by flink on Mon, 28/10/2013 - 7:18am
As long as people believe they cannot do anything in contrib until core is released than that is their reality. It's not mine and it need not be the community's. There is a #D8CX upgrade pledge. The number of D8 contrib modules out there already without a #D8CX pledge is greater than the number pledged (yay!), although it is only 3.3% of the number of D7 modules :-(

Submitted by naheem (not verified) on Sun, 27/10/2013 - 2:21am

One thing that contrib in earlier releases of Drupal had to wait for was Views - many modules did not even start porting 'til that was released.

Now its in core. So while there will still be some time before contrib is featureful, it should not have as long a quiet period. Besides, with just views in core, core will be more capable than it was previously and less contrib will be required.

Submitted by Ivan Jaros (not verified) on Sat, 26/10/2013 - 8:18pm

Backdrop: they don't understand how much time and energy working on such a huge project will cost. Also, I think they should have just focused on maintaining D7 for a longer period, than is usual for Drupal release, instead of just forking the whole project. That's really dumb move in my opinion.

D8 modules vs D7 modules + Come learn D8 with us training course: what do you expect when there is almost no D8 documentation yet? Which is understandable since D8 isn't even in a beta state. So what is the point of your question?

Sorry but the questions asked and points made in this article are really stupid in the current state of D8 development.

Submitted by flink on Sat, 26/10/2013 - 8:52pm
Don't appreciate being called stupid, but re D8 contrib modules: your sentiment is similar to what was voiced by chx in the comment further above. So my response to your comment is the same as to chx's: in order to bring D8 to the masses sooner rather than later and given D8 alpha4 is out now, the community needs to work on D8 contrib *in parallel* with D8 being finalised.

Submitted by Charles (not verified) on Sat, 26/10/2013 - 11:18pm

I think the problem with Drupal 8 highlights the faults and weakness of the PHP.
Python was architected to be a robust, well-designed and well thought-out language.
PHP “just happened”. Not to knock PHP (I actually love working in PHP) — but Python is just a better language.

Python mostly has that with Django.
Contrast that to PHP where we have Symfony, Zend, CodeIgniter, Kohana/ no clear winner means that the market is fragmented. And, fragmentation is bad. It’s particularly bad when it comes to web frameworks.

Will Symfony still be the best framework in a few years time
with so much competition? We don't know?

I think more developers will be move toward the Django CMS framework in a few years

Submitted by Ryan Cross (not verified) on Sun, 27/10/2013 - 2:25am

Django, while popular, is definitely not the only popular python-based web framework. web.py and cherryPy readily come to mind. You can easily see a lot of "fragmention" just looking over this list https://wiki.python.org/moin/WebFrameworks

Submitted by just-passin-thru (not verified) on Sun, 27/10/2013 - 12:20am

1. many, if not most, contrib maintainers don't have spare cycles to port and report their modules. If anything, the d8 release cycle has been the most volatile-- none of the 'deadlines' have stuck, so why would any contrib maintainer want to risk porting now only to have port again the next time some big 'exception' to a deadline is made.

2. If anything, the d8 cycle has actually discouraged contrib porting even more than d7-- which was really mostly delayed due to the complete rewrite of views rather than core. Add the much much greater scope of changes, and much much longer contrib cycle is likely what will happen-- not a faster one.

3. This d8 dev cycle has been one big hot mess. Deadline after deadline was softened. So much so that even the most dedicated core developers can be seen frustrated in the issue queue complaining that they could have continued working on some important features if they knew that a particular 'deadline' was going to be bypassed when one after another large scale change (which shouldn't qualify due to a deadline) is committed. Why would contrib expect any better?

Submitted by flink on Sun, 27/10/2013 - 1:07am
Always a pleasure to have you chip in, just-passing-thru! I have no idea who you are, but your comments are always refreshingly cynical. Yes, BIG initial D7-to-D8 port, then tiny re-port(s) is what you, chx and Ivan Jaros seem to object to -- and it's precisely what I advocate. It is frustrating to everyone, including the D8 core girls and boys, that the D8 core API is not as solid as a rock yet. But D8, like any CMS, is a complex beast -- getting it right is an iterative process. Standing on the sideline screaming "where's my delivery?" is not going to bring forward the day we can all enjoy D8 in real websites. The bigger picture is that it's not us (contrib) and them (core). The big picture is that we're all in this together. Contrib needs core and core needs contrib for Drupal D8 to succeed. Given that D8 core is now in near-beta, I believe a realistic and more time-efficient option to serialising D8 core and D8 contrib developments is for core and contrib developments to parallelise and synergise.

Submitted by just-passin-thru (not verified) on Sun, 27/10/2013 - 1:20pm

While I totally am usually cynical, I really didn't think this particular post was, lol. But then it seems any one who isn't a cheerleader is a cynic.

And I'm not standing on the sidelines screaming anything.... though you certainly seem to be cheer leading at every opportunity. Was anything i said untrue?

But cheer all you want... I simply don't have the time to learn and relearn and port and re-port every time dries finds something he deems worthy to violate his own 'freezes' (at this point that term is a joke). And judging by your own stats it certainly seems many other contrib maintainers feel the same.

You'd probably have little more efficacy if you peeked out from behind the rose colored glasses occasionally, lol.

Submitted by flink on Sun, 27/10/2013 - 7:42pm

Funny you call me a cheerleader -- some would say I'm kicking against shins.

As I have already acknowledged, the D8 core team themselves would have loved the D8 roll-out to have gone according to the initial projections.
No-one is cheering about D8 being late, certainly not me.

While my passion is for the community to get many contrib modules out soon, I'm not asking you to learn and re-learn and port and re-port. Your strengths may not be in developing code, which is fine, as there are other ways people in the community can contribute to getting D8 + contrib out sooner.

I also believe that the community should stop expecting that things happen for free. The expectation that high-quality contributed modules will continue to appear for FREE is an unsustainable business model.

In order to get quicker to the point where we can have real websites on D8, we need to mobilise and bring together supply (module developers/maintainers) and demand (individuals and businesses using their modules). This requires some sort of market place and TSM have a great model for it. Check out their site.

Submitted by John_B (not verified) on Sun, 27/10/2013 - 7:51pm

I am open to your argument that free modules is an unsustainable model. But to be persuaded I need to be told what has changed. This model has served Drupal well, and not stopped us competing with CMSs which have many paid modules. Do you mean something changed in the environment, or just that it has never been a good model?

Submitted by flink on Sun, 27/10/2013 - 9:41pm
There are several issues with the free model. The TSM site lists several. Worth a read. I'll give you a couple. 1) Module quality. When you ask companies about the general quality of the modules they use, many of them will respond that they spend a lot of time, hence $$$, to make them work for them. Problems range from poor documentation, poor responsiveness in the issue queue to bugs and missing functionality. They'd love a place where they can go and know that if they use a module from that place, it is likely to work out of the box without rework. 2) Developers/maintainers cannot live off spending weeks developing modules and then maintaining them for years and never getting a reward for it. Maintainers may temporarily sacrifice time to put themselves on the map in the hope for some reward later on, like a job with a Drupal shop. If they succeed they're likely to stop maintaining their modules. If they don't find a Drupal job, they'll have to find something else to pay the bills. Being a maintainer may be a leisurely hobby, but it is not a sustainable job -- not at the moment. It is not something you can do for a long time at a high quality level without any rewards. Why would anyone be expected to give, give, give and not receive anything in return? That's a reason why so many projects are effectively abandoned, with bugs and long issue queues. And a reason why it takes so long for new versions to come out, including some very popular modules. Now, to bring 1) and 2) together.... If companies that make a lot of $$$ out of free Drupal modules could spend a tiny percentage of their profits on the maintainers of the modules that drive their businesses, then maintainers can spend more time on producing quality modules and giving better support in issue queues. And on releasing new versions more rapidly. The Drupal world would be a better place for it, for both the supply and demand sides.

Submitted by John_B (not verified) on Tue, 29/10/2013 - 8:21pm

You might be right that more paid Drupal software would be a good thing, although the line tends to be 'why would anyone pay when it is GPL licensed.' I have solicited views on starting a marketplace for paid Drupal modules on d.o. https://drupal.org/node/2122871.

Submitted by flink on Tue, 29/10/2013 - 10:57pm
In the TSM model, nothing will change on drupal.org. Modules remain free and available to everyone, under the existing license. You donate maintainers, or commission their work or pay a subscription, so TSM can manage project, vet modules, help with quality documentation etc. Thanks for starting more discussion on this!

Submitted by just-passin-thru (not verified) on Tue, 29/10/2013 - 11:13pm

Not sure that skills, my are fine btw lol, are necessarily the issue here. Rework is rework .... Even for the most skilled developer. I'm a one man band and I simply don't have the cycles to rework a module port (I get 0 paid time to contribute.... It's all personal time) over and over and over again. And I find it quite dismissive and insulting of contrib developer time when it's tossed off like no big deal.

And yes, the free vs paid module discussion is also very important. I agree that a paid module economy would probably be a good thing and help this issue a lot. However, this isn't the first time it's been suggested. It's come up many times....and by some very high profile drupalers. The fact that nothing has really come of it yet (TSM aside.... It's still pretty new) leads me to believe it may not be workable.

Submitted by flink on Tue, 29/10/2013 - 11:59pm
I get paid 0 also. I have over 10 active modules out there, that I all produced for free. Some others initially resulted from paid projects. Contrib developer time is too much taken for granted as part of this "how wonderful, everything is free, just take, take, take" attitude that some people have. Take the modules, take the maintainers time, never pay anything back. It's not sustainable. That's why I feel contrib needs to be funded. Or at least parts of it. Not so much the modules themselves, but the people and the services they provide. I hope TSM becomes a success. I'm not sure who you refer to when you find it "dismissive and insulting when contrib time is tossed off like no big deal" -- I'm certainly not one of those who have that opinion. I attend to my module issue queues every day. It's a lot of work. It IS a BIG deal. Developing and releasing a module is a laborious task, but it's a satisfying one and a one-off -- attending the issue queue that follows is a long-time sentence. I hate rework too. It still believe that for my own and for most maintainers' modules a biggish initial port followed by a few smaller tweaks is the path of least resistance, especially when there's so much new stuff in D8 to come to grips with. It is also a path that will create critical mass earlier in the piece. We only need a few people to lead the way and create momentum. Followers are welcome to do what they do best: follow. Except that with sufficient critical mass created by those that go before them, they have an opportunity to follow at an earlier stage.

Submitted by MisterMon (not verified) on Sun, 27/10/2013 - 1:55am

Something I noticed when testing D7 from alpha to release for a client. The contrib modules were coming along nicely in parallel with core. Then a release candidate made a core API change that broke a lot of the up-to-date modules. This happened not long before Christmas. Most activity died down over the festive break, maintainers were obviously taking a well-deserved rest. A week into the New Year and bang, D7 released because there were 'no new issues for 2 weeks'. Well duh, what did they expect? That everyone would be fixing and testing over Christmas? Hence very few modules were actually ready for the D7 stable release, although quite a few had been ready until the late change was made. If there were any voices commenting on this they were drowned out by the sound of champagne corks and cheering by the core team.

Its all very well telling the community to work harder but please give them a break and don't repeat what happened last time! (Not to mention that API changes shouldn't be happening as late as RC)

Submitted by flink on Sun, 27/10/2013 - 11:26am
Indeed. Core team take note!

Submitted by rooby (not verified) on Mon, 28/10/2013 - 12:20am

I think the main factors in terms of contrib are time and need.

It takes time to port modules to a new version and a lot of maintainers aren't able to spend their own unpaid spare time on the task.

This means that modules get ported as they are needed.
Once people/companies start seriously building sites using drupal 8 then when they come to something that needs porting they might spend the clients money to do so.

Until then I would not be expecting people to start donating all their time to it.

This is the reason why you see the much larger amount of drupal 7 module coming out.
That is what people are using so that is what they are making modules for.

It would be illogical for these people to be releasing all their modules for drupal 8 and having no one use them (and not be able to use them themselves unless they are way hardcore super risk takers).

People don't need drupal 8 modules yet so they are not building them.

Submitted by flink on Mon, 28/10/2013 - 7:21am
Yes there's a great element of chicken and egg in this and that cycle/stand-off needs to be broken.

Submitted by rooby (not verified) on Mon, 28/10/2013 - 11:51am

I don't really see how.
People & companies aren't going to magically get more time & money to put into Drupal development so it doesn't make sense to work on Drupal 8 until there is an immediate return on the investment, which won't really be until rc at least.

The way I see it, working on Drupal 8 contrib now when it isnt really usable instead of using that time to work on Drupal 7 contrib, which is useful to people right now, is bad use of time.

I don't see a problem with a large number of modules bot being ready when Drupal 8 launches, because that is just how the cycle works.
I don't see it as a bad thing that a bunch of people have to use Drupal 7 for a bit longer if modules they need aren't ready.

As long as it is only 6 months before a decent amount of modules are ported I think that is perfectly acceptable.

Submitted by flink on Mon, 28/10/2013 - 1:04pm
@rooby: I'm not saying D7 is bad. But if D7 is so great why have D8 at all? "Working on D7 while waiting for D8 to become ready" is never going to accelerate the process of D8 becoming the killer platform we all hope it to be. I mean why don't we all sit back and wait for our ROI to magically happen? Why not let others do everything? My opinion and that of some who have talked extensively to the industry is that there are companies that are indeed willing to invest money at getting quality contrib modules out sooner by engaging quality developers. All they have to do is spend that money a little earlier than when you're proposing. And I know there are quality developers out there, who in exchange for suitable compensation are willing to port now or soon, followed by a small tune-up later when the API is frozen. We're doing the same at flink. Modules with a "ready-for-D8 badge" (so to speak) on their project page send out a strong message for others to follow suit. It's about creating synergy and critical mass.

Submitted by JvE (not verified) on Mon, 28/10/2013 - 7:57pm

I'd have preferred it if all that time and effort spent on D8 would have gone into finishing D7.
23 releases over more than 2.5 years and still I cannot release a D7 site without core patches. There are currently 24 critical open issues and 103 major ones.
I do not have the resources to get them all fixed, but I try where I can.
To me it feels like D7 was released not when it was ready, but when certain core devs got fed up with it and wanted to start work on D8.
Will the same happen to D8?

Submitted by flink on Mon, 28/10/2013 - 8:02pm
You're a great cynic with great humour.

Submitted by ontological (not verified) on Tue, 29/10/2013 - 12:28pm

I agree with your insight that the Backdrop announcement had some beneficial effect on D8. At DrupalCon Prague there were a number of sessions etc addressing the developer experience in D8 ... which was beneficial. I think there have also been a few tweaks to D8 to help. If Backdrop maintained contrib compatibility I think it would be guaranteed success, or as you suggest, supporting D7 longer. Other than that, it may be too early to pass any judgement on Backdrop's future.

I personally am OK with delaying D8 until it is ready (though I understand some people's frustration). Also, until an API freeze is certain I wouldn't push too hard to have people port modules to D8 early. Just my opinion.