As mentioned in the last blog post, next weekend 50 people from all over the Plone community will meet at the Googleplex in Mountain View to discuss the future of Plone. The idea is to bring people together who know what’s going on in the CMS scene, have knowledge about competitors, know how people approach Plone and which problems they have and of course have some influence in the Plone community to make changes happen.
The goal is to make strategic decision or at least suggestions where to move with Plone. Therefor even more than US$10,000 were donated by individuals, companies and the Plone Foundation to cover travelling costs for those coming.
It’s an experiment which to my knowledge has never been tried before with any other Open Source CMS and it will be interesting to see how well it works. There are some potential problems of course:
- Can 50 people reach a consensus or some direction?
- Will the broader community follow? Decisions on such meetings will always be done by creating compromises. People not being there have not been part of building this compromise and might complain because of some (in their eyes) wrong decisions.
- Will these decisions really be implemented? After all Plone is not a company but an Open Source project it might be a challenge. Usually people fix or extend things they personally need and not what global strategy is. It very much depends here on good motivators.
- Can the summit speak for the whole community?
Of course the summit cannot really come up with a binding strategy everybody has to follow but it should at least give hints and perception of where people think the future direction is. It will at least be good to collect all these ideas. Some collection already has happened, as several people have written about their ideas:
- „18 Things I Wish Were True About Plone“ by Alexander Limi
- „Pete and Andy try Plone“ by Martin Aspeli
- „Is Plone too hard?“ by Martin Aspeli
- „Plone-the-product vs. Plone-the-platform, Joel-on-software edition“ by Paul Everitt
- „Plone in the New Marketing and Data Portability Era“ by myself
- „Some more ideas to consider“ by Hanno Schlichting
- „Short Plone Wishlist“ by Chris McDonough
- „If I had a single item in my wishlist for Plone 4…„ by Kamon Ayeva
- „What is Plone“ by Martin Aspeli
- „What Plone means to me (and my clients)“ by Donna Snow
- „Is Plone a CMS“ by Chris McDonough
- „Yet another pre-summit blog entry“ by Lennart Regebro
- „Platform, Framework, Product“ by Reinout van Rees
plus long discussions on the mailing list about these topics.
Jon Stahl also conducted a survey in which over 140 people took part, more will probably follow. You can find the summarized results here.
So I think measures were taken to get the voice of those who cannot attend personally and thus the broader community (although it’s of course bigger than 140 people but maybe next time it needs more time and more advertising for a survey). And even just having these discussions is probably worth it because a lot of great stuff was mentioned.
So here are my 10 potential topics/wishes for the summit:
1. Make sure we have a defined release frequency?
The actual question is if we want time-based releases but I guess we want. It makes more sense to have a more limited scope to cover in each release and make sure that people know deadlines. Even if a deadline is missed people can be assured that the next one is coming up in a defined timeframe.
Of course handling deadlines is difficult as everybody is busy so there might be some delays but maybe it’s an idea to add more buffer time inbetween.
Good would also be a calendar which reminds you of upcoming deadlines. I created one a few weeks back so maybe something like this can be used (and I am experimenting with Yahoo Pipes to make it more useful right now).
2. Define the development process more precisely
I think here are basically two fields to address: a properly defined process and better documentation. To me it wasn’t clear how the process these days actually is, what the job of the framework team and the release manager is and how these are defined. I hope some light can be shed on this.
3. Decide whether Plone is a Product or Framework
This seems esp. a topic of Paul Everitt and we had some discussion about this on the plone-dev list. To me I think both aspects are important but it’s important not to confuse people. Thus maybe a rebranding/renaming of the framework might help here. I also would like to be able to market Plone to developers and for them the framework aspect is definitely of more use.
4. Decide upon the scope of Plone
This topic is related to the whole Product vs. Framework discussion as there should be a decision of what belongs in the Plone core (means ships with it) and what doesn’t. It is naturally that projects start more organic and lots of stuff gets added which you later might regret. But we already have a well working process which maybe can still be improved of course. So not only quality should maybe count here but it should also depend on the general strategy.
This might be a sensible topic regarding framework features because IMHO it should be made sure that we don’t lose the flexibility we have now.
5. Decide upon the future roadmap of Plone
This again is related to the previous point. The longer time roadmap defines what goes in and what does not. It also defines how development in the future might take place. If it’s still Archetypes based or going in another direction and so on.
IMHO it is also important to document these things properly. When Plone changed from 2.1 to 3.0 via 2.5 quite a lot has changed and maybe it was not only me who was lost in all the restructuring and embracing new concepts. I think in such cases there should be a central place where these things are written down or linked.
The roadmap will then also help in deciding which PLIPs to accept and which not to.
6. Provide a better story for components outside the core
Now if people can not easily get their code into the core they might be disappointed because one factor for doing Open Source is of course getting attention. At the Snow Sprint we briefly discussed the importance of that and how people want to be part of the core thing.
So maybe we also need to think about ways to get people recognized who don’t end up in the core. They still might do great stuff but it might not fit the actual roadmap of Plone. That being said Plone should of course always be that flexible to allow such external addons.
Ideas for recognizing them more is maybe a section of recommended products or similar things. Of course such sections have their issues and other ideas fleshed out on the mailing list and the above mentioned posts were ratings, automatic sending of installed products from deployments to plone.org or the possibility for plone.org users to just list their favourite products.
7. Decide on how Plone is marketed
This is very much related to the product/framework and roadmap question. It would be good to have material and guidelines for everybody who wants to market Plone.
I also hope that people don’t forget about New Marketing because I think it can be very powerful and might reach people you won’t reach traditionally (maybe more the framework fans but having new developers on board is IMHO not a bad thing).
8. Decide on follow-up actions
Of course the summit will be far too short in the end. So more events of this sort will probably happen. And there is also a lot of work to be done afterwards. This means that there should be some lists of what people can do and what other event organizers might do.
It might also be important to define a structure on how such events are documented and organized.
9. Document exactly what was working and what wasn’t working so much
Related to 8. and I am quite sure this will be done by Jon Stahl et al.
10. Document all and everything which was said, discussed
This is maybe the most important one. As said 50 people are not the whole community and some people might actually feel left out esp. if there will be decision they don’t like. They might have the feeling that they could have changed this if they just would have been there.
Helping here might be a lot of coverage from this event to be able to see how compromises and decisions are created. It is also important to keep the community in the loop.
Jon already said that he wants to scribble down all the notes he takes but of course Jon cannot be in every meeting.
So it’s up to all the participants and IMHO it would really be great if some special timeslot is defined for writing things down and posting it. If people don’t want to write they can do podcasts or video blogs. It’s really quite easy and people who can help with that are on location.
It comes down to the fact that when you want to decide for the community and want as much people as possible to follow you, you need to be a good communicator.
Technical things
So these points have mostly been organizatorial and maybe that’s even sufficient for some first meeting. Some technical things should probably addresses nevertheless.
For me personally important would be:
- addressing the performance issues (but I think this is an accepted problem by now in the Plone community so it’s quite sure that work on this is being done)
- a good SQL story (this is important for being able to address data from outside Zope and maybe also for performance or general interoperability)
- making Plone easier for new developers to understand (and maybe even for end users such as installing products etc.)
- getting repoze into the loop as nice things will be possible then (but at the same time making installation of all this easier. Please note that buildout is not for everyone).
Enough points for now I think. I am looking forward to what will come out of that and wish all of the participants lots of success! After that I am then planning on getting feedback from them to understand what has happened :-) So anybody who wants to be skype-interviewed by me, please step up!
Technorati Tags: plone, psps, zope, development, strategy, opensource