Reasons
For many years, until the end of 2008, the MeqTrees Project was essentially a 2-man operation: A highly productive System Architect (OMS) under the loose tutelage of a technically unassertive Visionary cum Protector (JEN). In addition, important contributions were made by a group of part-time associates: Tony Willis, Sarod Yatawatta, Maaijke Mevius, Ronald Nijboer, Rob Assendorp. With such a small team, Project Managament could be mercifully limited to a combination of informal discussions, email gripes, Bugzilla entries, a weekly videocon and an occasional statement of Grand Policy. This has worked remarkably well, fostering an atmosphere of freedom and creativity, disciplined only by the consistent interfaces imposed the single system architect.
Now, after entering into more formal ties with our colleagues in Oxford, and the subsequent Release, and before we absorb the first batch of "stemcells", the MeqTrees Project has entered a new phase. This requires a little more structure than before, the details of which must be determined by our special circumstances, and by what we are trying to do.
Although we have demonstrated the power of MeqTrees in the hands of an expert, it is not yet a package that can be offered to the "average" user for routine data reduction. Too many things are still missing, like a Parameter Management System, a Script Exchange Mechanism, better tree building tools, a more able TDL option manager, (even) more visualization, all kinds of documentation, examples, etc, etc. In addition, MeqTrees is too different from existing packages, because it speaks the new language of the Measurement Equation, and because it offers a bewildering number of possibilities. There is (as yet) no simple handle to crank.
For all these reasons, and because there is little prospect of formally enlarging our tiny team in the near future, we have decided to try a different approach. Noting that there is an urgent need for something like MeqTrees in the SKA community, and noting that the unusual modularity of MeqTrees makes it very easy to contribute scripts or nodes remotely, we will try to enlarge the MeqTrees team informally, by nurturing the first CCC-network (Contribution, Collaboration, Competition). Its members have the opportunity to take part in the grand SKA adventure, without having to leave their institutes.
Eventually, membership of a CCC-network will just be a (the?) new way of reducing data. But for the moment, we can only accept those who have demonstrated an unusual productivity in writing reliable software, thereby proving that they have highly organized brains. Such people need very little documentation, they are not in the habit of whining, and will rapidly absorb the new language (with any luck, they will not even have to un-learn the old language). They will quickly become the vanguard of the new generation of user-developers that will determine the success of SKA and its precursors.
Thus, the new MeqTrees Project structure is determined by the needs of the CCC-network. This means two things:
- The members of the network must have a reliable MeqTrees kernel to work with. This requires a somewhat more professional approach towards Releases, testing, and shielding the kernel from outsiders. We must also guard against single-point-failures (we have a pretty obvious one!).
- Especially this first batch of members must very much feel part of the team. This means that they should participate in discussions about new functionality and other Project activities. In a sense, we are constantly inventing ourselves because MeqTrees is not a normal project. The core team will never be large, and we rely on self-motivation and self-discipline of highly talented and productive individuals.
Finally the question: Is it all worth it? Why are we busting our guts in order to offer the first 3rd generation package to an ungrateful world?