White-House win blackened
"Sometimes we have to make trade-offs – we go for big sites, and make a compromise that effects the smaller sites, and when we do, we have to be careful. Right now, there's a bias towards the bigger sites because of the core development team," Buytaert said.
Security has been another source of tension. Three weeks after Druplers crowed that Whitehouse.gov gave them credibility by releasing new open modules, a potentially serious XSS hole was spotted in the Drupal Context module used by the Whitehouse.gov and 10,000 other sites.
XSS vulns are not uncommon in web software, but the discovery touched off a disagreement between the security researcher who'd documented this and other vulns, Justin Klein Keane, and Drupal's security team. Klein Keane complained that his report went unanswered for ages and that Drupal's security team didn't make it clear who researchers should contact or how such are incidents handled. Drupal's security team consists of 32 individuals, including Buytaert.
The result was that Drupal's security team announced that it could only work to fix Drupal modules considered finished and that release-candidate modules won't get fixed. The Whitehouse.gov module had been a release candidate piece of software – but the White House installed it anyway.
Klein Keane, the senior information security specialist at the University of Pennsylvania and a Drupal user, told The Reg in reaction to the White-House-inspired changes that there exists "tremendous opportunity" to improve the situation – though he was generally complimentary of the project.
"This is one of their biggest challenges to becoming a widely used piece of enterprise software," he told us.
"I'd really love to see them encourage more participation by security researchers - they have a tremendous opportunity here and they are making it difficult and painful," he said.
Buytaert said in response that in addition to clarifying what code Drupal will and won't fix, the security team's polices and workflows have been improved as a result of the White House incident. There was no word on opening the process to external security researchers.
Another hurdle to Drupal's uptake is reliable delivery. Like most open source projects, Drupal's timely completion is hostage to participation. At DrupalCon, the goal was for Drupal 7 to arrive by June. Code was frozen in September 2009, and 114 bugs still stood in the way of a shipping product. Completion has now slipped to summer/fall – possibly a year after code was finished.
Illustrating the participation problem: half of the patches in Drupal 7 by April came from just 25 contributors.
Buytaert acknowledged the painful process of completing Drupal in a recent blog here. "Seeing Drupal 7 getting steadily closer to its release, is like watching a cocoon grow into a butterfly," he wrote. "The inevitable results are going to be spectacular."
Spectacular they may be, but about those breaking changes in Drupal 7?
Users implementing the core Drupal modules will find the move to the latest version easy. But who doesn't modify? Things will be trickier if you've custom coded so it'll come down to manual coding. Sometimes, the changes will be minor, like re-naming a function or adding a new argument, Buytaert tried to reassure us. He also stressed peoples' data won't get lost.
"People will have to update their codes," Buytaert said. "That's going to piss people off, but it also makes developers really happy because it means we have no legacy and we have really clean and consistent APIs."
Does this thing go to 8?
And with Drupal 7 crawling towards completion, Buytaert's already looking towards changes with Drupal 8. To crack the enterprise, Buytaert believes configuration management and staging need more work on usability. They are not as easy in Drupal 7 as they could be. "That will require some API changes across the board," he cautioned.
Also up for discussion is whether Drupal and Drupal Gardens should include more tools out-of-the-box such as in traffic monitoring – something competitor Wordpress provides.
What ever the pain these or other changes involve, Buytaert reckons Drupal needs to become even more focused on the needs of the end user.
"I do think that one of the things that has been changing is to have a culture of user testing. We have to go back and observe what the pain points are - the existing UIs and the features that people want," he told us.
Expect more broken APIs. ®