Commercial Free Software projects and KDE

Ralf Nolden nolden at
Thu Jul 31 11:01:59 BST 2003

On Donnerstag, 31. Juli 2003 11:10, Bernhard Reiter wrote:
> On Wednesday 30 July 2003 22:37, Christoph Cullmann wrote:
> > On Wednesday 30 July 2003 19:32, Bernhard Reiter wrote:
> > > > No, there's two things: production environment and development
> > > > codebase. Like others already said, HEAD != stable.
> > >
> > > As mentioned in another subthread, I don't buy into that simplicity.
> > > Especially regarding stability in HEAD as base for application
> > > development.
> >
> > Should external application developers not work with the "stable"
> > versions of kde/qt for their developement, which means atm kde 3.1.x and
> > qt 3.1.x ?
> Of course they should.
> However if could be easier for them to also help to upcoming new versions
> of the KDE applications doing so.
> Additionally I believe that my comments to stability
> also effect the KDE application development itself,
> so I don't regard it a question only interesting for external application
> developers.
> > Why is it interesting for external applications devs to work with head as
> > long as we provide that head (for the .x releases) is bc to the old stuff
> > ? (in the normal software development world you develop for existing
> > platforms, too, and not for the internal development snapshots of the os
> > companies (which would be HEAD for kde, as we haven't had any public beta
> > test phase until now), or ?)
> Time to market, would be the simple end of the answer.
> Some people want KDE to benefit from their efforts.
> Any responsible "external" group will want to keep the basis
> for their success viable and improving.
> Which would lead to the interesting question
> if that makes them internal or not.

I think it makes them internals because their requirements make it desrieable 
to work directly on the mainstream development tree. That is something that 
distributions have to live with, too, to make their final products better and 
they have a long term experience in working inside the projects with either 
hiring dedicated people from inside the existing community, so both sides 
take that benefit: project has a fulltime/parttime member who originally 
comes from the project and works in the sense of the project; company/
distributor has some chance of getting issues solved directly in CVS. Of 
course those things are often not as high targeted or more long-term 
involvements without dedicated goals that stem from contracts with an exact 

All good intention provided, I think that when commercial interests are 
becoming an importance that make it over-proportional compared to the 
project's goals and it's established ways of handling things you're going to 
piss off more people than you actually draw on your side.

I can only repeat: we're doing good stuff and we have our ways of doing so, 
because we do it for the fun of it (as one reason to do it, there are also 
others in many cases, but fun is definetly one of the highest ranking ones). 
Take the fun factor away and you'll loose a good part of the motivation of 
the volunteers.

I'll give you a precise example: Why do you think that the KDE e.V., even an 
"inside" KDE entity that consists of KDE contributors, does *explicitely* 
_NOT_ have the goal to give the KDE development any direction at _all_ ?

Reason: all other developers who are not in the KDE e.V. (yet) would feel 
ruled upon and some group of developers would, because of their membership in 
the KDE e.V., direct the way that KDE goes. KDE's only entry level is the 
ability to read, write and think. Get the code, write a patch, send it in and 
you're part of the game - and you're as valuable as anyone else for the sake 
of the whole project. Even if your first attempts break something, because 
someone else will tell you what you did wrong and help you fix it.

KDE has always been about getting the job done without anyone claiming he's 
found the stone of wisdom that has all answers to day to day problems in CVS. 
That leaves everyone the freedom (that's the other main factor besides fun) 
to participate in this project and feel as valuable as anyone else. So, from 
a sociological POV, KDE can be described as trying to materialize liberte,
egalite, fraternite in C++ code :) and even if the quality of KDE can be 
improved by enforcing it with laws, orders and rules, I would resist against 
barriers that would limit my liberte and egalite.


We're not a company, we just produce better code at less costs.
Ralf Nolden
nolden at

The K Desktop Environment       The KDevelop Project    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <>

More information about the kde-core-devel mailing list