You are here
Drupal continues to rack up successes among large developer communities, with x.commerce joining Twitter, which made the move last month. X.commerce is a new division of PayPal that serves as an open, central meeting place for over 700,000 developers for eBay, PayPal, Magento, and other eBay properties.
These communities join those of Brightcove, Symantec, DivX -- and, of course, Drupal. All told, that's millions of developers relying on Drupal-run sites for coding tips, product info, and idea exchange.
x.commerce's communities were formerly run on Jive, a proprietary package. Through Acquia, eBay engaged VML to create the site, with additional consulting by Cyrve (now part of Acquia) to migrate data. Acquia provided a Technical Account Manager (TAM), who helped coordinate resources to put the site into production and will be on call as it grows.
Like many developer sites, x.commerce centers around its documentation and its communities. The latter are a model of social networking at its best, in the service of a question-and-answer format. Developers help each other by responding directly to questions, either publicly or through private email; vote on questions (and answers) to highlight those of importance; promote conversations through other social sites such as Facebook; and bookmark discussions to form personal collections. The results are evident in the enormous level of activity within the forums (which, by the way, are built on Organic Groups).
This project is an excellent example of how open-source software drives innovation. Under Jive, eBay wasn't able to develop features that it needed. If eBay needed to do something that wasn't in Jive's roadmap, that was just too bad. Drupal, of course, allows them to create whatever they need, or developers outside the company to do it. That jibes well with x.commerce's ethos of open development, as is demonstrated by the extensive APIs it provides for eBay and PayPal, and the freedom the company allows its developers. I believe that their openness is a key factor to their success -- there are over 4,500 apps on Magento alone -- and that their move to Drupal will allow them to grow at the speed of their community.
As you know, I'm no stranger to travel — I flew over 100,000 km in 2010 and over 300,000 km in 2011. But India is one place I haven't visited yet, even though I feel that Drupal's success there is crucial to its worldwide adoption.
Besides having a strong Drupal community, India is one of the world's fastest-growing economies, with great promise to continue its rise for several years. Where a country's economy grows, so grows its need for online solutions. So the opportunities for Drupal there are obvious.
So I'm excited to be visiting this coming month. My schedule is:
- 7-8 November in Delhi
- 9-10 November in Mumbai
- 11 November in Hyderabad
My time will be split between events with the Drupal community, press meetings and private meetings with Acquia partners and customers. I'm grateful for volunteers who have been making plans in the Drupal India group. If you're local and would like to meet, be sure to check in there. Even if we can't meet, I'd especially appreciate Indians' comments of what you hope I know about Drupal in India when my trip is done.
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?