[kde-community] Using software created by KDE and KDE-related communities/companies for KDE infrastructure

[Thomas Pfeiffer]

On Monday 15 September 2014 16:24:55 Aleix Pol wrote:
> Hi Thomas,

Hi Aleix,

> First of all, I'd like to say I mostly agree with you. I would add a bit of
> a twist though, I think we must ensure the services we rely on are free and
> open as possible, they don't need to be our own (or in a tier2 kind of,
> like owncloud or kollab) but we must ensure we keep true to making it
> possible to be able to deliver a KDE development experience based on free
> software.

True. I'd propose the following priorities for software procurement:
1. Viability. It needs to get the job done. A Free but useless software won't 
help us, unless the reasons why it's not useful for us are easy enough for us 
to fix.
2. Feasibility. If it's something we don't have the capacity to host or which 
costs significant amounts of of money to use, it's out
3. Freedom. If there is a proprietary and a free tool that are both viable and 
feasible, of course the free one wins, even if some people like the 
proprietary one more
4. In-house: If there is a KDE product and a third-party one that both satisfy 
requirements 1-3, we should prefer our own so we can identify and fix its 
potential issues.

> To get some perspective, one recent event I'm really happy about is
> Kanboard. We could have all dived into using Trello, but we found a good
> alternative we could use and host and we leveraged on it. Everyone is using
> it now and we're even starting to scratch the small itches we found, so
> we'll end up improving it, most likely.

Yes, I'm very happy about that switch, too!
 
> As for the specific cases you proposed, I concur that they are great but we
> should really see what they can offer:
> - Kollab: This was already discussed recently in this list, it doesn't seem
> feasible to offer a Kollab instance to the membership (let alone the whole
> community) so I don't think we want to depend on it. That said, We might
> want to ensure we have all the tools to use the standards we can rely on,
> then ensure Kollab is capable to interact with them, given it's one of the
> few platforms we could have a say.

Given that Kolab will power the whole of Munich administration soon, I wonder 
why it wouldn't work for the - big, but still tiny compared to that - KDE 
community, but I am not an admin (I really should establish the IANAA and 
IANAD acronyms), so I may totally miss the difference. Would it require 
massive server or bandwidth resources which we don't have?

> - ownCloud: It could be useful. I seldom share actual files, we have an
> owncloud instance in KDE Spain server and we don't use it. Maybe it's that
> it overlaps with etherpad to some extent, or that we haven't learned what
> it can offer.

There could be several reasons for that. For example
- You don't use many non-plaintext documents (I can say that the visual design 
and usability groups use a lot of them!)
- People are so used to working with other tools (like e.g. wstaw for images) 
that they don't switch easily.

I can just tell from my experience in the VDG that having all of our mockups 
spread over a dozen different image and file hosting services and only tied 
together by links spread all over the forum isn't a good situation.
Often when someone asks me for a certain asset, I have to say "Sorry, no idea, 
try to find it in the forum". Not what we'd like to have.

> - Bodega: +1, it should happen soon. I'd say there's some rough edges to
> polish on the client side, as we don't really have all the infrastructure
> needed so that it shines, but I'm confident it will happen sooner rather
> than later.

Well, it won't happen by itself ;) If someone is working on this, then yes, it 
will happen sooner or later. If nobody is working on it or will start doing 
so, soon, I don't see it happening.