Omegawiki: towards a 2.0

All software sooner or later needs a new release. Requirements evolve in time, new functionalities get added and sooner or later even the best design needs some basic reordering. 2.0 time has come for OmegaWiki, too.

Implementation details are currently more or less in a RFC state. It is extremely important that we do not try to be friendly, but rather to be as hypercritical as one can be. Whatever is not assessed now will cost money and time later, which is definitely not what we want.

The one and only safe bit we can already deliver is the strategic vision behind 2.0. Our strategy is expressed by 8 corner stones, it is fairly well assessed and it shall serve as a guideline in evaluating all proposals concerning implementation details.

1. Independence: this release defines a critical passage in that no client will be allowed to directly use DB tables any more. This means that:
   • The DB becomes a black box that is to be used with one single call. An API based on stored procedures is defined and maintained DB side;
   • Omegawiki becomes independent from PHP and can be used just by any third party no matter their preferences in technology (Ruby, Java or whatever else);
   • Interaction time shrinks to an absolute minimum, since the interaction with the database is performed in one shot.
   • Uis are now Uis, they only care about formatting data and managing user interaction, but have no control whatsoever on data structure. This also allows a better specialisation of resources.
   • DB administrators can perform a typical DB admin job: they can concentrate on performance and stability on their side of the fence, without interfering with development activities.
2. Flexibility: an unlimited number of different applications must be able to use the DB without risking to damage each other.
   • We are already in the situation in which there is more than one power user for the DB, and obviously all projects have their needs. We must make absolutely sure that we can allow to single users all the freedom they need.
3. Cost reduction: each every entity in a system is a cost centre. This release concentrates on cutting the number of existing entities to the absolute minimum. We aim to have few extremely powerful entities, rather than a lot of small specialized entities that all need an individual maintenance cycle. This will allow to cut dramatically our need for resources both in terms of hired programmers and and documentation.
4. Full documentation: no part of the system will be accepted from any third party unless full documentation according to project standards is delivered.
5. Personnel rotation: developers will not work on the same code for more than a few weeks before being rotated to other jobs. This will at the very same time
   • spread knowledge about the system as a whole among the developers,
   • make sure that everyone is useful AND nobody is necessary, which makes it easier to
   • find less expensive resources
   • substitute missing individuals (thus allowing more freedom in programmers' holidays, too)
   • accept volunteers and integrate them in our production cycle, even if they have little time to invest in the project
   • verify that the documentation is absolutely clear, updated and useful

6. Distributed architecture: our database can reside in a number of concurrent servers. Data get distributed along the OmegaNet by means of RSS feeds. All members of the net can subscribe to any of the public feeds in order to build a compilation of the data they need. Users not wishing to publish their data on external server can define their data as private, and serve it privately as they please while still integrating with public data. This is strategically important because:

   • a number of power users will want to remain in control of their data while sharing only part of it, while they will want to be automatically updated about the progress made on the public network.
   • a good service is a service that can be used in a large number of projects/contexts at no cost. OW's architecture is designed to be easily integrated with other projects as a knowledge repository.
7. Fine grain copyright management: data needs to be copyrightable at very low level. Licenses are specified so that people may be able to extract only those data that are published under a certain license.
8. Independence from coders: data will be designed in such a way that users will be largely able to define their own data relations without needing to pay money to professional developers.