Commercial Free Software projects and KDE

[Ralf Nolden]

On Mittwoch, 30. Juli 2003 16:34, Bernhard Reiter wrote:
>
> This opinion is close to being offensive against those projects.
> Being the person who has been the responsible manager
> for Ägypten and Kroupware I'm trying to give back my experiences
> to the KDE project about the process.
> You could call that an attempt of constructive criticism.

Yes, I didn't mean that in an offensive way. The thing is that those projects 
went sucessfully and they were appreciated by the project in careful ways. 
Other attempts for similar things may differ in the way they proceed - what I 
tried to communicate is that there's the needs for those commercial projects 
but that doesn't imply that there's an automatism that those projects to 
become successful have to dominate the way KDE goes.

> > KDE is way less complicated than any other piece of software when it
> > comes to requirements.
>
> Reading that sentence alone makes me laugh.
Try installing GNOME from scratch and follow their requirements in terms of 
the libs and stuff they need :-)  Compared to what you get in functionality 
and programming power the effort to get a KDE build environment up and 
running is comparably small. 

> > a) companies/externals who want to or need to be involved in the core
> > development on the absolute bleeding edge of KDE
>
> There are alternatives to just have one bleeding edge in KDE.
>
> People trying to bet on KDE and its development
> might actually start to bleed (in effort) and having
> uncalculatable risks in such project involving KDE,
> just makes projects with KDE less likely.
>
> There are projects that the KDE community
> will like and there are ones that are not desireable.
> Still it is worth thinking about how to support the projects
> that will lead to improvements for KDE.

Sure, but not the KDE way in the first place ?

>
> > As much as I think that those developments generally help KDE, there is
> > no way that as a free software programmer I freely give away control over
> > the project in technical aspects so that companies can fulfill their
> > contracts if they calculated their costs too low (or didn't communicate
> > their barriers as valuable enough that the extra effort to work with the
> > decisions of the community as a whole). It's still the project that,
> > despite any commercial inerest, decides where the train is going in the
> > technical interest of KDE's success as a development platform during the
> > HEAD development process.
>
> This is not a viable long term vision.
> Stable successful Free Software projects are maintained by professional
> about 50% in an average. So commercial interests do play an important
> role in many Free Software project, but only through the core teams.

The Cathedral and the Bazaar.  We're the Bazaar :)

> That's more than 25%. I currently estimate about additional 50% or more.
> Both points you've raised are major drawbacks for deployment
> of KDE in production environments on the cost side.
> You have to be careful to not create the message
> "KDE development is not ready for production us of the product"
> here.

No, there's two things: production environment and development codebase. Like 
others already said, HEAD != stable. If you need to fulfill a contract with 
the minimum amount of uncalculatable risks, then you need to pick a branch 
like KDE_3_1_BRANCH and work from there. Otherwise, if you need direct 
interaction in the main development thread, communicate to the customer that 
this is possible due to that you already have experience with this but at a 
higher cost than development of an add-on product for the stable release of 
KDE.

Compare this to developing a GNU/Linux version for the Itanium processor: you 
have to take emulators first because the real hardware isn't there and go 
through all uncalculatable risks; in the end it may have happened that the 
processor device never saw production and all the work was in vain. If you're 
developing inside HEAD you have to take that risk. There is no way to avoid 
that and you simply can't put your requirements for a stable environment on 
the main development tree of any project. The people who are doing this for 
fun - which is the main part of the motivation for many people - will get 
spoiled because you'll have to tell them "you do your work sometime else but 
I need to fulfill my contract first". Their idea is an evolutionary process 
of the software and not having someone with a contract that's not of those 
people's business (those who work on it for fun) to tell them how to work.

This will eventually lead to a situation where dynamic people who are 
inventing new things, going forward and break things, then fix them and do it 
right, in a very fast way, will say: wait a minute, this is not the bazaar 
style I used to know here. If this won't change, and there are others sharing 
my interest, we'll just open a new HEAD version. It's my free time I spend 
with hacking and free software anyway.

I don't want to be over-picky about my observation that you try to get some 
stability into KDE from the commercial point of view. But putting the 
responsibility for that towards the project and nagging around saying it 
needs a better code and quality management in HEAD spoils all the fun we 
have.

We *like* to break things sometimes :-)

Ralf

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

The K Desktop Environment       The KDevelop Project
http://www.kde.org              http://www.kdevelop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030730/b03a7db6/attachment.sig>