Recently training was conducted for participants representing a number of NATO's Partnership for Peace (PfP) Training Centers.
Participants were led through a set of scenario driven exercises using a system based on Drupal and XMPP. The scenario encouraged participants to "meet" online (even though they were sitting across the room from each other) and coordinate events and information in "semi public and private spaces". The group also modeled and simulated how to find subject matter experts using the expertise keywords, profiles, tagging, and search.
Interesting to see how social software tools (i.e. Drupal) are used by institutions such as NATO, and glad to see that we help make the world a better place ...
A <a href="http://www.nato.int/issues/pfp/index.html">Partnership for Peace (PfP)</a> website using Drupal.
Drupal training at a <a href="http://www.nato.int/issues/pfp/index.html">Partnership for Peace (PfP) Training Centers</a>. © <a href="http://www.exposur3.com/">Chrys</a>.
Two months ago I invited Neil Drumm to become a core committer of the next Drupal version. For the duration of one release cycle, Neil will help Steven Wittens and myself to shape the face of the next Drupal version by identifying and coordinating interesting development efforts. I haven't been very verbose about my choice of Neil, but I figured it would be a pretty good hint as what I'd like to see us work on. Not unsurprisingly, this went mostly unnoticed.
I picked Neil for two reasons. First and foremost, Neil doesn't like complexity. People tend to propose incomprehensibly complex solutions, and Neil has quite a knack for detecting attempts to get cruft into Drupal. Secondly, Neil has been the co-founder and maintainer of CivicSpace, the first Drupal distribution. In his role at CivicSpace, Neil has been actively involved with the development of an install system. I hope that in his new post, Neil will help coordinate the development of a cruft-free install, upgrade and dependency system for core.
It is needed to get custom content types in core and part of the larger goal to make Drupal easier to use and develop for.
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.
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.
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.
After more than a year of development we just released Drupal 4.7.0, our most exciting release to date. More than five years, 13 major releases, 30+ servicing firms employing 100+ Drupal professionals, 300+ third party modules, and over 55,000+ Drupal powered sites later, Drupal 4.7.0 is finally here. Enjoy!