This weekend there was another Drupal CxO meeting in Amsterdam. After the big success of the first meeting in Brussels this was the second event of this type in Europe. This time with a focus on development, business and quality assurance processes in Drupal shops. The format of the meeting was Open Space, so no presentations, no slideshows and no fixed program. In this post I will give a short summary of some of the topics that were discussed last weekend.
Contrib vs. Custom
This session was about choosing contrib modules or using with custom code. When to choose what. The average ratio contrib vs. custom was about 80% to 20%. Everybody agreed that if there is contrib module that does what you want, the best choice is to go with that. But often the functionality you want can only be achieved with a combination of a lot of modules that all do a little bit of what you want. The more simple solution in that case is writing a custom module for that project.
Another problem we discussed is the activity of module maintainers. Almost everybody had experienced the situation that they submitted a patch for new functionality or a bug and there was no response at all from the module maintainer. You can try to overtake the module and become the new maintainer, but the procedure is not very easy to find and very often that is also not what you want. Baris Wanschers pointed out that maintainers could be more actively looking for co-maintainers. If someone submits a patch to your module and it's of good quality, ask that person to become the co-maintainer of the module. In that way you also increases the involvement of the community. I'll think he will be writing a blog post about this issue in the near future to get some discussion going on how to deal with this problem.
update: Baris wrote a blog post on this issue and you can find it here.
This session was about Jenkins and how to use it with Drupal. Jenkins is a Java tool which makes it easy to implement a so-called continuous integration system. This can be used to automate deployments to different environments and do automated testing. You can use it for example to trigger automated test on a push to a certain branch in your Git repo. This test can run all simpletests in your project and check if the code complies to the Drupal coding standards. If anything fails the developer can be notified. It's also possible to do automated selenium tests for integrations testing.
Installation of Jenkins is not that hard and there is a config file for using Jenkins with Drupal available on github. Some more information on configuring can be found here and here. If you don't want to install and maintain your own Jenkins instance it might be possible to use a cloudservice like cloudbees. I don't know if there are limitations of this service. If anybody has experience with it please let me know.
Another interesting session was about tools that Drupal shops use for CRM, ticketing, customer support, financial administration etc. At Triquanta we mainly use Redmine for all this tasks but it is not ideal. I will just give a list of tools that might be interesting.
- CiviCRM which has a great Drupal integration. It is not targeted at organizing your sales workflow.
- Capsule which has integrations for all kinds of other stuff.
Resource management / Project management
- Lego. Hoppinger is using this and looks very handy and cool. No digital systems and a simple overview.
This was an interesting session of course. What does Acquia mean for the community. Is it threat or an opportunity. What is the benefit for your shop to become a partner of Acquia. There was some skeptisism about Acquia and I think that it is healthy to be critical about the function of such a company in the Drupal eco-system. However, I also think that Acquia is necessary for us to get a foot in the door at the enterprise projects. They demand a insurance and support level the small Drupal shops can't supply. Because Acquia does not do development in any way there is enough room for Drupal shops to develop a viable business.
Of course it can be that Acquia becomes your competitor if your focus is not development. Acquia will develop more distributions, deliver more SaaS solutions and expand there hosting services. If that is your main business it might be a tough competitor.
Project management in software projects is a hot topic. A lot of projects fail because the project is managed in wrong way or the specifications are not clear or the expectations of the customer where off. Agile development maybe can be a solution for this. I really believe that agile project have much more chance of succeeding and a happy customer.
At NodeOne all the projects are done with Scrum and they are very happy with it. The discussion was mainly about how to convince a customer to go with scrum. Most clients demand all three parts of a project:
- Quality / functionality
It is not possible to satisfy all constraints for 100%. That's why so many projects fail. Requirements always change during a project. For big projects it is simply not possible to take all the variables into account up front. Developing with Scrum ensures that the functionality can change during the project and the client is in charge. They decide what to build and how important that is.
The experience at NodeOne was that convincing a customer was not hard at all. They are in the process of making a generic contract that they can use for all of their projects. If it is finished they will open source it so other Drupal shops may use it too! An eye opener for me was that they do not sell websites, but the process. NodeOne does not take clients anymore that do not want to conform to their way of working and I think that is a wise decision.
More on the agile contract here at the NodeOne website in a report of the Drupal process meetup.
There were also some more hands-on sessions like the one about business models and unique added value. After a short introduction from Kristof van Tomme about the business model canvas we tried to make a canvas for the typical Drupal shop:
I think it is a very interesting way to develop a business plan and makes a business plan more visible and tangible.
The last session of the day was about pricing strategies. How do you decide on the price you charge your customers. Do you use a flat fee or do you differentiate. How is the price Durpal development compared to other systems. Do you use outsourcing or not? All difficult questions with no silver bullet answer. It is also dependent on your focus of course.
An overall conclusion of this session was that in general Drupal developers do not value their added value high enough. We should look more at the value we add for the client and base our rates on that. This is a mind change for most Drupal shops.
This meeting was again very inspiring and we can all learn from eachother. A danger is though that we are all quite alike. Most of the Drupal shop owners have a technical background, are in business for a few years, and are about the same age. The conclusion was that we can use some input from the outside world like a marketing or business model expert. This will make it possible to take Drupal to the next level. Some of this will be touched at the next CxO in Rome about Drupal and products.
I want to thank Kristof van Tomme for organizing this event and Microsoft for hosting.