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