This software's goal is to prevent duplicate effort where possible in money-making enterprises
The fewer concepts we have to master, the more likely we are to actually master some concepts
We should hopefully have clearly defined core components that we maintain, For example, concave need not provide many types -- just a rich container will likely do
Each core should provide the services required to build more complicated applications, E.g., concave provides a content types system. Converging provides profiles and user relationships
Migration paths encourage these projects from trying to be everything to everyone, Concave can migrate to Plone. Convex could migrate to Nuxeo or some other ECM.
Convex's releases should not depend on Concave, but Convex should integrate with Concave to provide file-management.
Each component should have an API and specified, correct extension points
If a group wants a component to offer additional features, they should develop plugins and create a distribution that contains the necessary plugins, tested together
Common frontend tasks should not require programming skills.
Having lots of different concepts is OK, as long as you don't have to master ALL OF THEM to be competent at customizing the system
Also known for "Pay for only what you eat."
Configuration should be serializable to YAML or XML (I don't care which)
Customization is through eggs, buildout, and policy products, You create eggs of your content types, workflows, static pages, user-profile stuff, and then a policy product that orchestrates configuring and installing those eggs
Yes, this is really more of a pipe-dream than a serious proposal
Use Zine or some other blog to provide blogging in Concave or Grok fire., We'll probably have two different blogging platforms -- Zine for when blogging is separate conceptually but not visually, and probably some hacked-together grok blog for when we want integrated blogging.
Plugin installer interface, All of our systems at least can share common code for registering, installing, and initializing plugins
Configuration management, A data-store for components and plugins to store persistent configuration, Automatically generated config forms, Import and export of settings, Import and export could be XML or YAML; I don't care so much which we use, XML keeps our number of concepts to a minium, Can configuration be basically just another content type? Or is that stupid, since each plugin will have only one config, Look at how Generic Setup actually works
Metadata System, All components will ideally add metadata to a common index so that we can have multi-component search, I'd be really interested in looking at RDFLib for this
Authentication Support, Likely just repoze.who integration
Now called PageParts, At most basic, a template that has access to its context, At most, is a template, a schema, a class implementing schema
Creative, Developers, Integrators, Content and strategy staff, Designers, Sys Admins
Business, Account/sales staff, The client
These are people who don't know HTML, or even what it is
This is a web developer who is caught maintaining a highly customized site.