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

[Aleix Pol]

On Mon, Sep 15, 2014 at 2:58 PM, Thomas Pfeiffer <thomas.pfeiffer at kde.org>
wrote:

> 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
> _______________________________________________
> kde-community mailing list
> kde-community at kde.org
> https://mail.kde.org/mailman/listinfo/kde-community
>

Hi Thomas,
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.

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.

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.
- 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.
- 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.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20140915/73a46aab/attachment.htm>