Plone 2020
The future of Plone - a community-generated roadmap from the 2014 Plone Conference
A Plone 2020 Open Space discussion was held at the 2014 Bristol Plone Conference - "Plone 2020" being our shorthand for "What should Plone be in the year 2020". A large number of people attended. To efficiently elicit ideas from the crowd, Martin Aspeli led a brainstorming session during which people wrote ideas on sticky notes, and Martin and helpers organized them by topic. The goal was to look for areas of consensus regarding the long term direction of Plone. There was in fact a surprising amount of consensus, and the results form a community-generated Plone roadmap.
The 2015 Strategic Summit took these ideas up and developed a consensus on direction.
Summary
We first asked: Why are we here at the conference? Why do we love Plone? Our answers were very consistent:
- Community
- Features
- Security
- Technology
- Making a living
We next asked: What are the top one or two items that need to be improved? And as Martin eloquently reminded us: If we are going to change Plone, can we please not mess up any of the things we love?
Grouping the broad topic areas by theme and adding a few annotations, here is our community vision of the evolution of Plone. This vision drove work at the conference sprint, and we hope it will guide sprint work in 2015 and beyond.
- APIs, hide complexity
- Restful JSON API (This is important for the future)
- Python API - improve, extend plone.api (This will mitigate risk when making code improvements)
- Integrator usability, grow community
- Documentation and training
- TTW (through the web) theming and templates
- Improve deployment
- End user usability
- Small fixes
- Or major overhaul (intranet consortium-type project for mockup-mosaic?)
- Code improvements (This is high risk but can be mitigated by above API work)
- Simplify code base structure
- Remove old/awful stuff, notably CMF, z3c.form (Need for deprecation warnings)
- Strategic
- Roadmap and communications
- Community processes
- Motivation and Funding and Marketing
Why do you love Plone?
A transcription (in no particular order) of all the brainstorming ideas, grouped into broad topics.
Community
- Wisdom and experience in a box
- Shared experience
- Community driven development (smart community)
- Community
- Community
- Community: professional and friendly
- Community
- Community
- Helpful and nice community
- Community
- I love the community
- Open source community
- People
- I am here to learn from clever people
- Great developers
- Community
- Open source
- Plone and the Plone community teach me the important skills and ethics
- No lead company
- Plone community
- Community
- The nicest community
- Open source community
- Community
- Awesome global community
Features
- It is nice to use (user friendly for editing and admin people)
- Solves something nobody else does in open source CMS
- Flexibility
- Incredibly flexible
- Plone is a content integration framework that lets me integrate almost everything
- Plone is perfect fot the type of projects I love to do: large, feature-rich CMS websites for higher ed and non-profits
- Flexibility
- Flexibility
- I know: no matter how much my client's needs grow, Plone will work for them
- Full-featured, directly usable system
- Easy to have a full featured site in a short time
- Control over and speed of functional development
- Rich range of functionality, flexibility
- Powerful
- Ecosystem
- Plone lets me produce solutions to diffferent problems in a consistent repeatable way
- Repeatable
- Provides a solid foundation to build my solutions
- Out of box
- Our users depend on Plone to get their message to the world
- It allows me to empower my customers to do more themselves, especially in cloud
- Best open source CMS for universities
Security
- Sustainability (10 years same content)
- Plone is a good product
- Stable, secure web dev framework
- Stability, security, TTW
- Very secure
- Security
- Security
- Security
- (User group permissions roles) intranet
Technology
- Technology
- Innovation
- Zope component architecture
- ZODB
- The Zope ecosystem
Making a living
- It is my job (that I love)
- Pays the bills
- Job $
- Cost effective development
- Its features tick so many boxes that it's easy to sell to big institutions
- Guaranteed paid work that is fun to do
Other
- Open source commons/resource managed by foundation
- Don't know yet! New to Plone!
Identify the top one or two items that need to be improved in Plone
A transcription of all the brainstorming ideas, grouped into broad topics.
JSON/REST API
- Provide a web services API
- A complete RESTful API
- A REST API allowing us to decouple UI from backend
- (JSON) / API; (REST) / API; (PY) / API
- (Proper) RESTful (JSON) API
- JSON REST API
- RESTful JSON API +x
- Embrace Javascript for UI
Python API
- Less ways to do stuff, one canonical way, example: plone.api
- Make Plone more pluggable => Well defined APIs for: Authentication, Data export, Syndication between instances
- Extend plone.api
- Python API to separate Plone features from Zope
- Extend plone.api
- Make plone.api complete
- Sane API
- Hide complexity from integrators, newbies, non-programmers through Plone API, easy installation, documentation, training
- List features and templates and easy option to turn them on/off - too many hidden stuff now
- One style guide for all code
Improve End User UX
- "Better" portlet handling
- A better UX experience that allows more sophisticated web content without developer
- Make the user experience simple and intuitive/beautiful
- Improve experience for content editors by combining flexible tile layout editor with outstanding design
- As a user I want an easy to use editing experience with an up to date UI
- Enhance UX and more designers in community
- Make Plone beautiful out of the box (UI, theme)
- Better UI
- Fix the top content management UX bugs which confuse users, such as default pages and roles
Improve Deployment
- Improve developer experience by: 1) Making it obvious where to obtain buildouts; 2) Making Zopeskel/Templer work (and generate good defaults)
- Make Plone dead easy to try without installing
- Be on every cpanel-esque platform
- Provide easy recipes to deploy in various scenarios
- Improve ZPublisher for easier deployment story (WSGI)
TTW (through the web) Themes and Templates
- Easy add-on installs - click and run
- Unify theming solutions
- Two ways/techniques for theming that 90% of us are satisfied with
- Theme editor that can be used for real in production
- Consistent TTW experience so someone newish to the web can create a completely custom site in a day
- Empower users with robust tiling/mixing/embedding
- TTW view creation/customization and export - and/or Mosaic
- Finish TTW development story
- Simplified configuration - single source/way of defining content types/registrations (vs. ZCML, GS, ...)
- Improve caching support (response times)
Documentation and Training
- Engage computing students so they know about Plone before they graduate
- Grow community by giving more training to integrators and developers
- Cook book with best practice recipes to do things in one proper way
- Make Plone more appealing to end users and site owners as opposed to sophisticated devs: 1) Entry level user training; 2) Hide complexity
- One globally known single entry point knowledge base (with clear procedures for maintenance)
- Make it easier to start Plone development by recommending the right way to do things in the docs, like Python does
- Better documentation + plone.api to help new developers starting with Plone
- More standards to do certain things
Improve Forms Experience
- Kill z3c.form
* Merge z3c.form wrappers into a single form package
* Simplify form generation
Simplify Codebase Structure - Remove Old Code
- Clean up multiple ways to do the exact same things in the codebase
- Remove (replace) old cpy/cpt/... code
- Clean up dependencies, i.e. remove CMF
- Remove CMF
- Move/merge Zope/CMF into Plone ecosystem to make it more usable
- Remove CMF*
- When I run a PDB and list all the methods of an object, I want that list much shorter...
- Remove old/deprecated code (CMF, etc.)
- Remove monkey patching as the default recommendation - make it easier to override Plone internals to avoid this
- Simpler codebase
- Clean legacy (improve developer experience)
- Only 2 ways for doing things (i.e. consistency)
- Update core for new web standards
- Remove complexity around writing views (context of view variables, template attr in ZCML, etc.)
- Reduce number of eggs
- Would like to have Plone smaller - some packages should be available as add-ons
- Reduce cognitive overload by simplifying core
- Grok vs. ZCML - pick one and make consistent documentation for it
- Improve dev's experience by removing/hiding ZCML
- Possibility to view (chart? - like DCWorkflows does) all products and dependencies when installing a product (and sub-product)
- Do not break if one part breaks
- Stable software stack
- Do things the right way (eventually)
Roadmap and Communications
- Give Zope some love (sprint? roadmap, plan)
- Roadmap should inform users and potential customers where Plone is going and that Plone is vital and in active development
- Roadmap communicates the vision of the community and leads to discussion
Motivation and Funding and Marketing
- Find way to pay/motivate bright minds to get stuff done <-- board/framework team agreed with
- Do more fund-raising to be more effective in achieving goals that are set
- Fund marketing to gain more visibility
- Help Plone companies market Plone
- Improve public visibility by sharing success stories and have a clear picture for people not in the community
Community Processes
- Less bitching
- Change foundation rules to empower leaders more
- Bring Martin and Laurence back to the community
- Bring Martin and Lwrence back to the community
- Discuss issues openly in a friendly way
Other
- Improve connectivity with other systems/DBs/single sign on
- Breathalyzer on github commits
- Be Python 3 compatible
- I want to create a product that will be used by others - I can't be more concrete because I'm new!