KDE's rough edges... what are your experiences?

Kevin Krammer krammer at kde.org
Sun Oct 27 20:23:05 GMT 2013


On Sunday, 2013-10-27, 16:47:08, Duncan wrote:

> FWIW, my thinking on this is that it just happens that the kde devs (and
> in particular the plasma devs, since that's the desktop kde uses) have a
> particularly bad case of one of the traits very common to free and open
> source application development and the developers behind them -- the
> "developer scratches his own itch and stops when it stops itching for
> him" phenomenon.

I don't think so. Most applications have way more features than what the 
respective handful of developers would be using themselves.
What is most likely true though is that those features which are not used by 
the developers themselves need to receive active and continuous testing by 
other contributors lest they easily break.

> Those commercial/proprietary model proponents do have a point, that IS a
> weakness of FLOSS

I think the problem with this statement is mixing terms for orthogonal 
properties into one.
A commercial product is something that is monetarized, a proprietary product 
is something that only one entity has source access to, a FLOSS product is 
something that is also available in source to anyone.

Since some of those labels are for orthogonal concepts, they can appear in 
different combinations.

E.g. a FLOSS product is not necessarily developed by a community of 
individuals, nor is it necessarily non-commerical.
A proprietary product is also not necessarily commercial, etc.

Proprietary software vendors often get a free pass at stabs at FLOSS software 
because they managed to make people think of certain combinations as opposite 
sides.

Lets take for example a commercial, single-vendor product. Whether the code is 
proprietary or FLOSS licensed does not change its commercial status, does not 
change the development model, etc.
If the vendor is responsive enough to implement new features and fix bugs 
there migth not even be a pratical difference from user point of view.
However, should the vendor not be responsive enough, then a FLOSS license 
would make the vendor one of several options for change.

This enabling of users to take their business elsewhere is why proprietary 
vendors try their best to fold all kinds of unrelated aspects into the FLOSS 
moniker, so people don't see that they can't get this advantage from the 
proprietary vendor but can get all other advantages from a non-proprietary 
one.

This subterfuge is slowly breaking down though, as more and more categories of 
users see the bigger picture, see how different aspects affect different 
properties of the software they are using.

I think it is important that we as users of FLOSS software understand and 
communicate how the different influences work together.

For example for KDE products, the available features and/or development 
direction is most strongly influenced by the volunteer community driven 
development aspect, a bit by the non-commercial aspect and negligibly by the 
licensing aspect [1].

Other things are more influences by the non-commercial aspect, e.g. 
availability of services.

And again other things, like customizability, are most strongly influenced by 
the licensing aspect, i.e. the license enabling others to provide tailoring.

Cheers,
Kevin

[1] licensing obviously influences the amount of volunteers but it has only 
little direct impact on feature availability

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20131027/b27e3446/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.


More information about the kde mailing list