On Saturday 23. October 2010 11.16.45 Cyrille Berger Skott wrote: > As you might be aware, after months of discussions, it has been concluded > that the best solution is to split the community. > > However, the split is going to happen at application level. The maintainer > of each application will be asked to consult his fellow developers to > decide in which group, A or B, the application will lived. The other group > is free to fork the application under a different name. It is also > possible for the developers to change the application name and ask that > the current name is not used by any of the group. This can be used as an > opportunity for a fresh start. I have not been part of those discussions (though I wrote an email when asked for my opinion) and the split on application level is a new suggestion for me. I guess the name 'koffice' has had plenty of requests for renames as well as many of the other app names so maybe this is a good opportunity. Fresh start, as you say. I'm not for or against. But lets focus on the split here. I want to go a bit deeper in the now purely anonymous Group A and Group B. People need more to make an informed choice what to join. The main reason for splitting is not about applications, the main reason is also not about application maintainers. The actual background reason is about focus and how to be part of a community. --- What groups? In the KOffice community there are currently two distinct streams of efforts. Two streams with different priorities. There is the effort to get KOffice successful for desktop usage which have a set of priorities; the most distinct one the end-user-readyness. See this post for KWords focus on this; http://www.koffice.org/blogs/thomaszander/philosophical-investigation/ Next to that there is an effort to get a KOffice core and certain applications and the Microsoft filters in such a state that Meego can ship this with their own user interface on top. The most distinct priority is getting advanced MSOffice documents rendered properly. These priorities are at conflict, there is some overlap but the two streams clearly focus on different subset of functionality, while using the same codebase. Conflicting priorities while working on the same codebase need coordination and need compromise. Compromise to avoid that changes made for one stream will negatively impact the efforts of the other stream. The problem we have today stems from the basic fact that there has never been an open discussion on how to synchronize those two sets of priorities. The individual teams never had an open discussion where the goal of the discussion was to find out how we can work on the same codebase without hurting each others goals. The end result is clear; two teams that fight on one codebase, and KOffice has been in a stalemate for a while, I'm glad this stalemate has finally been broken. We lost enough contributors in the battle, lets hope we can get some back again after we regain our internal focus. --- What would be good for KOffice as a FOSS project The split as its proposed really is not a split for applications. As Cyrille wrote; the group B will fork KWord. So lets call this whole thing what it is, a fork off of KOffice focusing on getting it ready to render MSOffice documents properly and getting it working for Meego using the ways of working that Nokia uses for such projects. The group I want to be in is one that embraces the KDE and the FOSS philosophy. The idea that we are building a community first and a product second. Contributions from people that commit and run away are valued less; we value people over code. The group I want to be in is creating a product that is innovative, is next millennium and is not chasing a 20 year old competitor. The concepts of Flake, the ideas of 3rd party plugins with things like the music shape are pursued further and we become the first suite to exploit these concepts to the fullest. Even if that means we don't become the word processor of choice for legal students. In KDE we have a saying; If you want to go fast, go alone. If you want to go far, work together. The way forward for KOffice is to embrace the different needs of people as well as companies, but be clear to say no to those that are unwilling to embrace the needs and requests of those that lead the way. --- Conclusion The people that stated to want to fork as group 'B' have a different goal for the KOffice codebase. Their priorities are different and attempts to make those priorities open and clear (like working together in kdes bugzilla) is an ongoing struggle. Attempts to synchronize the different priorities are largely one-sided and unsuccessful. KOffice is an open source codebase and a free and open source community project, part of the larger KDE community. The best way to get KOffice to go far is to work together and therefore be an opening and growing community. We got distracted by allowing in our community a team that failed to integrate and put their own needs over the needs of KDE. The solution going forward is to allow the people that want to go fast to go on alone. The resulting project of going alone would not be an FOSS project as described above. Due to this the fork of Group B would not fit in KDE (the community). Group A should remove Krita and Kexi as they are too big to be without maintainer and remove the f-office that is not useful anymore since Maemo 5 is end-of-life. (No new devices will have it). The rest of KOffice stays unaltered. We focus on growing the community again. We talk to the KDE release team and the promo team and do what we should have done 2 years ago, we become part of the main kde releases cycle and promotion and avoid fighting for publicity. Group B is the group that wants to go fast; forking is their request and this is something we should allow. It will end the struggles. I want to suggest group B will rename the suite to something that is not confusingly similar and they probably want to host it on a server from either KoGmbh or Nokia and run it as a their project, following their rules. I think they will want to drop KPlato and all the cool plugins that would not be very useful for the commercial version. -- Thomas Zander _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel