RiskFactors

Risks

Status: IsDraft

Here we capture the most significant risks to the success of the project, along with proposed ways to mitigate those risks.

1. It may take too long to develop a component architecture. We may have bit off more than we can chew. Since this project has such a large scope, we may end up working on it forever without coming to resolution.

   We should carefully limit the scope and deliverables of this project to keep it reasonable. Perhaps the project should be broken into sub-projects to keep us from getting overwhelmed and having to do everything at once.

   Note by editor: I think we have overcome this issue. Several releases are planned or are available when you read this.

2. There are unknown issues that need to become known before we can get our story told.

   Note by editor: I think we did a very good job managing this risk using the Wikis, the Zope 3 Dev mailing list and sprints.

3. It may end up being too complex. The goal of this project is to make life easier for developers. If the component architecture ends up being too complex or to hard to learn or use it will not satisfy the goals of the project.

   We need to keep close to the Zope developer community to make sure that what we develop doesn't get too far off track. We can help folks keep tabs on what we're doing by developing user documentation as we go and making plenty of releases as we go that folks can work with.

4. It may be difficult to migrate Zope to a component architecture. It may turn out that the component architecture doesn't work well with the existing Zope code base. This will result in either an infinite postponement of a switch to using it, or a big backward incompatibility problem.

   We need to make sure that we plan for a gradual migration to the component architecture. We should include use cases and tests to keep us on track.

5. We may alienate existing Zope or CMF users.

   We need to make every effort to assure that changes are backward compatible and to provide a migration strategy for existing Zope and CMF software.

6. The unification of portal types and interfaces requires persistent interfaces. This is similar in many ways to providing persistent classes, which is tricky. (Addendum: there turned out to be a relatively simple way to achieve persistent interfaces, similar to persistent classes, that only required a change to the Interface package. Thus this is not a significant risk.)

   We will mitigate this risk by being conservative in what we try to achieve. We will only attempt to provide the functional equivalent of portal types through the web for now. That is, through-the-web interfaces:

   • Can only be used for new content types, at least in this development cycle, and
   • Through the web interfaces will not specify anything other than a name. Note, however, that the Portal Types service can track other meta-data for content types, as it does now.

   CMFContentTypeDesign for design notes.

7. We may need to think harder about interface versions and their interaction with component registration.
8. The long-standing problems with numerous permissions and a lack of descriptions are magnified by the component architecture. There will be more types of objects (and a corresponding number of permissions) and more activities site users can perform.