We need to admit, these days, people are more reliant on contributed modules then Drupal core. What is in Drupal core is taken as a given and some requested new feature would ever come in a contributed module in a reasonable timeframe for a Drupal site builder. People are not waiting for Drupal 7 to get a feature, people are active in the issue queues to get things done sooner. Drupal core is supposed to lay the foundation and be stable for long, while contributed modules can experiment, change, and add new features on a much more active pace. So as a result, Drupal core can keep using the "will be released sometime" approach, and it does well with Drupal 7 allowing for more improvements by not keeping the "every 12 months" release cycle intact. With contributed modules on the other hand, much more frequent releases are anticipated with new features introduced through a shorter timeframe.

What's common in both, is that for longer lasting development, overseeing progress on major areas like the file API, the database layer and so on is important, while on shorter release cycles, knowing what is required for the release to be fixed, and whether the project is on track or not could be key to get contributors. So having (A) overviews of project progress and (B) checklists of things to be done is increasingly needed on drupal.org. There are a few things people did about these needs recently, and all have their advantages and disadvantages. There are some reasonably new approaches, so I decided to highlight the ways I see people approach project planning on drupal.org.

Drupal.org runs the infamous project* module family to help micro (and not so micro) projects run around the Drupal core. These include modules, themes and translations as well as installation profiles. Currently, drupal.org hosts more then four thousand (yes, more then 4000) projects, with support for a CVS space for hosting the code with branching and tagging, as well as a release system tied to those CVS concepts. Projects can also have an issue queue, which people can submit issues with, covering bug fix requests and suggestions as well as new feature requests. So a project's issue queue can be quite busy, but it is the only "core" way to track what needs to be done, who is assigned to these tasks, who is working on them, what is the current status and so on.

So eventually people started to experiment building new tools on top of project issues to help manage project planning, overviews and checklists. Here is a hopefully comprehensive list of what tools people built on top:

I had many requests for a case study on how we did the Drupalcon Szeged 2008 website. Granted, it was a long time ago, I just had time recently to do a writeup, sprinkle it with links to modules we used and attach some images for your viewing pleasure.

While it is waiting for consideration for a drupal.org front page promotion, since you are reading (an aggregation of) my blog, you'll get to see The tech story behind the Drupalcon Szeged conference website now. I hope it will help you get some insight into the good and bad decisions we made while we built the website, and the technology behind certain fun functions, like the registration system, the drag-and-drop scheduler, the wiki whiteboard and even the dynamic projection screen at the venue entrance. It was certainly fun to build.

Watch out, the next Drupal fest, Drupalcon Washington DC is coming up quickly in just two months!

Special thanks to Robert Douglass for proof-reading and fixing some of my non-native English writing.

On Drupal.org, user HongPong asked a valid question about our Drupal.org upgrade/redesign fundraiser:

I am curious if these codesprint efforts will be useful for other projects. I think it's fantastic so many people are organizing, but I wonder if whatever form the bulk of this takes will be released - or is it mostly a one-off effort that is too customized to be generally useful elsewhere?

I thought it would be useful to have a blog post about this instead of just sending the reply in the comments, since I think this is an important topic to talk about.

• As Niel pointed out, the modules used on Drupal.org will get attention. I've just started to use the "drupal.org upgrade" tag over the weekend to mark issues requiring an attention for the Drupal.org upgrade: http://drupal.org/project/issues-term/346 General purpose existing modules used on the site including simplenews, comment_upload, comment_alter_taxonomy, image or imagefield, and so on will be tested and fixed where required. New modules will be used on Drupal.org and will get similar attention: CCK and Views are the first obvious contenders (right, Drupal.org is not using these modules as of now).
• Drupal.org runs some custom core patches to improve performance by handling master and replicated databases. We will take a deep look on these changes and will implement a similar or better solution for the upgraded site based on Drupal 6. Our caching setup will have similar attention. Having this insight we will be able to document what best practice we found to scale drupal.org. This will join documentation on ways to make Drupal more scalable. Such efforts on Drupal.org also helped improve general performance in Drupal itself (both current stable and current development versions) in the past.
• The upgrade is planned to omit some of the current features on Drupal.org such as the current search implementation and the custom Drupal based distributed login system. OpenID and a new search implementation are about to be implemented in place instead. It will be easier to find stuff on drupal.org for your day-to-day development and you will be able to reuse your Drupal.org account on any OpenID supporting site.
• These items above all happen as products of our upgrade, even if there is no redesign. While all of the above items are great by themselves, the redesign will be the biggest hit. It will help you use a more fine grained navigation, move around the Drupal.org subsites seamlessly, find and understand modules needed for your projects, and so on. But what's even better is that it will be a site you can point possible customers to. It will help you market your services, consulting, books, courses and so on more effectively, since the Drupal site itself will do a better job to help the community and the project market itself and flourish in the times ahead of us. If you earn (part of) your living from Drupal related work, this will give you a boost. If you do not yet earn (part of) your living from Drupal, you'll be more tempted then ever to do so.

We are making exciting things happen, but your help is still vital to make this a reality. You can help by donating some money to get the expert teams together (use the ChipIn widget in this post) or by contributing to the sprints yourself either via the issues listed at http://drupal.org/project/issues-term/346 or by coming to the sprints. Thanks for being part of getting this huge improvement into production!

Drupal.org is in need of some makeup, and we know this quite well. It runs on the old and stable Drupal 5 codebase, while Drupal 6 is out for almost one year (and is just as stable but way more useful especially with all the new contributed modules). Drupal.org also sports a design which was last refreshed in 2005. So it does not really give justice to the software it helps to flourish. Therefore the Drupal Association hired Mark Boulton to help with a community based redesign of the site, and the results are outstanding. Now people from the community need to get together and actually implement it.

We are set out to make progress quickly, so Dries Buytaert decided to organize a series of developer sprints where people get together and plan and execute on the redesign. First we need to upgrade drupal.org to Drupal 6, so that we can work with up-to-date APIs to implement the new features. Then we can move on to actually implementing the redesign.

Thanks to Acquia letting me put some of my time on this job and my scheduling over the holidays and some free time put on these tasks, I've contributed work (to upgrading the existing theme, eliminate modules, help upgrade some other modules, etc) and had quite a few overviews, blog posts and call for actions. Now, these code sprints will actually get the real people together, so for example, two lead maintainers to the project module suite will be in the same room to implement, discuss and review updates to Drupal 6. We expect to make good progress this way.

However, your help is still needed! While some exceptional companies help fund and plan this sprint already, we need more funding for some of the people and also other members of the community who are willing to join and do the work. Sprints will happen in Cologne, Boston and Paris over the next few weeks (exact timing and more details in the drupal.org front page post); and we expect we will continue working on it while in Washington DC for Drupalcon and onwards. We found these places with people to help in mind, not so that we can travel around the globe (there is little overlap between the North-American and European sprints in terms of people, but some overlap is required for consistency in setting goals and planning). I've already contributed to the chipin and encourage you to do so!

If you are more into help doing the work, and you're available to attend one of these sprints, and if you have the time and dedication to work on the drupal.org redesign before, during and after the code sprints, join the redesign infrastructure team and let Dries know in the comments of the drupal.org post, and we'll figure out how and when you can best participate.

The most exciting move in Acquia for me so far just happened a few days ago. We rolled out what was called "Big tent" internally, and means much wider support for all Drupal 6 sites. As Dries points out in his blog post, we used to support our Acquia Drupal distribution via forums, tickets and phone support. However, we found that virtually all sites will use other modules, custom code and themes, tweaks to existing code.

I've immediately jumped on the new 6.5 release of the Netbeans IDE when it was released with much fanfare about its PHP support. Netbeans is a free to use IDE sponsored by Sun. I've used it years ago to edit XML documents, but did not look back on it ever since. Now it does indeed have nice PHP syntax highlighting, context sensitive code suggestions and debugger support as you'd expect from a PHP IDE.

One of my first new year's readings was Dries' reflection post on 2008 which includes predictions for 2009. One of the predictions is that he sees Drupal 7 to be released in the last quarter of 2009. He predicts pain but a strong outcome.

I predict that Drupal 7 will be released in the fourth quarter of 2009. The two most exciting features in Drupal 7 core will be custom content types and radical improvements in usability. To reduce the risk of important modules falling behind in support or update path, a significant portion of the Content Construction Kit (CCK) related modules will move to core and we'll pave the way for the Views modules. The same holds true for other important contributed modules, including token module, path auto module, and image handling functionality. In 2009, core becomes bigger, not smaller. The Drupal 7 code freeze will be longer than expected regardless our new continuous test framework, and the upgrade path to Drupal 7 will be more painful than hoped for. But like always, we'll come out stronger than before...

Two key takeaways to spread from my mind are that:

• You should seriously move to Drupal 6 instead of staying on older versions, in anticipation of a new major Drupal release around the corner. The key modules are already out, and they are amazingly more useful then their Drupal 5 or earlier counterparts. The action happens in the contributed modules area!
• The doors for your work on Drupal 7 are wide open! You should not hold back big ideas on the grounds of a shortly coming Drupal 7 release. We still have time to design and discuss bigger changes. No wonder the fields in core effort needs time to stabilize and achieve "CCK in core" on higher levels that we anticipated before.

Happy upgrading Drupal 5 sites, working on Drupal 6 modules and contributing to Drupal 7 core in 2009!

I've helped recently to unfork the Bluebeach theme (the theme used on Drupal.org and subsites) which was used with different code on drupal.org and groups.drupal.org. So now both sites can use the same source code for their theming. I've also ported the changes to the Drupal 6 port of the theme which was done by Earl Miles earlier, based on the Drupal 5 version. These were all in anticipation of doing upgrades of drupal.org and subsites with the existing theme before going to the next step with Mark Boulton's redesign.

Dries Buytaert recently posted his Fields in core code sprint debrief, in which he mentions toying with the idea of organizing a Drupal.org upgrade sprint at Acquia. This is what Dries has to say:

All things considered, this [Fields in core] sprint was a big success, and I'm now toying with organizing a "drupal.org upgrade" sprint at Acquia during the last week of January. The goal would be to upgrade drupal.org from Drupal 5 to Drupal 6, and make progress on the drupal.org redesign work. Is anyone interested in participating in or helping fund this sprint? If so, more soon.

From my previous involvement and blog posts, it is probably not big news that I am very interested in helping out with that. Are you?

Just over a week ago, I've been in New Orleans to talk about multilingual Drupal website building at the Do It With Drupal event organized by Lullabot. I've been happy to join fellow Acquians for a short time at the office and then at the Do It With Drupal seminar to represent the company. It was a fun experience to hook up with so many other people looking into using Drupal for the first time or even selling Drupal services already. It was a good mix, and was a very different target audience compared to Drupalcons. This event was more focused on the path seekers and the beginners with high detail and cross-discipline talks over four days. I've enjoyed several sessions, including Robert's session on Solr.

Unfortunately (for my enjoyment of the conference), my session was at one of the last slots, but it had a good turnout nonetheless. I've been prepared well in advance with a completely rethought line of thought (compared to previous, more developer focused events), and a slideshow done from the ground up. So despite talking about this topic before elsewhere, I needed to have a totally fresh look at the topic and present all the latest developments to date.

Since I do not have the permissions to upload my session to the website of the event, and the slides I sent in by email were not uploaded yet, I figured I'd better share them here with those eager to look into them soon. Happy holiday's reading if you are about to take time to learn more about multilingual Drupal solutions!