The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

Another growth problem: shrinking amount of core contributors

Submitted by nk on Tue, 2009-12-29 20:12

While Drupal 7 is awesome, it's quite clear we have a problem: we do not have enough core contributors. According to Greg's post there are less than 700 contributors to Drupal 7 core. Compare this to Angie's report on Drupal 5 and 6 where the number have doubled -- and now it shrinked. Shrinking amount of contributors combined with a growing code base is uh oh.

The worst is that most reasons are side effects of otherwise really and truly awesome happenings. This is not a critique of said happenings this is a description is where we are now as far as I can see:

  1. Drupal 5 and 6 are too good. Everyone is busy building awesome websites with them. There is no pressing need for Drupal 7 apparently.
  2. D7 is even better. While automated testing is undoubtedly awesome, it raised the barrier of entry because while clicking around in HEAD was never a good use of our limited resources it was a way to ease into core development.
  3. And minor problems existed which are now gone because that pesky bot keeps HEAD stable (that's soooooo bad! :p). Fixing these were also "onramps" into core development.
  4. Talking of onramp, we have coopted our biggest resource helping in this area to be a core committer. Once again, I do not mean this as a critique of anyone, it is awesome to have Angie as a core committer but this is a fact.
  5. D7 became more complex. Take field API which is now ubiquitous in core -- it's a fairly advanced topic.

Ps. This post was triggered by the zero people showing up yesterday to help with update manager which is a feature so many people want.

Commenting on this Story is closed.

Submitted by xtfer (not verified) on Tue, 2009-12-29 22:52.

While I agree with you that Drupal 7 needs lots of committed core contributors, I wonder if the factors you discussed above have contributed to the smaller number in a good way. For example, if there are automated testing and management features (as you discussed) then less folks are required to test and debug. Also, it depends to some extent on what features people are working on: if 100 people work on 10 features, thats better than 200 people working on 40 features.

Another factor to consider might be how you count "contributors". I have tested drupal 6 core patches, and on a couple of occasions attempted to pitch in writing patches - though I don't have the strong programming background to do anything clever.

I'm not pretending to understand the scope of the problem, just floating some more ideas.

Do you think it would help if there was a clearer contribution path into Core? I don't mean for features, but to get developers feet wet in some way first? Would Smallcore help?

Submitted by nk on Fri, 2010-01-01 19:20. l. Let's stop saying "smallcore".

Submitted by Anonymous (not verified) on Wed, 2009-12-30 04:06.

Another point: contrib is another way into core development, but contrib will be harder to do in D7 too. Half the point of abstraction is to make code easier to read, write, and learn; but a lot of D7's new API's raise the DX learning curve very significantly. There was a lot of simplification in existing API's, but unfortunately the new API's haven't undergone the kind of UX testing that the interface has while in reality DX is at least as important, probably more so. UI is something that can always be added or modified later while building a site, but DX decides whether or not a site will use Drupal.

Submitted by webchickenator (not verified) on Wed, 2009-12-30 09:16.

Those stats don't quite paint a total picture, since the 5 and 6 ones were both taken at the day of the final release, and D7 still has... a ways to go yet. ;)

However, I generally agree with your assessment about some of the challenges that we face. Testing bot is indeed a double-edged sword, though the problems it creates are really nice ones to have. ;) The size of the tarball has doubled, which indeed means more code, and thus more complexity. And reviewing/committing patches does indeed take valuable newbie contributor helping time away (though I think that for the most part I still do that as much as I ever did; my brain needs time once in awhile to take a break from delving into the innards of DBTNG and relax a little, after all ;)).

Coincidentally, I put out a notice this evening about the forthcoming 7.0 alpha 1, and I think at that point Drupal 7 will start becoming a lot more "real" for people, and we will hopefully pick up some additional recruits to help guide us to release. Or that's my hope, anyway. :)

Submitted by Jacob Singh (not verified) on Wed, 2009-12-30 13:11.

How do we create an efficient workflow so that someone who is not a "sponsored" developer like yourself, Crell, Angie, etc or someone who is "lightly sponsored" like me find a way to plug-in as a part of their job. That's what's important IMO. As long as people are itchy, they will scratch that itch. I don't know how to generate that, but we need to give people some motivation beyond "the software is cool" - which is also a valid reason.

Regarding the update sprint, I couldn't come as I mentioned to dww when he told me on the 26 with a confirmed date already. I think that planning it during the Christian holidays makes it really hard for people who have tons of family around. Perhaps companies can start sponsoring working groups (i.e. Acquia pays me, NP pays you, Someone picks up Derek, etc) so we can have regular sprints and have it be part of our workload...

I dunno... good points, but I think we need to figure out the economics of it and have some full time facilitators who can route people and on-ramp them if you want to attract hordes of people.

Submitted by Crell on Thu, 2009-12-31 23:57.

To clarify, I am not "sponsored" to work on core. I do some contrib work on my employer's time (Palantir), but 99.5% of my core work is on my own time. I just happen to have large itches. :-)

Submitted by adrinux (not verified) on Wed, 2009-12-30 21:44.

Well, it *is* between xmas and new year - for a lot of people there are other commitments at this time of year. That said I think update manager is a feature most requested and required by people who have little ability to manage drupal sites, let alone program. The very people that need update manager are the ones least able to contribute.

For many of us drush, drush_make, aegir and DVCS are where the future lies, and none of those are in core, never will be. Update manager is not an itch we have a desire to scratch.

I get the logic adding this sort of feature - it will attract more people to drupal, increase the size of the community and the market - and it's an excellent feature to add, it's just there are so many other itches to scratch first.

For the rest. Yeah. Lets hope Angie isn't too burnt out to shoo people onto the D8 onramp...

Submitted by eigentor1 on Thu, 2009-12-31 08:03.

True observations. I have not observed core development in D6 but it appears to me that there are more people doing a lot of work, so the 700 there are loading 16 tons still. I would suspect it was more some few people doing the heavylifting in previous versions with a lot just adding a peanut here and there?

Just speculations, the statistics department please prove me wrong.

I support strongly point 5 to which you can add: catch moving to japan and being temporarily unavailable :)
A really great entry point last year was GHOP which brought to us if I am right Jimmy Berry, Dmitri Gaskin and Charlie Gordon.

Angie and Catch were busy in core very much this year so no GHOP because of lack of Resources. If there is a D8GHOPX I hereby pledge to help out since this was sooo successful.

What also might be a stepping stone is Drupal's very autonomous API's. I guess it is definitely not effective to start porting Drupal to CakePHP or another framework, let alone even possible.

But I hear repeatedly from seasoned Web Developers that they had to work with Drupal and hated it - for the sole reason that the learning curve is too steep and they find little that they know. So maybe we should reconsider including more external libraries and known patterns and best practices to keep Devs flocking to Drupal and beig even more awesome.

There appears to be a notion in Drupal that we can do anything better than anyone else and thus rather roll our own. This may partially be true but makes up for quite some problems. Being - let's be honest - absolutely dominant in our area (Joomla and Wordpress serve totally different markets) we could affort rethinking some of this and being the real world domination Framework our beloved drop deserves to be.


yo man

Submitted by nk on Thu, 2009-12-31 08:34.

And it did not happen for a second time yet. Hopefully next year. And Dmitri was with us before GHOP but indeed GHOP brought us Jimmy and Charlie :)

Submitted by mike stewart (not verified) on Thu, 2010-02-25 01:41.


new drupal developers not already using CVS simply won't adopt it. its arcane. it speaks poorly of the drupal project.

GDO upgrade #FAIL

I think the community as a whole has suffered tremendously due to gdo upgrade. I don't want to take away from the volunteers that helped, it is a difficult, time consuming task, however the final effect has been a detriment to the community.

- many users still complain of not being able to login
- email notifications are a complete failure. they were sad before, but useless now
- css & theme fixes have never come

This simply doesnt attract new or noob users. Longtime users that relied on email for news are now unable to EASILY contribute.

Submitted by chanel (not verified) on Thu, 2010-09-16 09:32.

love you, love your sharing!