This is my happy rant about the sad state of Plone adoption and bootstrapping your Plone the development project. Again – you may have heard this before. But this time I draw pretty pictures 
Each new Plone release has brought less happiness to the developers. We are not in free fall anymore, but the happiness curve remains flat (source: rants of Plone IRC channel)
Developers are the consumers of Plone the project. The effective result on the first diagram is that it is very hard to consider Plone as a platform for your new project unless you are “in the Plone” already. There is lack of “start building my site on Plone from the scratch” option.
Eventually this will marginalize Plone. People prefer to work on easier tools, tools they can get started easily even those tools would not be the best fit for the solving the problem (PHP, anyone?) When I learnt Plone I was still in a school. Can a student anymore learn Plone? (source: mailing list questions and on-line discussion)
This will eventually lead to a situation that we all die to the old age, alone with our Plone sites. That would be sad (source: Plone Conference picture galleries)
I don’t believe this is a result of any person doing things wrong. It is just a general oversight, the tradegy of commons. People are too excited to work on the fresh things and forget those who are still learning to drink our champagne (choosing a bottle is difficult if they lack labels). There hasn’t been focus to make Plone easier to adopt. This is slowly changing with plone.api and things. However, based on e.g. the sprint topic list of last Plone conference the message is going through slow. (source: past sprints until summer 2012)
What we can do?
- On the Plone roadmap and Plone conference keynote I want to see “Plone easier for developers”. Looks like it has not made appearance on any keynote or roadmap for a while. The highlight have been features, features and features. Let’s make this year different.
- For every Plone release, let’s require that there is at least 1-2 PLIPs which actually state “this is how Plone will become easier for developers”
- How we can gently guide community members to take the tasks which make adopting Plone easier? We need to staff the tasks with people who actually know things. People how need to dig up things by turning stones (code) upside down don’t tend to work there very long.
- Every time there is a new feature in Plone the feature sponsor should think: “How, with this new cool feature, I can make people more happy when they start using it?” I don’t want to see any feature which after the landing will lead to a situation where people come to ask to IRC “How this works” and I cannot point them to any up-to-date functional manual about the things. Lack of on-line tutorial = the feature is effective not functional. It makes me feel so sad: “How did this happen, again?”
- How can we reduce the steps the developer needs to take to get his Hello world running? Can we make a tutorial which fits into a single screenful of text, because your dev tools would be provided out of the box? The first impression counts the most.
- plone.org needs love too. Documentation team no longer effectively exists. Let’s give candy for those who volunteer.
How can we make these things happen? It seems everyone accepts this is the state of the things, but looks like there is no remedy coming or it is happening slowly
- Should we set core repositories to read-only until the documentation can catch up the things?
- Should we lock core developers and their friends to a room full of beer with disabled PyPi access, but give functional plone.org edit access?
- Let’s take some community members to a river boat ride on Arnheim and don’t let them land until they post out a solid story of functional ZopeSkel, unified installer and Hello World tutorial?
- Make sure that each Plone Conference sprint topics proposals has a bullet “this is how we actually make Plone adoption easier, not more difficult”
Let’s meet at Plone Conference (now with less offensive talk topic)
Cheers,
