You are here

Pitfalls of the growing community

Last weeks (maybe months), there is an active, sometimes heated discussion on the future of Drupal development - in twitter, blogs, forums etc. There is common understanding, that people "don't scale well", and to cope with increasing complexity of the Drupal code, developers community needs to attract new contributors.

Benefits of attracting new contributors are clear enough, but probably it could be interesting for Drupal veterans to know how discouraging newcomer experience can be.

So, let me tell you the story of A. A is a (relatively) new Drupal contributor. Which, by the way, does not mean he is a new developer. He has more than 15 years of programming experience.

He doesn't know in person anybody from the outstanding team of developers who are the driving force behind Drupal. Like many others, A became a contributor when he wanted to solve his own problem - lack of solution for a very common website building task in Drupal 7, when it was released in January. "There was module for that" in Drupal 6, but not in 7.

The last thing A wanted to do is to reinvent the wheel, so he searched the Internet, and d.o., and forums...

Good finding: there was a placeholder module aimed to solve the problem! And it was opened by the same person who maintains "the module for that" in D6. Let's call him B.
Bad finding: placeholder did not contain any code, and from IRC conversations/twitter posts it was clear that, unfortunately, this situation will not change soon.

So A decided to solve his problem by himself, and offered his solution to others - as another module.
Several things were important for A from the day 1:
  • solve very particular problem and not to try to become Swiss army knife
  • aware module users of probable future solution when (and if) B will actually write his code
  • follow the code of conduct
  • accept other people's help
  • keep B informed
  • be a responsible maintainer

When A released the first stable release of his module, he suggested it to be the base of B's future module. For technical reasons (B chose different approach to the problem) that was not done.
Anyway, it turned out, that quick solution which A made for himself, is demanded by other people. Installation base started to grow quickly. Yes, there are problems, bugs, issues, but there's feedback. It makes A actually proud. He feels that his work is needed, and gets incredible energy and strong wish to help drupal in other ways. A has tasted that poison :)

Now please excuse me for the short comparison:

  • A's module has 2nd stable release. B's has unstable snapshot of 1.x series
  • A's module supports upgrade path from original D6 module (by the way, written initially not by A, but by another user needing that feature). B's upgrade path is "under discussion"
  • A's module uses existing core APIs, B's creates APIs of its own

Following users' demand, A adds more features that make his module closer to "extended" feature set planned for B's module.
So, A's module has stable release, growing user base, and is actively maintained.

The sensitive point starts, when, after several months of inactivity, B renews (actually, starts) active development of his module. And this development is sponsored by 2 leading drupal shops. If you check both modules' issue queues, lot of people still see A's module as interim solution, that should be immediately replaced by the first stable release of B's module.

I would say this is weird.

Such situation does not add self-confidence to A. He doesn't want to "compete" with anyone, especially with people that he deeply respects (and B is definitely in that list). There is no doubt that B is able to complete his module, and that this module will work just fine. But... there must be a serious reason to do so. Because now, there is a solution to the problem B's module will solve.

In the end, A just wants to have fun from contributing code. The fact, that companies sponsor violation of collaboration rather than competition principle, is not fun. The fact, that someone else starts to solve the same problem you have already solved, is not fun.
Emotions aside, A wants to be able to mention in his resume that his efforts are respected by the community.

Most, if not all, voices in the "big developer appeal" discussion, belong to the people who live and breathe Drupal for a long time. They are Drupal, actually. But these people have to understand, that if an attempt to attract new contributors will succeed, this is going to change. Forever. This can be painful for several reasons:

  1. Drupal developers community is a geek community. For an average geek, personal relationships take more time to establish, yet they tend to be more tight. This makes existing community strong, but also creates certain barrier for newcomers. It's much easier for the "old" members to talk to each other, simply because they have more common memories. Drupal veterans had a long time to bring their technical, social and cultural values to more or less the same level. Relatively harmless example: it's a good tone in Drupal community to disagree with president Obama (just to make clear - I am not a US resident). Think a moment, and you easily reckon much more sensitive examples. Nobody can guarantee, that new community members share the same culture. Excellent analysis of what can happen just as a result of cultural difference, based on the recent incident, was done by Earl Miles.
  2. People that have spent endless days and nights, both of their work and  free time, working either on core or contrib modules, get "parent syndrome". You know, when you grow up a child, it's hard to accept that someone else can love him or her as strong as you. Defend, take care, grow up further... Like parents of grown up children, "old" developers have to accept that someone else can take care of their modules. Not better than you. Differently. Yes, it is possible that new contributors can screw up with your code. It is possible as well, that with constantly increasing amount of code, you will screw up with your own code without any external help.
  3. Also, like I said, the "old developers are Drupal", will change to "old+new developers are Drupal". In other words, Drupal will change, in a way that will not be controlled or planned solely by veterans. Hopefully, "new developers appeal" will attract 2 kinds of developers: without any experience at all, and with experience in other platforms. First group must be nurtured, educated and promoted - this will take time. This group can give Drupal strong push... in several years. For immediate push, drupal community needs the second group. This push will be effective only if developers coming with baggage of other platforms experience, will get equal voices with Drupal veterans.
  4. The story of A and B shows that while all developers are formally equal, some of them are "more equal than others". This is not B's fault that his efforts are respected more - he does awesome work for the community, and does it for years. How to give respect and encourage A - that's a serious question to community, and I don't have ready answer to that question.

To survive and succeed, Drupal community has to scale. And growth means not only positive emotions, but also explicit and hidden problems. How did Mad Eye say? Constant vigilance! :)