Earlier this year Dries wrote about "The investment case for employing a Drupal core contributor". This become a hot topic this year, with Dries dedicating  a large portion of his DrupalCon Amsterdam keynote to how we can incentivise Drupal companies to employ contributors to work on Drupal Core full time.

I feel like this is being introduced as the only way for companies to support core development, when it is not. I think there are far more options out there that benefit the supporting companies and the community as a whole.

I think that Chapter Three did a great thing when they hired Alex Pott to work on Drupal core full time. Having a full-time Drupal 8 core committer has really accelerated momentum and really influenced the issue queue.

Just done my 3000th commit to Drupal 8. Thanks for all the patches #Drupal community! And thank you @chapter_three for your support.

— Alex Pott (@alexpott) November 21, 2014

But I don't think that every reasonably sized Drupal shop should hire their own Alex Pott.  Here is why:

A large investment

Assuming you're paying the salary of a senior developer, it's a big decision to employ someone full-time who isn't directly generating any revenue. It requires a certain level of confidence in the diversity and the size of revenue for a company. This is fine for the Capgeminis,  the Chapter Threes, or the Wunderkrauts of the community, but not all Drupal shops have this level of confidence, for various reasons.

@webchick @paulmitchum @crell @yesct very few businesses are so heavily invested in Drupal that hiring a core would be justified.

— Paul Johnson (@pdjohnson) November 20, 2014

Discourages diversity

The Drupal community is lucky to have such a diverse range of contributors with varied backgrounds as well as professional experience in accessibility, design, frontend development, e-commerce, project management, nodejs, and so on. This diversity is important to ensure that we're building a framework that solves the needs of the whole community instead of the few who have a loud enough voice. It also helps ensure quality of all the aspects that make up a modern web product.

Over reliance on the few

Greg Dunlap covered this in detail in the excellent blog post "Stay for the Community". He highlights the problems in the community that appear when you have a select few people who are essentially required to move the project forward.

...the top 10 participants are in-part responsible for over 20% of the patches committed to Drupal 8. In fact the top two participants are responsible for almost 9% of the patches alone. Obviously these are people you need if you want the project to move forward. However this also leads to the horrible situation that when one of these individuals starts behaving in a bullying or abusive manner, there are numerous disincentives to speaking up against it or, if the problem is severe enough, ejecting them from the community. Their productivity makes them immensely valuable, and their friendships make it less likely that others at the same level of contribution will be willing to speak up against them.

This is, in my opinion, one of the worst current effects of our do-ocratic structure. It is yet another way that we alienate new contributors, especially if they get called out for behaviors they see empowered contributors exhibiting constantly. Also, you know, being a jerk is bad, but it’s even worse than you think.

I don't think that every major contributor in the community becomes a bully, but I don't think it's healthy to increase reliance on a few key members. I don't think it's a good suggestion to say the only way for a company to contribute is to elevate one employee to essential status. I don't think it's healthy for the community. 

@lewisnyman @PaulMitchum @YesCT @jpstacey @pdjohnson @webchick The "rock star" mindset I'd destructive to everyone, including the rock star.

— Larry Garfield (@Crell) November 20, 2014

It also produces burn out, when major contributors invest so much time or energy into core that they feel that they need a holiday from the issue queue, or that it's influencing their career path in ways they don't want.

An alternative suggestion: Grow your own contributors

Instead of hiring a core contributor into a company, what if we encouraged others to create contributors from the employees they already have. For all we know the next sun or chx is out there, but has never had the encouragement or support to contribute. 

Even if that isn't that case, I would still rather see tens of contributors with a modest number of patches than one who has an extreme number. There are loads of additional benefits for a business, large or small.

The best training, for free

Every company that works with Drupal is going to have to deal with the hurdle of Drupal 8, ideally before it comes out and they need to use it for client projects. Contributing to Drupal 8 is the best way to learn Drupal 8.

Not only do employees learn about Drupal 8, they also improve their entire skill set.  All Drupal 8 issues have to pass core gates in: documentation, accessibility, usability, performance, and testing. People who work on core issues learn about those areas. 

They also get to interact with other experts in the community, working together to solve problems, and learning from each other.

Working with the community builds other valuable skills, that are not strictly about technology, applicable to internal processes as well as to client work.

For even more benefits, see Strategies for businesses investing (in Drupal 8) through giving their employees Drupal contribution time, which is an excellent resource.

Did I mention it's free?

Bring Drupal 8 closer, faster

At the moment, there are loads of improvements to Drupal 8 that we can't take advantage of because there is no stable release. Helping push Drupal 8 closer to release means we can take advantage of these benefits sooner.

It also means we can improve the quality of Drupal 8 before release, by fixing minor, non-release blocking issues, so it's more polished and suits our needs better.

Establishing relationships with potential employees

There's no better place to find talented and dedicated people than at contribution sprints. It's a natual way to connect and get to know what people are like to work with. 

What we are doing to grow contributors at Wunderkraut

A month ago at WunderCon, I held a BoF on how we could increase Drupal 8 contributors at Wunderkraut. The latest stats on drupalcores.com shows around 30 contributors, that's a little under 20% of all Wunderkraut employees. I would love to get this number above 50%.

Of course there are many other ways to contribute to Drupal apart from just code, but it's the only hard metric I've found so far.

Of the 12 people who attended the BoF, about 3 people said they contribute to Drupal core in their own spare time (including me). When I asked how many people would contribute if they were given company time, all 12 people put their hands up.

When asked how much experience they had contributing, some people stated they just didn't know where to get started. Other's said they had tried once, but their patch never go reviewed and went stale, so they gave up.

These are two problems that are shared widely across the Drupal community, which means we can reuse solutions from the community and apply them internally.

Wunderkraut core office hours

In the UK office, we're lucky enough to get every Friday to work on personal development and community contributions. I'm using this time to write this blog post right now!

Not every office is able to commit to this, so we started small. Every Friday afternoon, we run an internal version of core office hours. If someone doesn't know where to start then experienced contributors like myself can help them find issues they can work out and help them if they get stuck.

If we're all contributing at the same time, it means we can work together, help each other out, and review each other's patches to move forward quickly. Mario has already had his first contribution committed to core.

More Wunderkraut hosted sprints

The Helsinki office is already very good at hosting and running sprints for the local community. This is also a great benefit for the company, because we can attract great Drupal contributors and mentors who can help others and share knowledge. I'm hoping we can share knowledge with the rest of the community, so more Wunderkraut offices can start hosting sprints. The added benefit for Wunderkraut, is an excuse for employees from other offices to work on something together, which doesn't happen all the time.

There are loads of ways companies of all sizes can contribute to Drupal 8, not just by employing one full time contributor. For more examples of ways to contribute, and really detailed information on how to achieve them, read Strategies for businesses investing (in Drupal 8) through giving their employees Drupal contribution time.