As a follow up to my previous post, I'd like to offer some reflections on what was accomplished at the Plone Strategic Planning Conference 2008 (PSPS). I feel that, prima face, it was largely successful. It's true success will be difficult to assess for probably 18 months, and some of its most important effects may be beyond our resources to directly measure.
Before I left, I wrote the following, which I never had a chance to publish: As an open source project that's driven by a community (no one company is behind Plone, even if some do contribute a ton), where the project goes depends on the will of the community. Plone is big, complicated, and powerful. For it to get better, the community needs to work together; from my vantage point, no single player has enough resources to set an agenda and then see it through alone. However, working in small groups, we have a number of competing visions for Plone (as the many insightful, "Is Plone a Framework, Platform, or Product" discussions have shown). Our priorities are different, in part because of our backgrounds. This isn't necessarily a bad thing, but it may be inefficient. With a more consistent vision, those who want a framework might be able to build parts that more effectively support those who want a product, and the platformers can push the product to more generality, and so on. The inconsistency can also make it hard to attract newcomers to the community; when someone is evaluating Plone and they hear many different visions of what it is, it can be confusing and make the critical "Is this right for my needs" question difficult to answer.
Going into the conference, it was crucially important to me that we agree on a succinct version of "What is Plone?" and answer some of those fundamental questions that come up when you're talking about the fundamental nature of Plone (which Paul Evert quite eloquently explained in his post on the subject). Interestingly, at the PSPS, we never directly tackled the Product/Platform/Framework question. Yet, I feel like we largely answered it, at the same time. Had we tried to tackle the problem directly, I think we may have ended up (1) bogged down in semantics until everyone was tired and cranky and (2) butting heads with opinion and desire until everyone was in sad factions. This would not have been productive.
Instead, the summit leaders first through the lens of marketing and then through the lens of approachability for integrators and developers (note *not* end users, which is significant and which I hope to address in another post). Looking for a coherent approach to marketing Plone is an interesting problem in and of itself, but it also forced us to focus on the essence of our project and its target audiences. We were forced to actually state, "Who is this thing for?" Then, under the guidance of an experienced marketing consultant, we had to distill our explanations of Plone into 60-second elevator pitches. I found this activity telling; it was our chance to state, firmly, what Plone is and to whom we are targeting it. Interestingly, none of the pitches I heard presented Plone purely as a framework. Plone was pretty consistently presented as a customizable product. To me, this was an elegant way to approach the problem and build consensus without giving people reason to dig in and fight for a previously entrenches position.
On the second day of the summit, we approach "approachability," or how we can make it easier for people to dive into Plone. As in the previous day we had taken a look at what kinds of industries or other groups might be interested in Plone, this time we looked at what kinds of individuals might try to approach Plone. This, again, forced us to refine our vision of what Plone is by talking about what kinds of people we want to attract to the community in the future. This work will provide us a valuable base both for improving documentation and features, but also for framing future discussions of big questions.
Finally, we took the framing we had done for the previous two days and developed it into actionable proposals to improve Plone over the next few years. Even more importantly, we volunteered (and sometimes proxy-volunteered) to be responsible to see the proposals though -- people will own these tasks and be accountable to the community for their completion. Some of the proposals are pretty specific and should have pretty quick impact (e.g, an information architecture overhaul of Plone's documentation). Others will, I hope, allow us to get closer to creating a more focused Plone in the future (e.g., the eggification of Plone, moving Repoze to a buildout, and creating special interest groups for various "editions" of Plone). These concrete actions, along with the many useful outlines we produced during the conference, will surely help spur a great deal of development in Plone, both code and community.
To me, just as important as the concrete artifacts and action items though, was getting to see one another and exchange ideas at the speed of face-to-face interaction. Each day's activities framed our problems more and more concretely, meaning our discussions with one another could become more and more valuable. It was also good to see how much everyone tends to agree; although we bloggers may take strongly opposed positions in writing, often there was a great deal of consensus among attendees about issues such as product vs framework.