[kde-community] Proposal One: KDE (Core) Apps and Suites

[Jos Poortvliet]

On Wednesday 30 April 2014 13:04:16 Martin Klapetek wrote:
> On Wed, Apr 30, 2014 at 10:48 AM, Jos Poortvliet 
<jospoortvliet at gmail.com>wrote:
<snip>
> > But if anybody knows a good reason to sync, say so please.
> 
> To be honest I don't see the point of my application actually joining the
> joint release...

Well, the only point would be to have some work be done for you: making the 
tarballs, little promo perhaps, translation freeze... Currently, we do 
synchronized releases for this reason, I thought. If the release team brings 
no benefit to application developers, then we can dump the synchronization of 
releases all together of course. And only have individual projects including 
Frameworks, Calligra, Amarok, Plasma (with some basic parts like 
systemsettings) and other individual apps on their own.

> You cannot define "what 95% users use" because you don't have that data.
Filemanagement, picture viewer, document viewer... Most if it is reasonably 
clear-cut. I don't think you have a lot of vague stuff there but maybe I'm 
wrong. In any case, I'd simply NOT include something that is unclear and let 
users/distributions pick what they want. It isn't like they don't do that now 
(eg have Firefox as browser, gimp as image editor).

> We
> don't know our users. We don't even know how many there are, let alone
> what they use.
True, and that is a problem. Imho we would greatly benefit from a anonymous 
usage tracking functionality like Firefox includes. We could even make it 
opt-in instead of opt-out... I bet our usability team would drool all over 
data generated by something like that.

> This is simply impossible and even dangerous, because 95%
> of the users around me don't use Nepomuk/Baloo, should it then be removed?

That's part of Frameworks or Plasma (?) anyway.

> And if not, where do we draw the line then?
> 
> On the other hand, we can define our target users; users we are writing the
> software for (just like the usability "personas"). From there we can make
> a list of things we want these target users to be able to do in the basic
> desktop + basic apps, then look into our applications set and make the
> "core" list. Note that this should not be a promo/marketing effort, but
> rather usability one.

Yeah, that is an entirely different thing. Not even remotely related to 
release management, imho. If we go there, we should also start to define and 
develop applications we don't yet have, or which need more love and 
attention, and put resources on those.

We just can't do that with our current community collaboration setup in KDE. 
Not that I don't WANT to do it, but it isn't realistic as most people work on 
what THEY think is useful, not what some group of people or committee has 
deemed useful.

Now, changing that would require* a group of individuals and (ideally) 
company(s) to commit a quantifiable amount of resources. So a plan can be 
made, and it can be executed, and you know it will happen with reasonable 
certainty. Then, perhaps, volunteers will pitch in. Or not.

I think that's great, and cool, and can give us directions and accomplish 
great things and seems a bit like what Blue Systems does (but without, afaik, 
talking much about it in public - or at least, not exactly on the dot or such 
places).

(note that this is kind of what Red Hat does in GNOME although it seems to 
come with quite a bit of social pressure against ppl who don't like what the 
Lead Designer Deity decides. I'd rather not duplicate that specific part)

But I don't think it is a great idea to let our plans for future release 
scheduling depend on the creation and execution of such a plan. It just seems 
to big to me, and you might have noticed over the last years - I'm not a fan 
of 'big plans' as they have a very strong tendency to fail and leave a mess 
behind.

* another way would be to forbid ppl to work on anything except things that 
fit The Grand Plan but I think it is clear that that is something we never 
want - and that probably wouldn't succeed in much more than killing KDE.

> Cheers