Repositioning Plone

Development Roadmap and Future
1

Continuing the discussion from Future of Mosaic:

@flipmcf this is a very interesting idea, smells of Blue Ocean Strategy
And deserves a thread for itself IMHO.

Creating your own category makes a lot of sense, IF there is enough differentiation. So the question then becomes, is there enough and what would that category be?

1 Like
2

@pigeonflight Arguing about names doesn't create a new category. You have to actually find an unmet need and fulfil it in a way that people understand. Hence the idea of ranking ideas by their benefit - Decision Making Framework for Plone and ranking highly benefits to a lot fo people, or fewer people but high value or unmet needs.

3

I don't think we're saying different things here. I suspect @flipmcf was thinking this also. The end game is re-positioning in a way that plays to your strengths. The "naming" is the last step, the arguing over names only happens after we have clearly defined what differentiates us.

The steps as I see them.

  1. Understanding our benefits and selling points (or the ones we believe we should have)
    Anything that makes our benefits/selling points not true, is a gap in the story. We make fixing for the gaps our priority. Do we already have a fix that (just needs integrating)? Do we need to focus time and resources in that area?

  2. Define what differentiates us (e.g. the Only system that combines ALL of X, Y, Z)

  3. Define a category in which we are the leader. (e.g. Plone is the leading XYZ platform and the only system that combines XYZ....)

My 2 cents, not sure how this works in an open source project though.
So.. let's get back to defining our benefits.

1 Like
4

I am in complete philosophical agreement with @pigeonflight here.

I would rather be coding right now, but this needs to be addressed.

@pigeonflight has taken the additional step of outlining "how we get there" so I'm going to gladly follow his lead on it.

I'm quite intimidated to "Define" CMS and make Plone the "gold standard" CMS - that fight is a 64 player FFA and luck will choose the winner - for a year or so...

1 Like
5

  1. Plone's biggest strength is the framework it is built on and the adherence to good software engineering principles.
    [please argue to the contrary]

  2. Plone's biggest weakness is the same thing. You can't throw a Plone site up in 20 minutes and be ready for visitors like you can with SquareSpace. (I like Squarespace)
    [please argue to the contrary]

So, if Plone is a superior framework, then it needs "killer apps" - let the ultrageeks work within the framework to create killer apps and the rest of the community does the rest (pun slightly intended)

The two killer apps that we need - in my opinion - today.

  1. Page Layouts and TTW page creation.
  2. hosting.

If a startup could start their site with Plone as simple as Wix or Squarespace, they could find themselves perfectly positioned to scale.

The user story I have starts at "I need a website" and follows the lifecycle to "I need to tweak my user experience on the web" and "I need to scale easily" And if a business can do this without changing a hosting provider and with the fewest calls to that hosting provider, we have a win.

To say that we were the first platform for "NewHottness LLC" and still the preferred platform for "NewHotness [NASQ]" would be a first in the industry.

Back to the original point: Plone's biggest strength is the framework it is built on and the adherence to good software engineering principles.

6

I would say: the biggest weakness is the lack of bling, especially themes

7

Plone has a bunch of half-baked, half-implemented features

Plone has various half-baked or half-thought features - both frontend and backend:

  • Dexterity wanted to be Pythonic. Behaviours are not pythonic. No validation on the Python level (validation is only available for change through the web)
  • resource registries: integrator unfriendly, configuration overhead when you need more than one JS per JS framework
  • toolbar: lots of UI planning and research went into the toolbar. The current implementation still feels unfinished, unflexible and not widely loved (most of our customers prefer the green toolbar of Plone 4)
  • complex and verbose configuration of registry entries using XML in particular when it comes to simple modifications.
1 Like
8

At least we now have a way of adding and editing registry entries via a control panel...

This seems to be heading to a resolution, with web pack

I don't understand this :slight_smile: