Yesterday the second core development summit for Drupal took place in Copengaden. This is the gathering of people both actively involved or generally interested in core Drupal work. As was appropriate (and some would say indispensable) after an initial set of presentations the focus was squarely placed on work on Drupal 7 and great progress was made.
Angie of Lullabot has a great writeup about the details of what was presented, discussed and some of the outcomes. I want to try to draw some conclusions about where Drupal is heading based on the sum of what was said.
Four issues were touched on:
- Angie Byron talked about the committer application process and how it can be improved and made more user-friendly.
- Larry Garfield described his vision of how to change the page layout/creation mechanisms in Drupal 8 (also known as the Butler project.
- Jen Simmons explained the opportunities afforded by HTML 5 and the need to have Drupal support it easily so that professional web designers can take advantage of it
- David Strauss talked about what needs to happen to allow Drupal to take use some impressive performance improvement techniques using tools such as Kargo Event
The first issue is concerned with streamlining community processes and dealing with the growth pains of Drupal. With the growth that Drupal is experiencing the same methods simply can't cope. The good news are that there are some really great people worrying about this stuff in the Drupal community with the drive and enthusiasm to both bring up the problems and work towards solutions.
The other more technical issues I thought were interesting because they all came up against the same problem: "I would like Drupal to do X but unfortunately assumptions are made that don't allow me to do that".
In Larry's case it is about Drupal assuming that it will return standard HTML pages in more or less the same layout and that context is interwoven and spread across the place, in Jen's case it is Drupal assuming that it should only ever return (X)HTML 4 while she would like to be able to easily generate HTML 5, and in David's case it is Drupal assuming that it will only ever live in a standard LAMP-type environment while he wants to place Drupal in an interesting evented environment so as not to require a full bootstrap on every page load.
In order to address all three challenges a more modular and more easily re-configurable Drupal is required. While some solutions (hacks) can be introduced in Drupal 6 and 7 to get these things to work really the onus is on a Drupal 8 that will allow requirements such as the ones above to be easily met. The Butler effort is, I believe, key in this as it goes to the core of the issue (no pun intended). We need to decouple the process so the "what" will be represented is completely separated from the "how" and the "where".
Now, the challenge is to bring about this change in a reasonable time frame, without completely breaking existing modules, and in a manner that can be easily understood and taken advantage of. I think this means that some compromises will need to be made and that the full vision several people now have of what Drupal can be can't happen in one iteration but will need at least two (i.e. it will take a Drupal 8 and a Drupal 9).
The future is promising because there is vision and a will to make that vision reality. More importantly that vision is driven out of real practical needs (HTML 5, performance improvements). However, it will take a sustained effort and decisions that are willing to break stuff but not stretch the system and the community to such a point so as to reject the changes.
Good - now let's get back to finishing Drupal 7 :-)

Comments
As a matter of fact,
As a matter of fact, generalists have to trust specialists for API changes that touch the innards of a sub-system, because such changes are beyond their horizon (otherwise, they'd belong to the group of sub-system specialists).
Niche Finder
Add new comment