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.
There is also no actual code forking involved in breaking into two Framework teams. All Plone 3.x development ultimately goes into the trunk of the code repository, from which both 3.x and 4.0 builds branch off.
A New Sponsorship Program
Another big happening that has broad future implications is the recent relaunch of Plone.net -- known as the Plone Network -- which is part of the launch of the Plone Foundation's new sponsorship program.
While the Plone Foundation of course accepts contributions from individuals at any level, the sponsorship program is specifically aimed at Plone consultants and companies providing Plone-related services.
Two Tiers of Sponsorship
There are two tiers of sponsorship, and how much you pay to become a sponsor depends on whether you are a solo consultant, or part of a larger consulting firm. Fees for firms depend on a firm's size (size is determined by billable hours doing Plone-related work, not by actual number of people).
Whether you choose a Standard or Premium level of sponsorship, one of the benefits is a listing on Plone.net, which can now act as a source of referrals for systems integrators, hosting companies and other consultants working with the Plone CMS (see the providers and hosting providers sections of the website).
Sponsorship Funds Growing the Plone Foundation
According to McMahon, this combination of site and sponsorship program is "dramatically improving the income flow for the Plone Foundation."
Before you imagine gold-plated faucets, the money is going to more marketing, perhaps some Plone Foundation-subsidized development events, legal work to secure Plone's intellectual property, registration of the Plone trademark worldwide and paying the Plone release manager a stipend per major and minor release.
The foundation's fund raising goal for 2009 is between US$ 40,000 and 75,000.
A Strong Development Culture
Communication, Respect and Ownership
Plone's development culture has managed to achieve a high level of communication. For an example, they offered a three-day "Strategic Planning Summit" held on the Google campus in February 2008. A team of eighty core developers, trainers, integrators and marketing people were physically in the same room with their laptops banned and facilitators keeping things moving.
During the gathering, they generated around fifty tickets for platform and documentation process improvements. Each one was assigned a well-respected champion who would make sure that nothing would slip under the radar. As of March 2009, nearly every one of these items is either successfully closed, or part of the work being done for Plone 4.
Putting Best Practices to Work
In general, the Plone developer community has managed to take best practices like test-driven development, security consciousness and component architecture and collectively absorb them.
McMahon hopes that they can now bring that same culture to the Plone documentation and integration communities. Current initiatives to collect ideas on how to accomplish this goal include regular IRC meetups for documentation editors and for integrators.
Keeping Face Time High
Schlichting feels that part of what keeps the communication level high is the focus on many face-to-face interactions, and that the choice of technical frameworks -- namely, writing Plone in Python and basing it on Zope -- naturally restricts Plone to a narrower group of users and contributors.
Maintaining a Nice, Practical Ethic
So far, he says that they have large backing among Non-Government Organizations (NGOs), scientific and educational communities worldwide.
"There's still somewhere the idea of being 'good' as a value in this community," he points out. "We seem to be able to maintain this value, while neither drifting into abstract idealism nor mindless capitalism."
License Policy Changes
A number of things are coming down the Plone CMS pike. For one, while Plone itself is GPL -- and that is not changing -- there is discussion about making some allowances for framework components that don't have any dependencies within Plone itself.
These allowances would mean letting such packages' creators assign a LGPL or perhaps modified-BSD license to their work -- which license this will be is still under discussion.
The problem driving this discussion is that the Plone project, according to McMahon, "wants to be a better citizen in the wider Python and Zope community by giving back modules (with less limiting licensing) that are highly reusable and not part of the Plone application itself."
However, Zope uses the ZPL, a modified version of the BSD license.
The ZPL and GPL are not compatible. [Correction: The ZPL and GPL are compatible, see here.] As one might expect, the dividing line is between those who prefer the GPL (who are happiest with the idea of using the LGPL) and those who prefer the closest compatibility with Zope (who prefer the BSD license).
[Editor's Note: For an in-depth discussion on the GPL, see Open Source: The GPL, Your CMS Project and You.]
There is some precedence for this move. According to McMahon, everything owned by the Plone Foundation is GPL, but there are packages not in their repository or in the core product that have GPL-compatible licenses such as BSD, LGPL and MIT.
The discussion is far along enough for there to be a draft document: Plone Framework Components Relicensing Policy. This document lays out what types of packages are eligible for the relicensing, and how a package author goes about requesting permission to do so.
To weigh in on the matter or just see what people are saying, check out the Plone Foundation Membership email discussion list.
Continuing to Grow
Strengthen Integrator Relations
Of course, the Plone community still has room to mature and grow. One thing McMahon would like to see is better coordination between the developers and integrators. He'd like to minimize issues where spectacular new features greatly increase the complexity of integrating Plone into other systems.
Toward this end, one event on the horizon is a in-person meeting between the Plone 4 Framework Team and key integrators, trainers and documentation editors. The purpose is to gather early feedback on how to ease the path for Plone 4 acceptance.
Improve Project Marketing
Jens W. Klein, a Plone core developer, would like to see an improvement in Plone's marketing. Klein points out that what hasn't changed in the Plone community is that, "Its still the wide open friendly community it was years ago with a great product and worst marketing for it."
More Interconnectivity, Collaboration
One thing the Plone project is striving to do better on is to stop being so self-centric in their solutions. Schlichting says they are reaching out to other communities, particularly those in the Python web world, in order to resolve this issue.
There are already grass-roots movements of people in the Django, Pylon, TurboGear, Silva, Zope and Plone communities wanting to talk and share knowledge between one another. Sprints at this year's Python Conference in Chicago had members of many Python groups together in the same room.
As Helge Tesdal, member of the Plone Foundation, points out, "If we start by sharing code and components, there will be more communication, people will be more likely to be part of several communities, and the flow of ideas will increase. I don't have any examples of what we should learn, but I believe there will be plenty, as there is always someone brighter than you out there."
The Plone project member have impressed us as a thoughtful and practical bunch. No one project does everything perfectly, but the Plone team have set some good examples, especially in how they have chosen to maintain the code base and provide solid support over the release lifecycle.
Stay tuned here as we continue to cover the Plone Web CMS and what's happening in the world of open source content management.