no, seriously, have you look at the new WordPress editor?
Plone used to be years ahead of other players in many aspects; it's a pity that we didn't had the tools at the time, neither the resources later, to turn those concepts into usable software.
(kudos to @agnogueira for sharing this with me.)
A massive shame. Commercial open source wins over foundation open source when it comes to non developer tools 
I don't see how it's useful to compare how much progress a fat corporation vs an unpaid all-volunteer community can make. We have done very good things in the meantime, and Mosaic is in production use (and is included in CastleCMS). (Andreas, don't comment!)
We (the entire community) can still create our own editor, and @sneridagh and Timo and others have already done some nice things with React and Pastanaga editors. If you want to help, jump in!
as usually, I disagree with you: it's always useful to compare… in fact is not only useful, but strongly necessary.
of course we can create our own editor (the tools are now widely available), but the question today is if we really need to do so.
we never found a use case for Deco/Mosaic on the markets we serve; it's very difficult to maintain many different layouts for dozen of thousands of pieces of content; it's easier to do so in filesystem code.
I'm tempted to prepare a presentation about OSS development, thermodynamics, closed systems and entropy… maybe in 2019.
On that note, the group of parties whom benefit more from XDV / Diazo than lose time fighting with it is also slim.
But as nay-saying all new initiatives leads to stalling quicker, better let more flowers bud.
These days people just seem to roll their own JS on top of the restapi, though.
I totally agree with you; the ideal workflow is to let people test their own dog's food as an add-on, present how fantastic their idea is on a Plone Conference, and incorporate the best ideas on core, those that really make sense for everybody.
problems starts as soon as people push their dog's food on core, leave all the shit broken and fly away to another place leaving the (sad) state of things we have now.
just an example: I counted yesterday 223 open issues about the toolbar… 223, seriously!
that's entropy.
IMO is more that UX problems are hard. And community open source doesn't do well at long term hard problems. In particular it doesn't do well were there sometimes a lack of information to make the right choice. Going to python 3 is an easy choice... a lot of work but there was no other choice so its easy for people to take the initiative and feel like they are contributing in a direction everyone will appreciate.
On the other hand, Guido's exit after heated arguments about if ":=" is a good idea is the same problem we have in the plone world.
In just three posts you guys have expressed various opinions of giving editors layout is bad vs good, giving integrators simple non python ways to layout at a theme level is bad vs good. It's just too painful to resolve
and that's why I think we have to be careful and avoid unnecessary stress: nobody would care if I create an add-on to do X or Y, but many will argue if I want to push feature Z on the core for sure.
what I want is less unnecessary disruptive changes in the future: all those great, revolutionary ideas that will put Plone into the next new level, must be tested with real world cases outside the core first.
and I think we have learned from our past mistakes:
Mosaic and the REST API are greats examples of that: as add-ons they are showing their potentials and limitations; and they have a shorter release cycle independent from Plone versions, making easier to test and fix them.
(if anybody else, besides me, wants to know what's that := thing causing heated arguments on the Python community, take a look at PEP 572.)
It seems to me that you're arguing out both sides of your mouth 
You say you want features to remain outside of core, but then you also say you want them to be tested well together.
I agree with @hvelarde but lets put it in a different way.
Big disruptive changes... In core or out of core matters less than, does it solve all the usecases, or does it fix half the things and break another half?
For example to go all in a grid system like mosaic and switch to folderless and components, we need to ensure
Instead what happens is we wait for deco, mosaic, pastanga, angular, react, vue-angl-act or whatever is the next big bang and be disappointed when it either a) makes things pretty but doesn't improve how plone works (ie the toolbar) b) requires a lot of upgrades and doesn't solve all the use-cases because it was created with a limited set of usecases in mind.
I don't agree with keeping things out of core that long term benefits everyone.
If either of the following are true then the core needs to change
Because what I think is happening instead is we are getting distributions instead which are solving UX problems in ways that core plone would benefit from but can't because they have been implemented as one big take it or leave it package. They don't follow the pick-n-mix plugin philosophy that has made plone great. CastleCMS, Quieve, Cynin etc.
Why? because core plone is failing to create an environment that lets them customise plone via a plugin cheaply enough, or changing the core to make the same UX fixes creates too many community arguments
The end result is a fragmentation of effort and community.
Quieve and CastleCMS. Take your learnings (based on actual user experience) and customisations and bring that back to the core... or at least plugins... pretty please? People listen to actual user experience. I hope.
Yeah, I think the Plone frontend modernization efforts stopped for a couple of years when people started waiting for Deco to land, but it was somewhat silently abandoned instead.
With plone.restapi we give the modern frontend folks a familiar canvas to do their thing on, not a weird mishmash of oldschool-ajaxy widgets returning everything from OFS error snippets in HTML 3 glory to XHTML 4 in listings.
With the resources available, it looks prudent to assume Plone will only get the CMS bit right, as it usually has, and provides an API to that.
We've essentially done that to testing and some backendy stuff. Especially the testing thing hurts IMO.
But I'd not expect us to untangle parts of the testbrowser out of our own stuff like ftw.tabbedview to make a plone.testbrowser on top of which ours builds (doing raw zope.testbrowser is personally sorta painful for me at this point).
That's always been the case. What is changing is the size of the community. It's a thinning club.
Most bigger contributors are companies and these things exist because there are clients paying for them. Cleanup, reintegration and generalization are expensive.
Layout is the CMS part unfortunately, at least for the content area. Thats where we are stuck. We need to give the user something better than tinymce and default pages.
Very true. Sometimes more than what it cost to write the initial version.
Is the cost of abandoning plone less though because its not competitive anymore?
How feasible is it to build on Gutenberg? Similar to building on TinyMCE. Since it is open source Plone could benefit from the "engine".
Also there's this:
It's intersting its efforts to make it handle layout have come up against similar indecision.
Blockquote
My feedback would be this starts to turn the editor into a layout tool rather than a content editing tool. Things like responsive design make layout control very difficult in CMSs and IMHO are best left to the theme designer / developer. I could certainly see options like "2-col" but actually dragging dividers to basically allow users to lay content out seems outside the scope of a content editor tool to me.
Not sure if that philosophy is in agreement with how Project Gutenberg sees itself?..
but they did make it do layout anyway
As to if its contains too much WP specific stuff to make it easy to integrate... maybe would have made an interesting GSOC project.
Interesting developments in the Drupal community:
I really think that any effort should have high impact for non technical users.
This wysiwyg editor looks interesting.
https://editor.ory.am/
We looked into both ORY editor and Gutenberg long before we started to implement the new Pastanaga editor in Plone-React. Both were hard to integrate and lacked features that we need.
FWIW, I did spend a decent amount of time trying out gutenberg and at least right now, I would not recommend that path. It's very much tied to wordpress. There's no official javascript package for it, it uses globals, jquery, etc. From what I could tell, the project was kind of a mess from a technical standpoint.
I do really like the ORY editor and have successfully tested integration with volto.
I think it might be good for the community to not maintain their own editor.
Awesome! Did you push your ORY integration code? I would love to have a look.