Meeting MMBase discussing the results Ruben van Wendel de Joodes report Friday, August 30th 2005, TU Delft.
Ruben opens the meeting by presenting his research report and the main conclusions. The reasons to start this research were some negative claims on the developers mailing list concerning the direction of MMBase. The report, nevertheless, describes a vivid community. - The main conclusions are recapitulated: Some people do see problems, however, everyone is convinced that these problems can be overcome. None of the respondents choose answer D, "problems cannot be solved". - The problems noted are, in accordance to the respondents, more related to organizational aspects and communication, than technical. - Ruben points out that we should now try to focus on the future and on problem solving instead of having an ongoing debate about what happened in the past. - Main conclusions (before and after the meeting): A roadmap is needed, as well as a clear(er) architecture and some organizational issues can be strengthened. A remark is made: if a roadmap is to be made, the list mentioned can already serve as input. Ruben will look up in his notes which further issues were mentioned in this context. For a while there is a debate about the way things work out, or don't work out, at this moment. Obviously, a lot of software is being developed, but there is a gap between the many applications that are developed and the number of improvements/adds that end in the MMBase core. Most service providers are active (making money) at the level above the core, building CMS-specific functionality. So far, there have been very few (none?) projects that were started by vendors in accordance with the MMBase guidelines. For that reason we now have a large diversity in solutions for workflow, versioning, etc. The end-users, would really like to see more convergence in the development. How to deal with these issues in the future? 1. Stimulate to start projects in accordance with the MMBase guidelines. Even though it looks pretty hard to do so within the scope of everyday business with "always" strict deadlines and budgets, the committers stretch out that the fear for delays and criticism might be exaggerated (did you ever try?). 2. Draw up (and maintain) a roadmap and an architectural model, with a clear description of demands for components/applications and the connectors necessary (API), to interact with other components and the core of MMBase. The idea is, that if a component is developed (chat, poll, forum ) in accordance with the defined standards, it can (should?) more easily be accepted as a community application. So you could say we are looking for a way to make better "hacks" and find a way to get them accepted/maintained. Most attendees agreed on the necessity of drawing up a roadmap for MMBase and declared that they would help to achieve this. The first focus should be on the question what is MMBase. Or, perhaps even better, what do we want MMBase to be. And what are the "unique selling points" (we might find some of those arguments in the IBM Systems Journal paper). Agreement was reached on further steps to be taken: First, there will be a second meeting of the commercial service providers. They will discuss the initiatives to be taken by themselves and the arguments given by the committers (lack of feedback, little participation in projects, standards for joining, voting procedure, etc.). This meeting will take place on November 8. A week later, on November 15, we will have a general meeting at 16.00 hours. Please not: the location will be communicated later. All developers, users and vendors are invited. Goal of this meeting is to reach agreement on how we move on. Towards a great future, as we all hope. Regards, Jo. _______________________________________________ Developers mailing list [email protected] http://lists.mmbase.org/mailman/listinfo/developers
