The business of Drupal - Notes from the Drupal Executive Days Meeting in Brussels
Drupal is most definitely growing up. What else would justify a 2-day meeting of Drupal executives in Brussels to discuss how to deal with the pains of fast growth and the entrance into the market of the so called "elephants". The elephants in this case are large consulting companies such as Cap Gemini and Accenture who are using Drupal as part of their suite of solutions and are thus introducing Drupal in multi-million project environments.
I will try and summarise any conclusions / lessons learned that I think came out of the meeting and what all of these means for the business of Drupal in Europe. This blog post should come with two warnings: 1. This is what I got out of the meeting - it may well be flawed or skewed to just what I paid attention to 2. I typically write about technical issues so I may not be using the best possible business terminology to describe things.
Who was there
You can get the list of attendants from the Drupal Executive Days website - the companies represented ranged from freelancers to larger 20-30 people shops, mostly Drupal-specific but also some more generalist shops with a large Drupal component. Acquia, represented by its CEO Tom Erickson was arguably the largest pure Drupal company there.
How was the meeting organised
Kristof (the main organiser) had the the brilliant idea of structuring the meeting as an Open Space Technology event - a format that I had never encountered before. At the start of each day people suggested topics of interest to them that were allocated time slots and rooms and people divided themselves between these topics throughout the day. Typically the person or persons that suggested the topic opened proceedings but generally the meetings simply evolved organically with all getting the chance to offer their views or pose questions. The format was great because it provided just enough structure to get things done whilst allowing plenty of space to adapt throughout the day and provided opportunities to meet , network and discuss with people.
What was discussed
The topics were varied and a complete list can be found on the meeting's website but really I think they can all be summed up by an overarching concern that then breaks down into at least 5 challenges that Drupal shops face.
The main concern, as far as I could distinguish, is this:
Demand for Drupal-based solutions is rocketing - how can our businesses meet current demand and ensure that they best take advantage of it so that it translates into long-term growth while managing to compete or profitably co-exist with: a) the big (and medium-sized) elephants coming in and taking on the big (and medium-sized) projects as well as b) non-pure Drupal companies that jump on the bandwagon and look to undercut on prices (with often a hit on quality as well).
This overarching issue then breaks down into
1. We need more Drupal developers to grow - how can we find them or find people to train?
2. We need to quickly streamline all our back-office operations to deal with bigger projects - let us share and learn from each other.
3. We need to up our game in terms of marketing Drupal and presenting ourselves.
4. We need to find means and methods to gain access to the larger projects and ensure that big-profile Drupal projects do not fail as it will reflect badly on all of us.
5. We need long-term strategy and vision to translate the current positive moment into something more lasting.
Developers where art thou?
All businesses at the meeting from the single-man shop to the 20-30 people company are desperately looking for more people in order to grow, since projects seem to be plentiful. There are two routes to getting more people. Training them and/or finding ready, experienced Drupal developers. Both seem to be extremely challenging.
Finding experienced developers
Experienced developers are hard to come by because all the good ones are already tied up, learning Drupal to a sufficient level takes a long time, and people that are already experienced developers in other technologies don't seem to currently feel the need to switch to Drupal.
Training new people
Training new people is costly, you will only see the benefits in the future and shops that are growing quickly today have all their resources tied up in trying to deliver projects rather than being able to train people. At the university level few courses talk about let alone teach Drupal, and it may be hard to convince academics to introduce it in curricula although some interesting work in that direction is taking place.
What to do
Drupal needs to market itself to developers and make it clear that Drupal is a sexy technology to work with - if universities don't teach Drupal we need to excite students to learn it on their own.
Certification and clear career paths may also attract other people into the community who are unsure as to how one goes about it and what prospects or future there is.
Drupal shops need to recognize this as a clear and present danger to their growth and invest accordingly so that Drupal's success does not become its undoing because if people don't find someone to do the project in Drupal they will then simply turn to other technologies.
The problem can also partially be alleviated by closer collaboration between companies so that projects can more easily be distributed within the Drupal ecosystem. In this respect Drupal shops have agreed to open up communication channels so people can advertise services available and services wanted to enable match-making between shops on projects.
This issue is, in some ways, tied to the lack of developers. If there aren't enough people to do the job we must at least ensure that the people that are there do the job as efficiently as possible. This means streamlining all operations so as most of our time is spent creating awesome Drupal sites as opposed to invoicing, writing contracts, accounting or trying yet another ticketing system.
A lot of information was shared at the meeting and we will begin to see resources online to help shops. A survey will be co-ordinated to figure out what systems Drupal shops use and what lessons can be learned.
This is a great idea to create professional-grade marketing material that all businesses can have access to when presenting Drupal to their clients. It ensures that Drupal shops will save time but also that Drupal will be presented in the best possible light.
Accessing large projects
Given that the current Drupal ecosystem is made up of lots of smaller companies (especially in Europe), the large projects are hard to get. Government contracts or multi-million projects needs the assurance of large organisations behind them and need to talk with entities that are in it for the long term and are accountable.
Several solutions to the problem were discussed such as:
1. Creating closer ties with the big elephants so that once the larger companies do get the big projects they turn to the smaller Drupal-specific companies for the realisation of aspects of those projects.
2. Creating virtual entities that can provide the single point of contact and continuity that large projects needs but that allow the smaller business to retaing their identity - coming together to work on a project and disband once more. One such effort is Drushi.com.
3. Merging and creating those larger entities so that we can compete.
This is a complex issue with lots of ramifications, plenty of which require deep business know-how to fully appreciate. No doubt many more discussions on these lines will take places and various models will be tried until the market itself will settle on which models to award as winners.
Right now all the companies in the Drupal ecosystem are young companies - and their executives are quickly learning both how to run a company and how to better do Drupal websites. The demand for Drupal work means that there is little time left aside for long-term planning. This, however, is a crucial exercise for the longevity of a company. We had interesting discussions about the challenges that service-based companies face and the possibilities for a product-based company within the Drupal ecosystem. We also discussed the different between Drupal where you have lots of generalist shops and something like Joomla where companies focus on specific products.
Once more, there isn't a single solution but the knoweldge shared will greatly help all of us in determining what to do.
There you have it - in all a great meeting that has certainly helped us to think more about what we are doing and how we should do it. Without wanting to sound to celebratory of one's own community Drupal has once more proved that it really is all about the community - a community that stretches beyond just sharing a common codebase.