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.
- 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.
- 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.
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.
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.