<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 15, 2014 at 2:58 PM, Thomas Pfeiffer <span dir="ltr"><<a href="mailto:thomas.pfeiffer@kde.org" target="_blank">thomas.pfeiffer@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
this is a topic that has been going around my head for quite some now, and now<br>
I finally decided to actually try and get the ball rolling on it:<br>
<br>
I think we are quite good at "eating our own dog food" when it comes to<br>
desktop software: Most KDE contributors use Plasma as our desktop environment,<br>
many (most?) developers use KDevelop and/or Kate for development, many use<br>
Kontact for our PIM needs, KTp or Kopte for IM, etc.<br>
<br>
Where we don't use many of our own products, though, is on the infrastructure<br>
side. Which strikes me as quite odd, given that I know of at least two<br>
projects that have originated within KDE and have become quite successful<br>
_outside of KDE_ by now, but are not used by us: Kolab and ownCloud.<br>
Both serve needs that are of course present in KDE, too, as in any other<br>
organization: Communication/coordination and file hosting/sharing.<br>
<br>
There has been much talk about making KDE more "professional" and more<br>
efficient, and centralized management of communication, coordination of<br>
appointments and addresses and also hosting and sharing of documents is<br>
something that most "professional" organizations (and certainly all of our<br>
size) do, so it would most probably be helpful for KDE, too.<br>
<br>
Imagine we would not have to look up a KDE contributor's email address from an<br>
email they sent to a mailing list if we want to contact them, but instead just<br>
go to our central address book and type in their name. Or instead of relying<br>
on Doodle to coordinate meetings, we could send out invitations via our own<br>
Kolab system!<br>
<br>
Regarding file hosting/sharing, developers might ask themselves "Why do we<br>
need file hosting? We have git for all our assets!", but it's not that easy.<br>
Git is awesome for hosting code and other plain text assets (like HTML or<br>
LaTeX source files, for example). What it's not good at is conveniently<br>
uploading, browsing and downloading working non-plaintext documents, like<br>
images (which is what visual and interaction designers mostly work with),<br>
presentations and similar things. I'm not talking about assets which are<br>
directly used within our software, those should probably still be hosted in<br>
git to work seamlessly with our deployment process. What I'm talking about are<br>
e.g. mockups, which are never released with software, but used by designers<br>
and developers to communicate during the design process. Yes, all that can be<br>
done with git, too, but<br>
1) Git has quite a steep learning curve for non-developers<br>
2) I've seen SVN being used for hosting binary format documents in a company,<br>
and it was quite a pain.<br>
<br>
A third product which was born within KDE and which could be really useful for<br>
us is Bodega. We all know that <a href="http://kde-look.org" target="_blank">kde-look.org</a> and <a href="http://kde-apps.org" target="_blank">kde-apps.org</a> are far from<br>
state of the art at this point. Their websites look really outdated and are<br>
not very usable, and desktop integration via Get Hot New Stuff has quite a few<br>
problems, too: For example, often download links in kde-look/kde-apps do not<br>
point to a file in the format expected by GHNS for that type of asset, making<br>
it impossible to install it directly via GHNS.<br>
<br>
Bodega, on the other hand, was created precisely with our requirements in<br>
mind: It supports the whole process from creation of an asset to installing it<br>
on a device running Plasma (and also rating and discussing it, even<br>
payment/donation to the creator if wanted) very well, and is flexible enough<br>
to incorporate anything from wallpapers to full desktop applications.<br>
<br>
I would not like to discuss the three specific products I mentioned directly<br>
in this thread, because that could make it confusing quickly. Here I just<br>
wanted to present the general idea of pushing our use of our "own" server-side<br>
products within KDE. If there is general agreement that we should work on<br>
this, I'd start a new thread for in-depth discussion of each product (and of<br>
course any others which I haven't thought of yet).<br>
<br>
There have been attempts to task the KDE e.V. board with getting the<br>
aforementioned products established in the KDE infrastructure, but with all<br>
the crucial strategic things the board has to do, there simply isn't the time<br>
to do such operative work, so we have to do it ourselves.<br>
<br>
So, what do you think?<br>
<br>
Best,<br>
Thomas<br>
_______________________________________________<br>
kde-community mailing list<br>
<a href="mailto:kde-community@kde.org">kde-community@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-community" target="_blank">https://mail.kde.org/mailman/listinfo/kde-community</a><br>
</blockquote></div><br></div><div class="gmail_extra">Hi Thomas,</div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">As for the specific cases you proposed, I concur that they are great but we should really see what they can offer:</div><div class="gmail_extra">- 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.</div><div class="gmail_extra">- 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.</div><div class="gmail_extra">- 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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Aleix</div></div>