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

[Thomas Pfeiffer]

Hi everyone,
this is a topic that has been going around my head for quite some now, and now 
I finally decided to actually try and get the ball rolling on it:

I think we are quite good at "eating our own dog food" when it comes to 
desktop software: Most KDE contributors use Plasma as our desktop environment, 
many (most?) developers use KDevelop and/or Kate for development, many use 
Kontact for our PIM needs, KTp or Kopte for IM, etc.

Where we don't use many of our own products, though, is on the infrastructure 
side. Which strikes me as quite odd, given that I know of at least two 
projects that have originated within KDE and have become quite successful 
_outside of KDE_ by now, but are not used by us: Kolab and ownCloud.
Both serve needs that are of course present in KDE, too, as in any other 
organization: Communication/coordination and file hosting/sharing.

There has been much talk about making KDE more "professional" and more 
efficient, and centralized management of communication, coordination of 
appointments and addresses and also hosting and sharing of documents is 
something that most "professional" organizations (and certainly all of our 
size) do, so it would most probably be helpful for KDE, too.

Imagine we would not have to look up a KDE contributor's email address from an 
email they sent to a mailing list if we want to contact them, but instead just 
go to our central address book and type in their name. Or instead of relying 
on Doodle to coordinate meetings, we could send out invitations via our own 
Kolab system!

Regarding file hosting/sharing, developers might ask themselves "Why do we 
need file hosting? We have git for all our assets!", but it's not that easy. 
Git is awesome for hosting code and other plain text assets (like HTML or 
LaTeX source files, for example). What it's not good at is conveniently 
uploading, browsing and downloading working non-plaintext documents, like 
images (which is what visual and interaction designers mostly work with), 
presentations and similar things. I'm not talking about assets which are 
directly used within our software, those should probably still be hosted in 
git to work seamlessly with our deployment process. What I'm talking about are 
e.g. mockups, which are never released with software, but used by designers 
and developers to communicate during the design process. Yes, all that can be 
done with git, too, but
1) Git has quite a steep learning curve for non-developers
2) I've seen SVN being used for hosting binary format documents in a company, 
and it was quite a pain.

A third product which was born within KDE and which could be really useful for 
us is Bodega. We all know that kde-look.org and kde-apps.org are far from 
state of the art at this point. Their websites look really outdated and are 
not very usable, and desktop integration via Get Hot New Stuff has quite a few 
problems, too: For example, often download links in kde-look/kde-apps do not 
point to a file in the format expected by GHNS for that type of asset, making 
it impossible to install it directly via GHNS.

Bodega, on the other hand, was created precisely with our requirements in 
mind: It supports the whole process from creation of an asset to installing it 
on a device running Plasma (and also rating and discussing it, even 
payment/donation to the creator if wanted) very well, and is flexible enough 
to incorporate anything from wallpapers to full desktop applications.

I would not like to discuss the three specific products I mentioned directly 
in this thread, because that could make it confusing quickly. Here I just 
wanted to present the general idea of pushing our use of our "own" server-side 
products within KDE. If there is general agreement that we should work on 
this, I'd start a new thread for in-depth discussion of each product (and of 
course any others which I haven't thought of yet).

There have been attempts to task the KDE e.V. board with getting the 
aforementioned products established in the KDE infrastructure, but with all 
the crucial strategic things the board has to do, there simply isn't the time 
to do such operative work, so we have to do it ourselves.

So, what do you think?

Best,
Thomas