State of the Project Report: Plone Web CMS

By Dee-Ann LeBlanc (@deele) May 6, 2009 Comments

1 comment

Some might say that over the ten years since the Plone (news, site) project was founded, the Plone community has developed an organizational fetish. However, that fetish has served them well — leading to 2 Packt Open Source CMS Awards, participation in events like the Google Summer of Code and a worldwide Python-powered following. Here's a look at where the Plone project is today.

Divide and Conquer

The Plone project has reached new levels of maturity. For example, they have enough skilled and interested developers that they've been able to split their Framework Team into two, yet have both fully staffed.

A new Framework Team is chosen for every Plone release, though generally the idea is to retain some of the previous team for the sake of continuity. These teams help developers to propose new features through the PLone Improvement Proposal (PLIP) process, guiding them through, helping them package their code, and ultimately voting on which new features to recommend that the Release Manager add to that release.

So while the Framework Team doesn't code the release, they do in a way drive and support the vision of where it's going — according to the roadmaps and strategy decided on through mailing lists, sprints, conferences and strategic planning summits.

Two Teams are Better than One

To understand the value of having simultaneous Framework Teams for both 3.x and 4.0 development, consider what happens with many projects. The teams focus all of their energies on a release. In this case, Plone 3.x. Then, they begin ramping up to work on the next one, which here would be Plone 4.0.

With a single team handling everything, it's a common and very human problem that the further one gets into the new version and its lifecycle, the harder it is to muster the energy and focus to properly tend to the previous version.

Meanwhile, you still officially support the previous version, and there's always bug and security fixes that need to be done, not to mention refinements that really don't need to wait until the new version.

The Plone 3 Team Mandate

The Plone 3 team's mandate is to pursue improvement of Plone 3.x while, according to Steve McMahon, Secretary of the Board of Directors of the Plone Foundation, "maintaining the validity of Plone 3 documentation, continuity in the visual interface and as close as possible to 100% compatibility of add-on products for the Plone 3 series."

Even when Plone 4 is out in the wild, the Plone 3.x Framework Team will continue their work until it's time to lay Plone 3.x to rest.

Knowing this is the case, integrators and organizations who run on Plone can relax a bit, rather than feeling the surge of panic they felt during the large jump from Plone 2.5 to 3.0. They'll know that investing their efforts into a version of Plone now has a long payoff, while Plone 3.x remains a stable, developing platform. Yet, they'll also know that Plone is still a fast-moving project with new innovations just over the horizon. It's a nice balance they've struck here.

The Plone 4 Team Mandate

In the meantime, the Plone 4 Framework Team's mandate is quite different. McMahon says it's to "push the boundaries of what a content-management system can do (while keeping the focus on being a CMS and not trying to do everything)."

This team can focus on innovation without worrying about causing mild bits of panic among integrators and others who before have been a bit overwhelmed by the leaps made between releases.

Both teams communicate using the same IRC channel and mailing list, and community members can join in or just listen as well. Hanno Schlichting, Plone 4 Release Manager, says that these open, transparent discussions have so far prevented the forming of two separate camps among developers or elsewhere.