Top 50 Drupal 7 Contrib Module Status

tsvenson's picture
Submitted by tsvenson on Tue, 06/21/2011 - 21:08

Drupal 7 has now been out for more than six months, v7.2 was just recently released. There is no doubt that Drupal Core is very stable, if not rock solid. However, very few sites can be built using just the core functionality, most sites needs many contributed modules. In this post I have looked at the status of the top 50 contributed modules and what state they are in.

First a look back on Drupal 6. When it was released, it took a long time before it was used for new sites, even longer before Drupal 5 sites could be upgraded. This was due to that a lot of the important contributed modules was not ported to it until long after. That was something everyone in the community wanted to avoid happening again. A lot of module maintainers joined the #D7CX movement, pledging that their module would have an official release on the day Drupal 7 was released.

It made a difference, just not as much as everyone hoped it will. Below I will go over what I have found out about the current situation.

Before going into more details I want to point out a few things regarding my selection of modules to include.

  • It is based on the officially available Usage Statistics list on drupal.org.
  • Modules that are incorporated in Drupal 7 Core has been filtered out.
  • Themes have been filtered out.
  • In a few cases a module has a fresh Drupal 7 start. See the list of modules for which ones.

Anothert thing you need to keep in mind is that the usage statistics is based on Drupal installations that pings home, using the Available Updates report. Many sites have this turned of, or only check manually and therefor the stats are just to be taken as a sample of what modules that are popular.

Drupal 7 to 50 contrib modules release status

So, did #D7CX make any difference then? Well, to a certain degree it did. A lot of modules have Drupal 7 versions at some stage, but a very small amount have even now been released in official versions. Just looking at the 50 most popular modules speaks for itself, only 26% have an official release today.

Just comparing contribs that have released versions, or not, paints a bad picture of the situation. Therefor I have also broken things down in what stage of development each module on the top 50 list is in.

Drupal 7 to 50 contrib modules status breakdown

When breaking things down in what stage of development each module is in, it is clear that there is still a lot to do. Only 32% is either released or have reached Release Candidate status.

Many modules are still only in dev version and two haven't even gone that far yet.

To dig even deeper I have gone over each individual module, checked their issue queues and so on. Unfortunately I haven't had time to test each module individually, but a lot of them I use already on a daily basis, and thus have deep knowledge of. I have tried to be as accurate as possible about their current status.

Status of Individual Modules

Below I have listed them grouped on what stage they are in. For not released modules you will also find a short comment about their status.

After each module name you have their position in the popularity list and if development is active or stalled. Modules marked as stalled have not had any new commits for the last month. I have also linked each module to their respective project page on drupal.org.

Released modules (13):

Release Candidates (3):

  • Views (1) - Active
    Very close to official release. Have been working solidly for many months.
  • Pathauto (4) - Active
    Works well and is close to full release.
  • Administration menu (6) - Active
    Minor issues remains before full release.

Beta Releases (14):

  • Token (3) - Active
    Adds a lot of tokens that are missing in core, plus an on-page contextual token list. Main holdup is is the Field Tokens support.
  • Chaos tool suite (12) - Active
    Goes hand in hand with the development of Views and Panels.
  • Advanced help (13) - Stalled
    Works OKish, but could be better integrated with new features in Drupal 7. Still takes up unnecessary space in Toolbar/Administration menu.
  • XML Sitemap (20) - Active
    Works well and is close to RC/full release.
  • Page Title (25) - Stalled
    Works OKish and seems close to official release.
  • Rules (30) - Active
    Very close to official release. Have been working solidly for many months. Dependent on the Entity API module.
  • Email (31) - Stalled
    Several bugs, but no new commits since january 20th.
  • Nice menus (32) - Stalled
    Quite a few bugs still remaining to be fixed.
  • Redirect (Path Redirect) (34) - Active
    Fresh start for Drupal 7 as well as transformed into API module for other modules to leverage on.
  • Site map (37) - Stalled
    Only two bugs, but seeking new maintainer.
  • Internationalization (40) - Active
    This project has undergone a big rewrite for Drupal 7 and is quickly getting very close to release version.
  • Ubercart (46) - Active
    Depends on many other not relesed modules, such as Views, Rules, Ctools, Entity API.
  • Admin - (47) - Stalled
    Beta released 2010, no dev version available on project page.
  • Profile 2 (Content Profile) (50) - Active
    Quite a few bugs still remaining to be fixed.

Alpha Releases (9):

  • Date (7) - Active
    Quite a few issues. Also dependent on Views and Ctools, which do not have official releases yet.
  • Link (13) - Active
    Quite a few open bug issues
  • CAPTCHA (15) - Stalled
    No TrueType support due to lack of ImageMagick support. Also seeking co-maintainer.
  • Panels (23) - Active
    Quite a few open bugs, but is quickly closing in on getting ready. Once Views in officially released, count on even higher activity.
  • Calendar (27) - Active
    Heavily dependent on the Date module, which in turn depends on Views and Ctools.
  • Views Slideshow (28) - Active
    Once Views reaches released, this module should follow shortly after.
  • Transliteration (29) - Stalled
    Works OKish and seems close to official release, but no work on it done since February.
  • Views Bulk Operations (35) - Active
    Depends heavily on the release of Views.
  • Content Templates (41) - Stalled
    Quite a few bugs still remaining to be fixed. Seeking co-maintainer.

Development Releases (9):

  • CCK (2) - Active
    Most is now in core, but the contrib contains D6 to D7 migration code.
  • Image API (5) - Stalled
    Adds ImageMagick support. No development this year. Development has moved to the ImageMagick project, which though seems to have stalled as well.
  • IMCE Wysiwyg bridge (22) - Active
    Works. Seeks co-maintainer.
  • Printer, e-mail and PDF versions (36) - Stalled
    Lots of bugs exists, however no new release since March 5th.
  • Better Formats (39) - Stalled
    Partially works, development goes on in the Drupal 7 Port issue. No new dev version since February.
  • Tagadelic (44) - Active
    No bugs in issue queue.
  • Location (45) - Active
    Lots of bugs exists, seems far from even alpha release.
  • Simplenews (48) - Active
    Quite a few bugs still remaining to be fixed.
  • Gmap (49) - Stalled
    Lots of bugs exists, however no new release since April 1st.

No Release (2):

Conclusions

From the above statistics and look at the status of each project we can draw some conclusions:

  • Many project are dependent on other projects to be ready. Examples of those are Date, Calendar and Views Slideshow. Once the main modules are ready, we will see these being ready shortly after.
  • Quite a few modules are stalled for a long time. Some are looking for co-maintainers, others seems almost abandoned.
  • Several modules looks to be very close to be ready, but have for some reason been stalled for a long time.

Another trend we see growing when it comes to contributed modules is the number of pure API modules. Examples of those are Entity API, Libraries API, Session API and Redirect API. In many cases these are spin-offs from existing modules. Personally I like the idea to collect often used functionality in pure API modules. They will both be easier to incorporate in future Drupal Core versions and make module development easier. Hopefully they will also mean that Drupal will use less memory and get better performance.

How this affects the users and site builders

For us that use Drupal to build websites with, having to live with using not released versions adds a lot of extra work. It means we constantly need to update everything from the development environment to the live sites. We need to have separate test environments before we can use new versions for the sites we build, just to make sure they don't break anything.

Most of us fully understand this is one of the consequences we have to live with when using and open source product. Since it is free, we can't demand that anyone fix it, unless we pay them to do that. Many of us are also trying to help out as best we can by feeding back information to the developers about bugs and other improvements.

However, Drupal has for a long time been a big player on the CMS/CMF market. It is used by many big organisations and its market share is constantly growing, especially among the largest sites out there.

We also see that the community is taking security and quality assurance more and more serious. We have a very respected security team as well as processes for handling quality assurance. This is not only related to Drupal Core, it covers contributed modules to some degree as well.

I know the majority of the maintainers of contrib modules are doing a fantastic job and take their roles very serious. The quality of what they create is often simply amazing.

Knowledge Sharing, Project Management and Mentoring

But, I think it is time that we put more emphasis on how important it is that contrib modules get official release versions much quicker. I'm not talking about taking shortcuts when it comes to quality, such as releasing something buggy just to get it out. That would just have to opposite effect.

Instead I believe we need to better help educating developers when it comes to how to handle their release cycles, how to plan their projects and also balance the amount of new features they add against getting an official release out sooner.

This is problems I have as a site builders as well. It is easy to create an amazing specification of the next killer site, but then implementing it takes time. That time is not always easy to estimate and will often result in that things take much longer than expected.

It takes special skills to be able to fully understand everything involved and be able to make correct time planning. This is skills you only get from experience and a will to understand everything involved.

I am sure there are a lot of users within the community that has these skills and would be more than willing to share it. Its just that I don't think many of them even thought of that they could help in that way.

If it was easier for people with project management skills to get involved in contrib projects, either actively or as a mentor then that would be a great start for sharing knowledge and help educating developers about this.

Another excellent way would be to make guides available that are tailored to the needs of a Drupal developer to manage their projects.

The Drupal community is a fantastic place, but often we are left on our own to figure out things. Its definitely getting better, but we can never stop looking at how we can improve things. The d.o infrastructure has a lot of fantastic tools available, it just needs better documentation and educational resources to make them accessible quicker and easier for more users.

Tags:

Share this on:

Comments

Nigel's picture

Nigel (not verified)

Tue, 06/21/2011 - 23:03

I have personally been trying to build out a standard D7 platform that includes all of the common features that pretty much gets asked for in every project we do. So far, I am up to 45+ contrib modules and it's going well. Many of the are in your top 50 above, but some aren't. It has been great to contribute back, but it has taken a long time to get to the point where I can push a moderate-full featured website live. My instinct is to tell others to hold off another 2 months or so before going down this road, however, the only way to push contrib modules to a stable status is to use them. So, if anyone reading this, don't build your next site on D6, but start with D7 and help contribute (even if it's a bug report because you are not a developer and able to also supply a patch).

tsvenson's picture

tsvenson

Tue, 06/21/2011 - 23:19

Hi Nigel,

Couldn't agree more to what you say. Its also one of the reasons I had when starting Drupal Mill, and other projects, on Drupal 7. By building real worl sites we stress test both Drupal Core and contrib modules the way they are supposed to be used.

However, when it comes to building sites for clients its normally much more involved. If you have a great relationship with the client and they have full understanding about the risks involved, then using Drupal 7 is an option. But if the client does not understand tech, what open source is and so on, then it is very different and the risk by going bleeding edge is much higher.

In the latter case the relation between you and the client is at business level and they most likely don't care about what the site runs on, just that it does what they want and they get the return they expect. Thus, they will have little understanding that things take longer due to that code used is still under development.

So, the choice for what to use has to be made per individual client. At least until you are confident enough that your Drupal 7 dev setup is safe enough for the particular website project.

/thomas

Nigel's picture

Nigel (not verified)

Tue, 06/21/2011 - 23:29

I agree that it is dependent on the client. However, we make sure we spend the time with the client to help them understand that when they sign up with us, they also become a a part of the Drupal community. They are helping to contribute back to the free code they received in the first place. It almost helps to feel more committed to the project and empowered.

Rick Vugteveen's picture

Rick Vugteveen (not verified)

Wed, 06/22/2011 - 00:51

I appreciate the research and effort that has gone into this post. Never the less I can not share in the conclusion that D7 isn't ready for general site building. There is an underlying assumption that beta/alpha/dev releases aren't stable. This isn't the case in many of these instances. I've used the dev code for Date, Link, VBO and others and found the modules workable, if a bit rough around the edges. Using a make file with patches (as required) and keeping up with new developments takes some extra time but is well worth the effort.

Your analysis highlights that some of Drupal contrib has a problem releasing early, often and labeling releases appropriately. This not just a D7 problem. There are modules like ImageCache for Drupal 6 that are still "beta" but are known to be rock solid (and in now in Drupal core to boot!). For Drupal 7 to gain momentum what is needed are more frequent releases and more accurate labeling. Releases help site builders, instill confidence and increase adoption, ultimately creating a virtuous cycle of further improvements.

Aside from the versioning issue there are cases where Drupal 6 modules don't need to be ported or are no longer the best solutions. Examples include Image API and Poor Man's Cron being part of core and Media being a better solution than IMCE for file management (at least once it matures). Removing these projects out of the calculation would bring the ported percentage closer to 80%-90%. This is well beyond the tipping point for most all site builders.

Thank you again for the research and bringing up the issue. I hope this have added to the dialog and am curious if others have come to the same conclusion.

tsvenson's picture

tsvenson

Wed, 06/22/2011 - 03:22

Sorry, but I never said Drupal 7 isn't ready for general site building. It is, but when it comes to using contrib modules it requires a lot of experience and skills from the users. As many of us have limited coding skills, it means that we need to learn a lot and much time will also be spent on discovering the shortcomings of the no released modules.

Applying patches is something we also need to deal with, and that can sometimes be quite tricky when there is 3-4, or even more, patches needed for the same module.

There is an underlying assumption that beta/alpha/dev releases aren't stable.

That is not the issue for me as a site builder. The problem is that there is such a difference between modules. I have used Views for Drupal 7 for over a year (Since Drupal 7 Alhpa) and the parts of it that worked, worked well. Other parts didn't work at all becuase they weren't fully ported yet even though they where available in the UI. Then you have other modules that even after several betas are still very buggy.

The amount of time I as a site builder need to spen learning this is not small. Since I have a pasion for Drupal i don't really mind and I spend a large part of my free time doing just that, including feeding as much information back to the maintainers as possible.

However, from a business perspective it would not make sense to pay staff that spends maybe 30-50% of their time learning to go around the issues the dev to RC modules still has. Add to that that projects using modules in those early stages also need to allocate time/resources for fixing hickups when new versions comes out that breaks functionality with previous in development versions.

Personally I see it as a dangerous path if the Drupal community and users get used to using dev versions in client projects. What we need is better guidelines for how the development process from idea to full release is done and when a module changes from dev to alpha to beta to RC and finally to full release.

I am convinced everyone both within and outside the community will gain from that.

bojanz's picture

bojanz (not verified)

Wed, 06/22/2011 - 01:41

The fact is that the issue queue is a terrible place to communicate with users, if we disregard bugs for a moment.
User feedback (outside of bugs) is pretty much impossible. Providing a list of release blockers is done in every project differently (text on the project page, meta issue, tags on issue, or nothing at all). I imagine it gets confusing to people.
I'm talking about release blockers because if people are saying "module X in alpha/beta works nicely", then the first question is "what's preventing it from becoming a full release?"

In the case of VBO (whose D7 branch I'm maintaining), it's missing features (what's there tends to work, but there are a few pieces still missing.). It's only been a month since the rewrite and the fact that the thousand users using the new code are not screaming for my head is a good sign :)

I think it's time for every self respecting agency / developer to start building on D7. If you can't fix an occasional bug or two, or port a small module (since anything non-trivial has pretty much already been done), then that's just embarrassing.

tsvenson's picture

tsvenson

Wed, 06/22/2011 - 03:37

Can only agree with what you say about the issue queues and project status information. Hopefully the Prarie Initiative will soon start resulting in improvements there.

Regarding VBO. It is one of those modules I haven't personally used yet. It is on my shortlist of modules to start using though.

However, my observations when researching for this post is not much different from when I look for modules that seems to provide functionality I need. I look at the project page and the issue queues to quickly get an understanding about project, any issues and how active the development is. Many open bugs and long time since any commits where done does ring an alarm bell for me. I think that a lot of users are using similar methods as well.

Please also note that I clearly point out that many modules such are dependent on the development of other modules. In VBO's case Views, plus Rules as well. I fully understand that is something that blocks it from being ready.

chx's picture

chx (not verified)

Wed, 06/22/2011 - 01:41

You should mention for stalled projects where the whole project is stalled not just D7. And as others mentioned there's a lot that dont need porting or has been replaced by another module. The overall would be even better.

tsvenson's picture

tsvenson

Wed, 06/22/2011 - 03:48

Focus on the post was the status of the Drupal 7 versions. What state the modules are for earlier Drupal versions has no real relevance as I see it.

As pointed out in the post, modules that has been incorporated in Drupal 7 has been filtered out. Of the remaining 50 I can't see any that doesn't justify being in the list. Even CCK is justified since it provides migration functionality from Drupal 6 to 7.

lars's picture

lars

Wed, 06/22/2011 - 02:35

Interesting reading. Just wanted to say I think you missed a few modules. There should be 14 beta releases, but I count only 9 on your list, and from the list of alfa releases, Panels is missing although you mention it elsewhere.
tsvenson's picture

tsvenson

Wed, 06/22/2011 - 02:58

Well spotted. I have now added the missing modules. Thanks.

HongPong's picture

HongPong (not verified)

Wed, 06/22/2011 - 09:44

I think everyone should try to test patches. Usually you can see if patches deliver correctly from other respondents. In one case just recently I ran a patch that had been around for a long time and bumped the thread to say it was RTBC already... and then it was committed! Developers need to get some confidence to push the commits from the community. They also need to be nudged to release new alphas and betas when things advance. (votingAPI for example)..

And with the complex stuff people could set more git sandboxes, a powerful tool for forking & testing that hasn't really taken off yet. It is too much to put the credibility of the whole project on the line for a tricky commit, instead at least have a git sandbox fork with that angle available & actually findable. That kind of technique (projects working on github like this) could get us through the stalling effectively.

Jeff's picture

Jeff (not verified)

Wed, 06/22/2011 - 18:54

The other problem with being in limbo between D6 and D7 is that niggling D6 issues aren't getting eyeballs anymore as everyone's concentrating on D7.

I have a complex site with over 100 modules and it's taken 9 months to get it all mostly working right with plenty of patches. But now the remaining problems with a few modules just aren't getting any attention, and I can't be sure these problems are fixed, or just don't exist in D7.

Frustrating.

bojanz's picture

bojanz (not verified)

Wed, 06/22/2011 - 19:18

Then you fix the issues yourself. At the end of the day, it is unrealistic to expect anyone else to fit into your schedule and fix your problems. If someone (a maintainer, or random coder) does help out and fix an issue that's affecting me, I consider that a bonus, not a right. People might disagree with my thinking here, but it leads to much more happiness and much less disappointment (not too mention less entitlement which is often a problem in open source). Of course, not all projects are done completely by programmers, but every project must have one, who can help out.

You do raise a good point though, D6 development is slowly stalling, and in a few months it will become really noticeable. One more reason to start with D7 (where you'll undoubtedly get even more bugs, so the line of thinking in my first paragraph is necessary).

Jeff's picture

Jeff (not verified)

Thu, 06/23/2011 - 04:01

Like a lot of site builders, I'm not much of a programmer. Plus the reason many of the bugs left over in D6 still exist is because they; are complex and to fix them requires an in depth understanding of the module and Drupal itself. Also, some of these bugs have been looked at extensively by many users with no clear solution, BUT were fixed in D7 with the admission of no time to port the fix back to D6. I'm speaking specifically here of a bug in the i18 module and pathauto where translated taxonomy terms used as tokens for auto URL aliasing were screwed up - the wrong language was being used. The module maintainers said it was easy to fix in D7 but not in D6 and all but abandoned the D6 issue in spite of many users literally begging someone to help fix it.

So I have no answer for my client who is ticked off. As if turned out, after a year in development and with an otherwise very nice site, he pulled the plug and got another shop to start over with .NET. Ouch.

Lesson learned for me - don't do complex sites by yourself unless you're a crack programmer AND have the time to fix bugs like these, or have the knowledge ahead of time to avoid them. But who does? There's no way I or anyone else could have predicted this. I painted myself into a corner and was stuck along with many other people in the same boat. Upgrading the site to D7? Fuhgetaboutit - HUGE and risky task - too many customizations at the theme level to deal with.

THIS is a BIG problem for Drupal - abandoning old versions in favor of newer ones and leaving people like me in the ditch.

VM's picture

VM (not verified)

Wed, 06/22/2011 - 19:53

<blockquote>However, from a business perspective it would not make sense to pay staff that spends maybe 30-50% of their time learning to go around the issues the dev to RC modules still has.</blockqute>

Agreed. It would make far more business sense to hire a developer to aid in the process of porting the modules which are claimed to hold back the ability for any business to grow.

tsvenson's picture

tsvenson

Wed, 06/22/2011 - 20:44

How can that make more business sense? The only thing you accomplish is that you move part of the cost to an external developer. That developer most likely have a far higher hourly rate than your own staff costs, plus you will still have the cost for your own staff managing the contact with that developer. All that still has to be paid for by the clients!

The only time it would be possible is for very large budget web projects where the client has a long term plan. Then they look at what this will save them over several years as well as the advantages going bleeding edge will mean for their business.

For the waste majority of client projects the competition is very stiff. The client is often much more shortsighted and technology a much lower priority than the cost. They simply don't care much what the site is built on, just that it does what they want and at as low cost as possible.

Drupal 6 is still going to be around for another two years or more. By the time Drupal 8 is out then Drupal 7 will be mature enough to make upgrading Drupal 6 sites much smother than today.

This has nothing to do with how much passion I have for Drupal or want to help pushing the Drupal 7 project forward, its about being able to be competitive on a very tough market.

Remember, Drupal is not the only choice out there and Drupal 6 is certainly not dead just because Drupal 7 has been released.

VM's picture

VM (not verified)

Thu, 06/23/2011 - 00:47

I meant an internal developer but an external developer would work as well. Let's be straight forward and completely honest for a moment. If you are building sites with Drupal for clients and are making money with Drupal then the reality is that the business model can be manipulated to bene-fit a developer into it and charge clients accordingly. This aids a bottom line and the community as a whole with reference to contribution. If the business is solely focused on low hanging fruit then I'd say it's a short sighted plan to start with.

IMO it seems to me that the title "site builders" get's thrown around too often as a security blanket to afford many to say "not me".

salvis's picture

salvis (not verified)

Wed, 06/22/2011 - 22:25

Thanks for this interesting post.

For me as a developer and maintainer with limited available time and a number of modules to take care of, it's not project management that I'm missing, but useful feedback. Qualified feedback is very valuable and I tend to work on those modules where I get it. Others are headed for your "stalled" category. I may eventually get to them, mostly because I need them myself, but they may never get past beta status.

No amount of managing or educating me will change that. Providing testing and feedback, both good and bad, would...

alfredo's picture

alfredo (not verified)

Sat, 07/16/2011 - 16:52

From alpha and dev lists I worked before Drupal7 arise with Gmap, Location, Better Formats,Content Templates,Transliteration,Views Slideshow,Calendar,Date modules.

tsvenson's picture

tsvenson

Sat, 07/16/2011 - 18:23

Yeah some modules have moved up a bit. I will need to make an update of this list. Probably will move it to another place on the site, once I get the new features I'm working on ready.

drupal module development's picture

drupal module d... (not verified)

Wed, 05/09/2012 - 15:43

its really good for drupal module development

Add new comment