Custom content types

Right now, creating a new content type in Drupal typically involves developing a new module, or extending an existing Drupal module to your needs. One of our long-term goals is to make it possible to create custom content types without having to write any code at all. We want users, not developers, to be able to create custom content types from within Drupal's administration interface. The need for this has been emerging gradually, and will become increasingly important for the success of Drupal, and content management systems in general. Eliminating developer intervention is a good example of how we can make Drupal more accessible to people that want to build websites.

The current code name for this project is the "content construction kit" (CCK). The project's goal is to allow users to create custom content types in Drupal through the web. The project is headed by John VanDyk and Johnatan Chaffer, who started working on the CCK almost two years ago. From day one, I've been keeping an eye on their work, hoping we can integrate it into Drupal core at some point. To understand the impact of such move, you can best think of it of as a heart transplantation. Much like open heart surgery, it needs careful planning and preparation.

It is part of the larger goal to make Drupal easier to use and develop for.

Complexity is a disease

The Ockham's Razor Principle of Content Management Systems says that given two functionally equivalent content management systems, the simplest one will be chosen. It asserts that simplicity is preferred to complexity. As content management systems become more alike in terms of critical functionality, ease of use will become a key differentiator (rather then functionality).

In addition, web application frameworks like Ruby on Rails, whose goal is to develop applications with as little code as possible, are redefining the rules of how websites are built. For web application developers, ease of development will become a key differentiator.

Hackability is key.

Complexity is a disease.

Making Drupal (i) easier to use, (ii) easier to develop for, and (iii) easier to theme -- while maintaining its functionality and flexibility -- is what I'll be working on.

Roadmaps

Now Drupal 4.7.0 is released, people start clamoring for some kind of roadmap. Drupal never had an official roadmap, and will never have one. People perceive a roadmap as a list of formal deliverables; they feel stranded when the roadmap is changed, and get upset when functionality is not completed in time. Volunteer-driven projects like Drupal can't make any guarantees. Things happen, or not. Code is ready, when it's ready. Volunteer-driven projects don't mix well with official roadmaps.

As the Drupal community grows, those who disagree with not having an official roadmap have become increasingly articulate.

Of course, I recognize that it is necessary for people to have some idea of where Drupal is heading. It enhances good communication and creates synergy between developers. Hoping that some people will engage in the opportunities, and that we can collaborate effectively, I'll start talking more about the directions Drupal is heading in, some of the decisions that are made, and the functionality I'd like to see integrated into Drupal core.

At the end of the day, it's all about better communication.