Commercial Free Software projects and KDE

[Bernhard Reiter]

On Wednesday 30 July 2003 18:36, Ralf Nolden wrote:
> 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.

You started the question of domination, so far I haven't seen doubts
about that the KDE community is staying on top of things.
Arguments coming from non-KDE groups are not aimed
at dominating KDE in principle, it might just be good or bad arguments.
In any way they are useful to have as feedback.

Additionally the perception of KDE and the needs of various 
external groups using KDE is an important source. 
Your style of argumentation does not encourage people 
to talk about those things.

> > 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 ?

Any "way" gets refined over time
and people understand different things under the same name.

Later in your email you only talk about "fun".
Some other KDE developers might be in here for other reasons.
Maybe having the goal to 
build a generally accepted modern desktop environment 
which is easy to use. 

This would bring us back to the question what die KDE project wants
and if there is a common vision or goal.

If the common vision of KDE is 
to only have "fun" and "break stuff sometimes"
then this is a message the coorporate users will hear.
It certainly would go against the goals of some KDE participants
as I far as I know.


> > > 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 :)

The 50% mostly use the Bazaar style,
so I don't understand your comment.

> > 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. 

As mentioned in another subthread, I don't buy into that simplicity.
Especially regarding stability in HEAD as base for application development.

> 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.

This mechanism, 
which you know is quite known to me,
is a high barrier to 
bring in more people that work on KDE in payed time.

What if there would be a KDE way to lower that barrier?
I'd say its worth looking for.

> 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.

I'm not sure that all KDE developer are in only for the fun.
That would be very unusual compared to the average
of Free Software projects.

Anyway there might be ways to keep the motivation up
and improve the process regarding disadvantages for commercial usage.

> 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.

If too many developer thought like this it would be a problem,
but you draw that picture as if it was necessarily black and white.
The current KDE practice also drove developers out of KDE
and continues to drive others away. 
I'll share that observation of Cornelius.

> 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.

I'm not "nagging" around,
at an average I get beaten a lot because I'm interested to 
make KDE a better experience by voicing my opinion.

> We *like* to break things sometimes :-)

I can see the headline: 
"KDE -- the desktop that `breaks` things sometimes"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030730/9a091f45/attachment.bin>