The discussion was about "why isn't plone easier?" and two tweets really highlighted the core of most people thinking about it I think.
Patrick Gerken @do3cc May 12
"@nzupan@yenzenz Always these hidden complaints. Plone is not that approachable for small sites any more because not enough developers cared"
Jens W. Klein @yenzenz May 12
"@do3cc@nzupan ack, because its not plones major use case anymore. but i'am not sure if this was a complaint."
What I think is this:
"be approachable for small sites" will always be and has to be plones major usecase. For various reasons to do with how open source spreads and enterprise software is procured, the only way plone will survive by concentrating on large sites is by being dominated by one large company. It is what a CMS does. It allows non technical people to make websites. End of story.
many developers do care about making it approachable. Plone wouldn't be as approachable as it is if this wasn't the case (and it is a lot more approachable than we give it credit for).
but it could be way more approachable and others are catching up. But plone has some fantastic cards up its sleeve that others don't have like purely online development which if were our main focus, could make plone very approachable.
but there is a fundamental mismatch of motivations which is at the heart of all community open source.
The mismatch isn't really that most plone companies don't have small clients as customers so there is no economic motivation to develop features for small sites and hobbyists. It's maybe partly true but the reality is large amounts of plone is written by people who work for organisations without a large direct profit from plone clients so this can't be the whole picture.
The real problem is that engineers understand their own problems best and open source is really about scratching your own itch or scratching the itch of people they admire. And that is entirely understandable. This is why the most successful open source is developer tools like databases or operating systems or frameworks and also the reason why plone is often pulled in the direction of being a framework and large amounts of effort gets spent on improving core plone development. Again entirely understandable. It is also the reason why the most user friendly software is often made by the most top down hierarchical businesses. It takes a lot of effort to get developers to understand real user problems. Trust me. I do this every day. I'm not assigning blame but just trying to outline the problem we have to overcome to make plone more popular.
That challenge is this: If our users are 2 firemen, jack and jill and jack can write content but never touched a CMS and Jill knows some CSS and html and JS but never touched plone, how do we reorganise the structure of the plone project to get engineers making decisions on how plone should work, to understand and help people they don't know or admire, such that Jack and Jill end up with a great website in 5min and then start telling all their friends about Plone and finally the entire countries fire system runs on plone?
Note I'm not asking how we make plone easier. I'm saying our organisation and structure and processes lead to the plone being less user friendly than it could be. That is real underlying problem. I'm asking: how do we make the plone organisation/processes better?
BTW: sorry for the long post. Twitter is sometimes better.
As @djay knows, I am a big proponent of TTW or Hackable Plone. If you look at that section of the Strategic Summit Report (I posted a link to this yesterday), you can see we have the makings of a manifesto that will maintain and improve the things we love and hold dear in large Plone self-service installations (and by "we" I mean big edu and gov and non-profit deployments, plus what could be large scale Plone hosting businesses like the one @svx is launching, and what Ploud once promised).
I don't agree with @djay that the community has broken processes (I paraphrase). They work as well as we are committed to making them work, and we operate under constraints that corporations do not face.
If we as a community want to operate more like a corporation, then please support that effort by sponsoring the Foundation (Donate). We do not get that much in the way of donations, but what we get we do use to fund sprints a lot.
If those of us who want to keep Plone "TTW" or "hackable" are serious, we will get together and fund or otherwise contribute code, or find devs to help us, or convince existing devs that our interests are really mostly in common. So far, edu folks haven't come together to build new code much (I say this having been part of the PloneEdu initiative for quite some time), and so maybe edu and gov and non-profits need to work together to formalize the manifesto and find ways of resourcing it. Most current core/framework devs aren't from those sectors so of course they don't feel the same urgency; that's fine - it isn't reasonable to expect them to do what we want them to do.
This is a do-ocracy, or, in the immortal words of Tom Cruise, "Show me the money!" [or the code]
Coda:
Here is the post with the link to the strategic summit report. This is now part of the Plone roadmap. This is how our community came together in a truly impressive way to discuss then decide on our future. The summit was a shining example of beautifully functioning community processes.
you can see we have the makings of a manifesto that will maintain and improve the things
FWIW, manifestos don't improve things, coordinate, document, coordinate community members, write code, etc. Only people do. I'm not trolling you Kim, I'm just saying that simply because we have a manifesto doesn't mean we have the people working on core that are committed to doing this work--as you've touched on.
In general, Dylan is right though. I don't know what you can do about it though. Companies and people involved in plone need to coordinate and/or contribute. As for our company, we'll keep trying to grow and contribute back more from that growth. Plone is important to our future and we'll be using it for many years to come. And even though we target larger clients, I still try and help where I can with hackability related stuff.
Indeed @djay is right. Neither we posted a complaint nor an goal, it is just an observation.
Plone is not that approachable for small sites any more because not enough developers cared
and
...its not plones major use case anymore
Thats coupled together. Plone is OpenSource and defines its feature set a lot from people who care and do.
It's not that I say no-TTW is ok. At PLOG I pointed out that a good TTW story is important for Plone. And @tkimnguyen gave some really good examples of people using Plone mainly TTW - even in big deployments.
So all you out there caring of Plone TTW: write concepts, write code & docs, write pull requests and PLIPs! Get it done! Make it a major use case again.
Larger projects tended to be the bread and butter for most core developers. That definitely biased development. But even then development had to be incremental. There's a nice article on this phenomenon which I think applied to Plone, Why Our Genome and Technology Are Both Riddled With "Crawling Horrors".
TTW was neglected because it just wasn't useful for the type of projects most core developers worked on. Supporting it was inherently complex. While it was one of the things that initially drew me in to Zope, I'm far from persuaded that the complexity is really justified.
I think the JavaScript discontinuity provides a credible path to a radical simplification of our stack. If the frontend is separated out then rewriting the backend becomes much more manageable.