New users universally do NOT understand that Drupal 8 is not near release

drupal8_release_date_confusion.pngOkay, so the title of this post is a bit tongue-in-cheek (it’s a reference to a particular Drupal 8 usability issue); I don’t really think this misunderstanding is “universal” but there does seem to be a bit of confusion about when to expect Drupal 8. The confusion seems common among the greater Drupal user-base, and it seems to affect more than just new Drupal users and those evaluating or considering using it, but also Drupal stakeholders who have several years’ of experience. According to Dries, we should not expect to see Drupal 8 released for at least another 18 months. Yes, I’m aware that he was talking about 18 months after Drupal 7 hits its “productivity plateau”, and since he also indicated that he would announce when he thought we were at that plateau (and to my knowledge, he has not yet) it’s likely to be more than 18 months before we see Drupal 8’s release.

And yet, for the past few months, we have been seeing increasing questions about Drupal 8 (in the greater developer and discussion community); questions which make the assumption that Drupal 8 is very close to release; a couple examples of such questions:

One user wrote:
... I have several years working with Drupal 6 and I am thinking to start building sites and develop over Drupal 7, but it seems that Drupal 8 will be launched very fast. Is it best to wait some months and learn about Drupal 8?
It’s easy to just think “Well, that’s just silly!” when we see one question like this, but when we see many such questions popping up, we have to know this points to some murkiness in terms of the Drupal release cycle.

We need some clear announcements about Drupal 8’s status

While a release date announcement is certainly premature, we should probably have some kind of clearly-posted announcements that Drupal 8 almost certainly will not be released before 2013. There is so much information and “buzz” about Drupal 8 on Drupal.org, Drupal groups, blog posts, and other internet sources that it’s not at all surprising that people will start to think it’s coming soon, but of course the fact is that Drupal 8 is simply in a very active state of development by the community and the discussion is not hidden from the public, indeed, the public is encouraged to become a part of the process and find ways to contribute; hence all the regular flow of information about a product that is far from release.

In commercial technology companies, there is often much pressure to hide details of a planned product right up to the point it’s ready for the market. This helps prevent any ideas in the user-base that they are advertising vaporware or otherwise producing too much hype too early on. But a healthy open-source community thrives on the discussion and open planning, which can lead to a lot more information about a coming product than they (e.g. someone searching for information about Drupal) might even find in a Google search for the current release. This can contribute to the confusion, so those of us writing about Drupal need to make sure that references to Drupal 8 come with a reminder that it’s still far from release.

Drupal 7 release numbers seem to cause part of the confusion…

Part of the confusion seems to be associated with the greater user community not quite “getting” the Drupal release numbering and assuming that the current version numbers (getting close to 8.0 if seen as decimal fractions) indicated that Drupal 8 was just around the corner. This should hopefully be ameliorated as soon as a 7.10 release is made, next Monday; but it couldn’t hurt to have an announcement that the Drupal 8 API is not even complete yet (and won’t be for some time). Currently it’s too easy to find information on Drupal.org about Drupal 8 without any information that the pages are essentially “placeholders” (e.g “stubs” for the documentation team to work on) or are for people actively working on core development.

In conclusion... encourage Drupal 7 use and Drupal 8 involvement

Personally, I think that we can, as a community, recommend that most users starting a Drupal site today should consider Drupal 7 rather than Drupal 6 (though many people maintaining Drupal 6 sites may not have much reason to migrate, especially if the state of necessary contrib modules make a smooth migration non-trivial). Drupal 7’s end-of-life is much further away and most of the important modules most people will want have now been ported and have a stable release for Drupal 7 and many other nice modules have been written from scratch and are only available for Drupal 7. But Drupal 7 has taken a long time, since it’s release, to get to this point — and while I’d like to think otherwise, realistically it’s likely that when Drupal 8 is released there will also be a “pain period” during which most developers working on complex sites will probably still want to use Drupal 7 (because of core issues and lack of modules). So recommending Drupal 7 for new sites and an announcement that Drupal 8 won’t be released for more than a year really ought to be added to the main downloads page on Drupal.org, the Drupal 8 API page, and other places where people might encounter information about Drupal 8. We, in the greater community, should get the word out that Drupal 8 will be awesome, but we shouldn’t give people the impression that it’s closer to release than it really is. And we should also make sure they know that there are modules and themes which will help them achieve the “coming-to-core-in-Drupal-8 features” they might be eager to use (HTML5 support, targeting mobile devices, etc).

Now is the time to bring new Drupal 7 users into the fold and recruit more people to help make Drupal 8 as awesome as it can be… so we need to ensure that anyone new to the community knows that there are ways that they can help and that it’s not to late to pitch in for the effort!

Comments

Really good points

Really good points. Its a very good observation that Drupal 8 would indeed not be released for at least 18 months, at least I use that rough-estimate in my assessment for the Drupal 8 Multilingual Initiative work I'm doing. So for everyday use, its very far off, for development its too close, because we want to improve so much :)

Nice to have confirmation of my release guesstimate, Gabor. :-)

Thanks for confirming my estimate, Gábor. For a while I was also not sure if Drupal 8 might have a shorter release cycle than did Drupal 7. (As you know, it was almost 3 years between Drupal 6 and Drupal 7’s release). But even before Drupal 7 was released (as soon as it was in code freeze, I guess), the talk about “what’s coming in Drupal 8” started and it seems there is a much better infrastructure for a larger community to work on building the next great release of Drupal. There’s been so much talk about the features planned (e.g. last couple of DrupalCons and many announcements since) and features implemented (e.g. HTML5 doctype and Symfony2 components in core) that it’s really easy for those not really “in the loop” to get the impression that Drupal 8 is maybe coming in the next few months.

By the way, I’m greatly looking forward to all the improvements for multilingual support and hope we can help in implementing them, too.

I fell for this assumption

I picked up Drupal 7 and fell for the misconception. I think had I experience with Drupal 6 and the versioning number it went though then I wouldn't have assumed an impending 8.0 release.

When Drupal 7.9 came out I was wondering if 8.0 was next month, kind of embarrassing when you release, but the whole Drupal site has so many 8.0 mentions and features, along with all the blog and twitter posts around 8.0 it is an easy assumption to make for those of us with less experience of previous versions.

Still very exciting that there is so much noise around 8

agree

thanks for putting this out here as a reference. if someone asks me exactly that stuff again i will sent him here.
i agree, release numbers are confusing as 7.9 and then comes 7.1 :)

i think drupal is doing it like firefox. verey month a new major number. but drupal is not doing that :D

Maybe Drupal would do better to change that, in future...

I would suggest that maybe, when D8 is released, it could adopt a new version numbering system where we go up in fractional increments, e.g. 8.01, 8.02, 8.03 ... then when we hit 8.09, people will expect 8.10 to come next, not 9.0. As far as Firefox goes... what they've been doing with version numbers lately is odd. I suspect they are trying to just catch their version numbers up with those of IE. To go from 7.x to 8.x for what amounted to basically a bug/security fix release is very bizarre.

Something that probably adds

Something that probably adds to the confusion, is that some modules already have Drupal 8 releases (usually tagged as dev). Api.drupal.org also has a tab Drupal 8, which doesn't help either.

The last part that definitely doesn't help, is that plenty of modules for D7 are still in either dev, alpha or beta. Some modules (like Node Access) won't ever be ported to D7 at all, which makes it really hard to make new sites in D7 instead of D6. I started a new project today, for example, and checked all necessary modules I could immediately think of. None of them had a full release yet, and two of them didn't have any D7 version.

Such things make people think: "It will still be a long time before I can actually use D7. They're already preparing for D8's arrival, so I'll just wait it out and skip D7"

Ironically, you are commenting on two sides of the same coin. ;-

The fact that we have all the documentation of Drupal 8 API in progress should hopefully help module developers avoid such a long delay (as after Drupal 7 was released) before porting their modules. So to try to avoid any such long future delays, some developers have proactively started a D8 release (probably usually just a copy of the D7 branch) so that an issue queue can be started (e.g. for feature requests, etc). This should definitely be helpful in the future, but for right now, it almost makes it seem like Drupal 8 is close to being the “current stable” release of Drupal.

As I said, the Drupal API front page really could benefit from a comment that Drupal 8 is not yet in code-freeze and won’t be for a while yet, so we should expect changes to the API for Drupal 8 and a long wait for the official release. By the same token, module developers creating a Drupal 8 branch should comment on their module description pages that this dev version is merely a placeholder so that feature requests can be started on (or moved to) the issue queue for that branch. The existence of Drupal 8 modules is misleading.

Coincidentally (on-topic to your comment, but a bit off-topic to this article) I was just showing a colleague of mine who is fairly new to Drupal development (but has a background in Typo3) that there are quite a few options available for Drupal 7 access control. Depending on your use case, it's possible that some of them might be helpful for you… see the following links:

You can also search the Drupal.org modules (That is simply a keyword-free search on http://drupal.org/project/modules with the following settings:
Module category: “Content Access Control”
Filter by compatibility: “7.x”
Status: “All projects”
Sort by: “Most installed” )

By the way, since the designation of a module as “dev”, “alpha” or “beta” is entirely arbitrary (completely controlled by the module maintainer), you should take that with a grain of salt. Some maintainers may be overly cautious or more optimistic than others. I've experienced major bugs in “stable” module releases which, for my use case, made a module totally unusable. I've also seen “pre-release” (alpha, beta, or even dev) versions which were in use on thousands of websites and, for my use case, seemed rock solid. If in doubt, I suggest looking at the numbers of people using a particular release and at the issue queue to see if there are many reports of unfixed issues that would likely affect your use case.

Thanks for clarifying that.

Thanks for clarifying that. It is quite confusing to see D8 mentioned in such important places, but now that I know why, it does make alot of sense. The biggest problem with D7 is the slow release of modules (which I got to start looking for a way around without too much time spent on custom dev), so anticipating that for D8 is by all means a good thing.

Now I still got the main (or my main) problem with D7 to solve: How you can use it as a full alternative to D6. I'll have to give alot of those alpha / beta versions a try then. Had some bad experience with OG going: "Yeah, the site admin decided this node is a group, but now that you're creating one, you can choose if the node of type group you're making will be a group or not" and similar nonsense with other major modules. That's kept me, and plenty of others, to think that those alpha / beta versions weren't ready yet. Maybe things evolved by now, or maybe there are general workarounds by now. I'll have to look into it and start adopting D7.

There is no Drupal 8

There is a Drupal X, an experimental version of Drupal. (Literally meaning a version of Drupal used to experiment on.)

Eventually, a Drupal 8 alpha or beta will be branched off from Drupal X, and then it will be sensible to suggest to new users to adopt Drupal 8 instead of 7.

There are always experimental (dev) versions...

Each branch has both stable and dev releases, except for the 8.x branch, which is all dev (experimental). If you go to to the Git repository, you can check out the dev version of D8. Unfortunately, I don't think the project infrastructure is compatible with your suggested approach. I think you have to create branches by number. Using the 'X' might also be confusing for those who want to help with D8 development, especially since a D9 branch might exist as soon as there is a freeze on the API, quite likely before there is any official release, even an alpha, for D8.

IMHO, the approach should be to create issues for Drupal.org webmasters and/or documentation team, etc, to add clarification to the project page, API page, etc, clarifying the current state of D8 (that we won't likely have an alpha version till 2013).

A freeze on the API would

A freeze on the API would imply an alpha release of D8 (no more upstream changes are expected).

The X branch would thus go on, but the D8 branch would freeze the developer experience for that version.

Hmmm...

It's an interesting approach. I'm not sure how technically feasible it is, nor if it's the approach that would make most sense to the community, but the issue does provide a good place to discuss that approach further.

Again, I'd personally suggest creating issues on the webmasters' and/or docs queues, etc, to add notice that D8 is still a development version which is far from being ready-for-use, wherever we find places where this kind of notice would be useful. (API top level; Git checkout page for Drupal; Drupal core description and/or main download pages, etc), as well as (short reminders in) 2012 DrupalCon session descriptions which involve D8; details of "core conversations", etc.

I do think this is a fairly critical issue right now since a lot of people making decisions about larger projects may also have fallen into this misconception and might be holding off on starting Drupal projects, so it could well be a significant factor deterring enterprise adoption of D7 and funding to finish porting modules from D6 to D7, etc.

Drupal versioning will

Drupal versioning will continue to work as always has..we have something called head which is currently represented by the d8 branch within git. Once drupal 8.0 is released and Dries decides he wants to open a new branch a new branch called d9 will created within git. At that point in time all patches will be applied to the shiney new d9 branch and require backporting. And yes people will start to refer to d9 despite it being many years off.

I think the key is simply ensuring that people understand that d8 etc is long way off so don't worry about it and don't use it unless you want to help contribute to its development.

Xactly

I was just thinking about a concept of Drupal Heaven for the development platform when I read your comment. Same idea as yours but X is shorter.
From a marketing perspective, if you don't want people to think about D8 because you are promoting D7, you should not offer the option. Elementary George Lakoff, 'Don't Think Of An Elephant'. If D8 is not a release yet, it should not be mentioned as an option. The very fact that the number exists suggests otherwise.
Microsoft and Apple do the same. They have fancy (animal) names for development projects. Anyone understands that. Drupal Tiger perhaps? Or Drupal Elephant :o)

Please bump my issue if you

Please bump my issue if you agree.

A simple solution...

A simple solution to this would be to put better explanations on the drupal.org front page, module pages, and download pages. Several years ago, well before drupal 7 was ready, I had a client that insisted that I use drupal 7 for his new site. After repeatedly explaining that 7 was not at all ready, he then insisted that I use only drupal 6 modules that had proclaimed their vow to upgrade to drupal 7. I then had to explain how much that would limit the modules that I could use for his site, and that module developers were still figuring out their future plans. Yes, this was a particularly demanding client. But he thought he was going with the newest and greatest simply because he had done some research into the "newest" version of drupal without understanding that it was actually "too" new. As a developer and consultant, I do a lot of educating to my clients because of the seemingly absent informational pages about the various versions and capabilities of drupal -- what it is and isn't, and what versions are recommended. Communications that come from the core development team are often believed to be the gospel, whereas the rest of us lowly disciples are just trying to put out some fishes and loaves with the more stable current versions.

Doesn't it seem that almost every problem can be attested to bad communication?