1. Principles
1.1. Open Source, using a liberal license
1.1.1. This software's goal is to prevent duplicate effort where possible in money-making enterprises
1.2. A minimum of technologies
1.2.1. The fewer concepts we have to master, the more likely we are to actually master some concepts
1.3. Keep pieces simple
1.3.1. We should hopefully have clearly defined core components that we maintain
1.3.1.1. For example, concave need not provide many types -- just a rich container will likely do
1.4. Core components provide basic services
1.4.1. Each core should provide the services required to build more complicated applications
1.4.1.1. E.g., concave provides a content types system. Converging provides profiles and user relationships
1.5. Provide migration paths in case scope creeps
1.5.1. Migration paths encourage these projects from trying to be everything to everyone
1.5.1.1. Concave can migrate to Plone. Convex could migrate to Nuxeo or some other ECM.
1.6. Components are independent but provide common services to one another
1.6.1. Convex's releases should not depend on Concave, but Convex should integrate with Concave to provide file-management.
1.7. Extensions through plugins to defined extension points
1.7.1. Each component should have an API and specified, correct extension points
1.8. Feature-growth through distributions
1.8.1. 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
1.9. Separation of concepts to separate roles
1.9.1. Common frontend tasks should not require programming skills.
1.9.2. 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
1.9.3. Also known for "Pay for only what you eat."
1.10. Repeatability is more important than simplicity
1.10.1. Configuration should be serializable to YAML or XML (I don't care which)
1.10.2. Customization is through eggs, buildout, and policy products
1.10.2.1. 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
2. Components
2.1. Concave, a Simple Content Management System
2.2. Convex, a Simple Digital Asset Management System
2.3. Leica, a simple ecommerce system
2.4. Converging, a Simple Social Network
2.5. Conex, a big pile of experimental code
2.6. 3rd party components
2.6.1. Use Zine or some other blog to provide blogging in Concave or Grok fire.
2.6.1.1. 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.
2.7. Low-level compontents
2.7.1. Plugin installer interface
2.7.1.1. All of our systems at least can share common code for registering, installing, and initializing plugins
2.7.2. Configuration management
2.7.2.1. A data-store for components and plugins to store persistent configuration
2.7.2.2. Automatically generated config forms
2.7.2.3. Import and export of settings
2.7.2.3.1. Import and export could be XML or YAML; I don't care so much which we use
2.7.2.4. Can configuration be basically just another content type? Or is that stupid, since each plugin will have only one config
2.7.2.4.1. Look at how Generic Setup actually works
2.7.3. Metadata System
2.7.3.1. All components will ideally add metadata to a common index so that we can have multi-component search
2.7.3.1.1. I'd be really interested in looking at RDFLib for this
2.7.4. Authentication Support
2.7.4.1. Likely just repoze.who integration
2.7.5. Search support
3. Design
3.1. Use WSGI and Grok where possible, with Pylons or Turbogears 2 for data-heavy applications
3.2. Ensure that all components can speak the same authentication protocol
3.3. Leverage something like Deliverance to provide consistent, cross-component themes
3.4. Use z3c.chameleon so we have a common templating language for most tasks
3.5. We need some sort of basic page-composition framework and viewlet provider system that could be shared by Convex and Grokfire.
3.5.1. Now called PageParts
3.5.1.1. At most basic, a template that has access to its context
3.5.1.2. At most, is a template, a schema, a class implementing schema
3.6. Pretty much everything will plug into Convex for storing blob files
3.7. Develop on the ZODB, store in the ZODB, deploy with Relstorage
3.8. Create Slicehost and Amazon VMs with various distributions to simplify deployment
4. Problems
4.1. Each component has its own authorization concerns and should handle authorization itself, but people might expect authorization to "just work" logically across applications
4.2. Theming and template designs are actually pretty tightly integrated, and it's hard to draw a solid line between them
5. Audiences
5.1. Boutique web design and PR firms
5.1.1. Creative
5.1.1.1. Developers
5.1.1.2. Integrators
5.1.1.3. Content and strategy staff
5.1.1.4. Designers
5.1.1.5. Sys Admins
5.1.2. Business
5.1.2.1. Account/sales staff
5.1.2.2. The client
5.2. Do we care about end users at all (that is, random individuals who want a simple CMS for themselves)?
5.3. Absolutely non-technical content managers
5.3.1. These are people who don't know HTML, or even what it is
5.4. Highly technical content managers
5.4.1. This is a web developer who is caught maintaining a highly customized site.