Drupal's Ladder of Engagement

by Larry Garfield

One conversation we frequently have with our clients is what level of involvement they want with the larger Drupal community. It is becomming increasingly common for our clients to say up front that they want to "play nice" with the community, which is terrific, but not all clients fully understand what that means.

Engaging with the community when building a Drupal site has a number of benefits both hard and soft. But there, are, of course, costs to doing so. There are also many different ways that you can engage with the community, each with their own pros and cons.

Fork it

Option 0 of course is to grab the code and wander off with it, modifying Drupal or modules directly to suit your needs. It's called "Option 0" for a reason: There are zero good reasons to do it this way. While it may be immediately faster to hack code to bits rather than trying to understand how it works, this approach always, always ends up costing more in the long run As soon as a new release of a module comes out with a security patch or a new feature you want or need, you discover that it's impossible to reintegrate your changes. You have created your own CMS that no one can support but you; Presumably you used Drupal in the first place to avoid being in that situation. Fortunately this is not as common as it once was thanks to a great deal of education, but some companies still fall into this trap. Please, don't let this be you.

No engagement

Option 1 is to do nothing. Any new code developed for the site is developed site-specific, not generalied, and not contributed back to the community. There is actually nothing inherently wrong with this approach. There is no added cost for time spent talking to module maintainers or reviewing patches or wrestling with Drupal.org's version control system. It's often faster to implement a one-off solution than to build a general solution, too. However, the lack of community time means that there is no future investment made in the community. There is no "community karma" built up that can come in handy when looking for support later. It also means that you're on your own to maintain all of the code you wrote. Single-purpose code often tends to be technically inferior to a general solution, too, and cost more maintain over the long term.

Module release

New code is developed as new releasable modules that are contributed back to the community on Drupal.org. This can lead to technically better solutions at slightly increased time/cost as well as some community recognition. Alternatively, a more general solution may actually end up saving time both during development and later during support. Modules that "play well" with existing approaches (Views plugins, Media plugins, Field modules, etc.) rather than being stand-alone mini-applications will be better received, especially if they are well documented.

That recognition may sour, however, if the modules are simply "dumped" and time is not allocated for ongoing maintenance. Abandoned modules do not generate good will. They may even generate ill-will. Before releasing a module, make sure that you have a strategy in place for ongoing maintenance, including handling of new feature requests or patches from others. You want to be a responsible maintainer. Don't be shy to add more maintainers from the community, too, if someone shows interest. Free labor is a precious commodity.

Module engagement

Far better than building yet-another-module that won't get maintained is enhancing an existing module. Most module maintainers are happy to entertain well-thought-out patches, especially if you explain the need for them rather than saying "here, I need this now". Be prepared for some back-and-forth with the maintainer as he or she reviews your patch, as it may need some work to get into just the right shape. Helping to extend and maintain an existing module is frequently better received than creating a new module, especially if that module is already widely used. It also means that you are not responsible for maintaining the module long-term, unless you decide to continue working with that maintainer long-term.

This approach can take longer than building a new module from scratch, of course, as the module maintainer may not be on the same schedule as you. You will need to factor in collaboration time and time to revise the patch a few times. It may also be problematic if the maintainer is inactive or uncollaborative, but most maintainers are happy to have help if it's offered the right way. If a module you need seems to be abandoned, you can see about taking over the module and improving it yourself.

Whatever you do, though, don't simply fork an existing module to a new project on Drupal.org. That's an excellent way to develop a bad reputation, as you're not helping the community but simply creating yet-another-unmaintained-module. Don't do that.

Community initiative engagement

The community at large recognizes certain needs that are unfulfilled or under-fulfilled, but they are a sufficiently large or complex problem that solving them takes more than just a module or two. Frequently they require a considerable amount of collaboration, time, or funding. This applies especially to improvements to Drupal core itself.

If your site faces one of these problems, working with other members of the community directly to develop, in the open, a better solution can yield the best technology for your site as well as the best response from the community. The end result has buy-in from many people, but as a key player in building the solution you get recognized as the go-to person or company in that space. The commercial PR you get back from that is worth its weight in gold, in addition to the karma you can then leverage when asking someone else for help on another problem later.

On the other hand, this can be challenging when there are frequently different competing needs, your own budget and timeline being one of them. The community doesn't always work on a tight schedule. For such a solution to be truly well-received, it needs to be built collaboratively and in public, not in a closed process and then released on a silver platter. Even if it starts out as your own private project, once it goes public and develops momentum you need to be able to let go and let the community drive it.

While this approach is the most challenging, it will also generate the most community good will and karma over the long term.

At Palantir, we usually steer our clients toward either Module Release or Module Engagement, depending on the project or task at hand. Sometimes a one-off solution is best; rare is the site that doesn't have at least a little bit of site-specific code. However, we've learned through experience that over the lifetime of a site, and definitely when spread out over many sites, building and collaborating on general solutions gives the best ROI over the lifetime of a site. And isn't that why we use Drupal in the first place?

Where possible, engage in larger community initiatives, too. Even if you're not driving one yourself, being part of those that are already afoot can help future-proof a site, generate a positive feedback loop of karma and support, and deliver a better product over the long-haul.

If I had to summarize engagement in the Drupal community, or any open source community, it would probably resemble a famous African proverb:

If you want to go fast, go alone. If you want to go far, go together.

Comments

Ha, funny comment, but the statement it's based on is so true and rings well with the Drupal community.

I tend to go for the Module Release and sometimes Module Engagement, which is what I think is in my current capabilities in Drupal. However, Larry, I find it a bit confusing to understand your statement about the Community Initiative Engagement: are you referring to starting something and let the community take over, or more as a sort of "marketer" for collaboration? If that's the case, I feel it would be the kind of thing that someone, even with little technical background (or none at all), could very well use as a way of pushing the community that extra step when it needs it.

One of the things that characterizes a large initiative is that it takes many different kinds of input. A bug fix or minor feature addition just takes someone to code it and someone to test it, but major changes require input from lots of people.

As an example, there's currently an active discussion about Search in Drupal. Core search sucks. Core's search API is simply not up to the task of, well, anything useful, and its search algorithm is sub-standard compared to the other options available. The apachesolr module in contrib is built around the existing core API, and assumes a specific workflow. There's the search_api module in contrib, but that's still very new and has some kinks to work out.

This is a hard problem space. So if you're doing anything major with search, do you:

1) Write a new search module yourself and release it? Do you maintain it after doing so?

2) Work with either the apachesolr or search_api maintainers to improve those modules to the point that they'll do what you need?

3) Get involved in this ongoing community initiative to improve the search world in general: http://groups.drupal.org/node/117274

#3 is the "community initiative" approach; better end result, but takes longer. And yes, there's lots of things that could be done:

- Help (constructively) architect the new approach on that thread.
- Attend or pay someone to attend the Core Conversation session at DrupalCon Chicago where this issue will be discussed.
- Offer time to help develop a new search infrastructure.
- Offer time to help test a new search infrastructure.
- Offer time to help coordinate the work of building a new search infrastructure (very important).
- Offer time to test test test test test the search system as it is developed.
- Offer time to do usability testing and accessibility testing on any interfaces that are proposed.
- If some parts of the system are completed early, try using them in pre-release form. That will help flush out bugs and design flaws early when they're cheaper to fix, even if it may make the project you use it for a bit rougher at first.
- Offer sprint space at your offices for people doing any of the above to get together and collaborate.
- Probably others I'm forgetting.

This isn't actually a made up example; Palantir is actually facing exactly this question on an upcoming search-intensive project, and we're weighing the pros and cons of all of the above approaches. Naturally we'd like to go with the "community engagement" approach, but time and budget may limit that. So could we do it in such a way that anything we do lends itself to future work by others in this area, even if it's not part of the over-arching framework? Well, maybe. We're looking into that right now. That's one of the things that prompted this article. :-)

Very nice article delineating code-sharing, module maintaining and community values. I'll definitely be incorporating your clear and robust explanation. Thanks for a thoughtful framing of an answer to the question, "Why Contribute?"

------------>
alone & fast
==== ==== ==== ==== ====>
together & further, and slower
__________________________________

I don't necessarily agree with the above diagram; at the very least, it should be put in perspective.

The Theory of Relativity was developed by a lone genius named Albert Einstein. Had he kept it in his desk drawer to himself, he can be faulted for not "collaborating" and advancing science. The fact that he PUBLISHED it in a scientific journal, albeit an obscure journal, IS itself an ACT of COLLABORATION. Period. Another lone genius, Linus Torvalds, developed Linux on his own time, and then he released on the Internet. Had Linus chosen not to maintain his OS after he released it, that's within his rights and perfectly normal. His code is open source and anybody can now "collaborate" as they see fit.
Somebody like Albert and Linus have to come up with an original idea for the rest of us mortals to have something to collaborate on.

Conversely, we can lock up 1000 people in a room and then tell them "ok, collaborate on 'nothing'", we will still get 'nothing'. Adding one more person in the room just to have 1001 bodies would not necessarily lead to a productive result. In IT especially, religious wars and strong disagreements can ensue in a so-called collaborative setting and can therefore impede progress.

My point is: the two development processes COMPLEMENT each other. Contribute in any way you can, in the way that is most productive to the individual, and therefore to the whole.