You are here
I'm pleased to share that Nat "catch" Catchpole has accepted my invitation to become my Drupal 8 co-maintainer. For the duration of one release cycle, he will help me co-ordinate Drupal 8 development.
Nat has been working with Drupal for almost 6 years and is one of the top two contributors to Drupal 7 core. In addition to being is known in the community as an incredibly talented engineer with a passion for software design, Nat is also a driving force on performance and scalability efforts. Additionally, he pays careful attention to core development processes and how they can be improved. I firmly believe he is what Drupal core development needs right now.
One of the things that I like best about Nat, is that he doesn't like unnecessary complexity. I believe he will be a great help in driving architectural decisions, helping to improve the framework aspects of Drupal core, and saying no to cruft.
Nat is working out of Japan for Tag1 Consulting. Note that Nat will be traveling between 4th-22nd October, but will get set up as co-maintainer this week.
I'm extremely excited to work alongside Nat to set the direction for the next version of Drupal! Please make him feel welcome.
While we made Drupal 7 easier to use and more feature-rich for site builders, we also added complexity for the core developers. We shouldn't be surprised though. As a software application evolves, its complexity increases unless work is done to maintain or reduce it.
When that happens, it is can be frustrating as software complexity is an obstacle to introducing change, can be a source of bugs and makes it harder for new contributors to get involved. The general sentiment among the core developers is that steps must be taken to reduce Drupal's complexity. I wholeheartedly agree.
Many people in the community put forward a lot of good suggestions to reduce the complexity of Drupal core; from removing unnecessary functionality, to decoupling systems, to improving our APIs and abstractions. All things we should consider doing. In fact, we have already removed some unnecessary modules and features from the Drupal 8 development branch. Last but not least, I'm looking to appoint a Drupal 8 co-maintainer that has the technical skillset to help manage Drupal core's complexity.
I also had a thought I wanted to run by you. It would be good if we could measure the evolution of Drupal's complexity over time. That would allow us to say things like: "Drupal 7 is 30% more complex compared to Drupal 6", "This Drupal site build has a complexity score of 420", or "This patch reduces the complexity by 12 points".
I'd like to see if we can come up with a "Drupal complexity score". It would obviously be important to combine different metrics such as (1) number of calls per function, (2) number of inter-module calls per function, (3) mean function size, (4) number of input arguments for API functions, (5) number of comments per function, (6) number of references to global variables, (7) number of different code paths, etc.
A "Drupal complexity score" is not the panacea, and neither will we ever have a perfect scoring system. However, I still believe that even a basic "Drupal complexity score" integrated in the patch review workflow (including our testbots and DrEditor) would be a big win. It is hard to manage what you can't measure. At a minimum, it would put reducing complexity at the front and center of every reviewer and maintainer.
If you watch the stream of new modules going through drupal.org, it's easy to miss those with special meaning. So you might not have noticed the appearance of Content API, an add-on to the Services module. The module was born of efforts by the U.S. Federal Communications Commission (FCC) to make 350,000 of its documents more available to the public, as part of a site that will enter public beta in a few weeks, My.FCC.gov. Like many government agencies, the FCC has been enthusiastic about Drupal lately, attracting a detailed write-up about its "reboot as an open government platform" on O'Reilly Radar last April. (FCC.gov also uses web services extensively, although without benefit of the Content API module.)
Seabourne Consulting in Washington, DC led the development, publishing a preview video of My.FCC.gov's prototype last May. Seabourne's Mike Reich told me that Drupal let them go from concept to working prototype in three weeks because they could leverage its existing features and add-ons, such as the Services module.
I consider web services to be a crucial area for improvement in Drupal 8. In fact, I made it the second Drupal 8 initiative back in April, and am very happy that Larry Garfield (aka Crell) has agreed to take on the challenge. In the meantime, the Content API module will give organizations like the FCC easier access to the power of web services right now, and its development could help guide efforts toward putting such tools in Drupal 8's core.
Three weeks ago, at DrupalCon London, I gave my traditional State of Drupal presentation. In good tradition, you can download a copy of my slides (PDF, 37 MB) or you can watch a video recording of my keynote.
My presentation was based on the results of the State of Drupal survey, which got over 3,000 responses from people all over the world. Because I didn't have time to talk about all the survey questions in my keynote, I've decided to make a summary of all the survey results (PDF, 160 KB) available as well. It gives a more complete view on the survey results.
However, there is much more data hidden in the raw survey results, so if you'd like to do your own analysis, you can download a copy of the raw survey results (CSV format or XLS format) and look at the raw data yourself. I anonymized the data by removing the name and company information. If you decide to analyze the raw data, consider sharing your findings with all of us.
DrupalCon London was a blast and I would like to thank everyone for making it such a great event.
A number of concerns have been voiced from the community about the substantial growth Acquia has achieved since its inception, the number of key contributors who are now employed by Acquia, and the subsequent influence that this allows Acquia to have on the project.
While some of these concerns have validity, I also think there is also a fair share of FUD (fear, uncertainty and doubt) being spread. So, let's clear up a few points.
In terms of growth, Acquia currently employs about 150 people. However, fewer than half of Acquia's employees work directly with Drupal; the majority of Acquians work in sales, marketing, hosting operations, finance, HR, etc. In a way, this makes us smaller than Phase2, Node One, Forum One, Propeople, Capgemini, and dozens of other shops in terms of Drupal staff. We have a different mix than most other Drupal shops.
In terms of influence, Acquia employs fewer than 10% of the contributors to Drupal core. Admittedly, on a "per Drupalist" basis, Acquia probably contributes significantly more code and magnitudes more dollars to the Drupal community than any other organization. We are investing in expanding the Drupal community through major learning initiatives. We sponsor more DrupalCamps, where new people are introduced to Drupal, than anyone. We sponsor more interns than perhaps the rest of the community combined, where high school and university students learn how to build a career in Drupal. Not to mention we contribute a lot of code.
I like to believe that is a great thing for Drupal and that not doing so would be a big loss for all of us.
It certainly helps to have venture capital money when making investments in the community, but it is not a magic bullet either. It is not free money. I've explicitly chosen to give up part of my equity in Acquia in exchange for money so that I can invest it back into the Drupal community to help Drupal advance.
I understand that my involvement with Acquia is tricky because its well-being is intertwined with Drupal's. But I help drive the decision-making process at Acquia, and I set those directions with the best interests of Drupal in mind at all times. Making Drupal successful and Drupal's well-being is my primary concern, regardless of the "hat" that I wear. We want Drupal to power as many sites as possible, both small and large. We want lots of Drupal entrepreneurs to thrive in a growing ecosystem. If you look at Acquia's actions, you'll see tons of contributions here. We sponsor DrupalCamps and DrupalCons, and pay employees to improve Drupal modules and themes.
Recently, our acquisitions of Cyrve and GVS have been a topic of debate. I'd like to point out that acquisitions are a two-way street: they don't happen unless both parties are really excited about it. Contributors come to Acquia for different reasons. Sometimes they would rather hand things like business development, sales, and support off to someone more set up for that, so they can stay focused on doing things they really enjoy. Others thrive more in a larger team of smart people working on interesting things, rather than toiling away on their own. Still others have put in huge amounts of their own personal time over a sustained period to help improve Drupal, often at great personal sacrifice, and are looking for an arrangement that makes this commitment to the project more sustainable. Painting these contributors as "bad guys", or the company who allows them to pursue a career that they love as "bad guys", is not healthy for our community, or the individuals involved.
The clear solution to the influence concern is to grow our community, particularly our contributor community. If more individuals and Drupal shops are contributing in a bigger way, this mitigates the risks of any organization, Acquia or otherwise, from exerting too much influence on the overall project.
So as a community, we need to re-frame this question. We need to be asking ourselves: (1) What can we do to grow the community? (2) Why aren't more people who depend on Drupal contributing to it? and (3) How can we encourage Drupal shops to contribute back?
As followers of this blog, you might have read that Acquia acquired two Drupal companies; security specialist Growing Venture Solutions and migration expert Cyrve. We wanted to do these acquisitions because they create a win-win-win situation; it is beneficial for the Drupal community, our partners and our customers. I personally championed and led those acquisitions so I want to take a moment to explain why.
How do these acquisitions affect Drupal?
I believe these acquisitions benefit Drupal by expanding its reach. Migration from legacy systems (like Vignette, RedDot and Interwoven) and from expensive enterprise solutions (like Jive Software, Adobe CQ5 and Sitecore) represents some of Drupal's biggest opportunities -- if not the biggest. My hope is that by acquiring and expanding Cyrve, we'll be able to bring more projects into Drupal. That leads to more site building work, more contributed module patches, and more people talking about their Drupal successes.
Similarly, Acquia's involvement in GVS gives it the resources it needs to pursue new security initiatives that will make Drupal more attractive to everybody. As always, we'll continue to return many developments to the community.
How do these acquisitions affect Acquia's customers?
Acquia's customer base has been growing rapidly, both in number and size. We plan to use these acquisitions to provide our customers with more product options and more experts. We will:
- Offer automated, self-service security tools as part of the Acquia Network.
- Integrate the services of both companies into our Professional Services group. We'll be expanding our security and migration teams, both by training existing consultants and by bringing new employees into the fold.
- Incorporate their curricula into our existing materials so we can help train many more experts on Drupal security and Drupal migrations.
All of these are good for Acquia's customers. But they're also good for the Drupal community at large: we need more migrations and security experts in the community.
How do these acquisitions affect Acquia's partners?
Many of our partners build Drupal websites, but few have in-house security or migration expertise. With Cyrve and GVS, we can all approach joint customers with more-complete offerings. This enables our partners to go after bigger projects.
In short, I believe these acquisitions are beneficial for Drupal, our partners and our customers. However, some people have expressed concerns that, with these acquisitions, Acquia is sucking up a lot of the Drupal talent. Because that concern is not limited to these acquisitions, I've decided to address that in a separate blog post: Does Acquia suck up all the Drupal talent?.
We've just reached another huge milestones at Mollom: we blocked our 500,000,000th spam message!
Furthermore, Mollom is currently protecting close to 50,000 active websites, that is a 75% increase since the beginning of the year 8 months ago.
It's sad that our websites get bombarded by idiots. But the fact that Mollom blocked half a billion of their attempts, actually makes me feel a lot better!
Screenshot of the scorecard section on Molom.com.