[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KOffice split
From:       Thomas Zander <zander () kde ! org>
Date:       2010-10-26 21:38:04
Message-ID: 201010262338.04269.zander () kde ! org
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic