Commercial Free Software projects and KDE

[Bernhard Reiter]

On Wednesday 30 July 2003 12:10, Ralf Nolden wrote:
> On Mittwoch, 30. Juli 2003 10:37, Marc Mutz wrote:

> > Since I think KDE's path to success will primarily lie in the
> > applications and commercial Free Software projects such as Safari,
> > Aegypten and Kroupware, and _not_ in further improvements of the
> > (already mature) framework, I conclude for myself and anyone that is
> > willing to follow this line of reasoning, that it's about time the
> > focus shifted from making development easy for "us" (the framework
> > developers) to making it easy for the application developers.
>
> My opinion is though that I appreciate all those projects that either
> you're a developer or a whiner who wants to get easy bucks for solving easy
> bugs.

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.

Also being a Free Software person I'll certainly can distinquish
between someone who is in for the vision, the money or both.
One of my internal top goals was to work with community,
and both projects heavly did so.

Being possibly called a "whiner", if I criticise KDE 
or point out discrepancies in its own image and what external people think,
is not something that motivates me put in even more of my personal time.

> KDE is way less complicated than any other piece of software when it
> comes to requirements.

Reading that sentence alone makes me laugh.

> > It's time that KDE recognizes that it has become mature, that the wild
> > escapades of it's youth (KDE 1->KDE 2 rewrite) are more or less over
> > and that it's now time to get a decent living (stable interfaces), give
> > birth to children (innovative apps) that thrive through the great
> > foundation (kdelibs) laid by their parents. Something like that.
>
> There's two scenarios to differentiate:
>
> 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.

> 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.
Turning your argument around would mean that you could not be part
of the KDE community anymore if you don't spend your spare time
on the project, but your work time. Sounds odd to me.

> You have to face that HEAD development is harder to calculate if you don't
> include the time that you will need for recompiling newer stuff or kdelibs
> over and over to have a deskop that will become the next KDE version where
> you have to ensure that the contracted work you're doing will perfectly
> work with. Calculating for contracts in the case of a) IMHO requires an
> additional 25% maximum offset from a contract that targets b). You have to
> sell that to customers who have this extraordinary wish to have the stuff
> they need included in the next KDE version - or do the additional work for
> free because you're a free software developer for KDE at the same time who
> does things in his spare time, too.

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.

-------------- 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/c6fad9a0/attachment.bin>