Attract existing FLOSS software projects to KDE and incorporate their members into our community
Open, NormalPublic

Description

We would want to increase the number of projects working within KDE. This task aims to lay out which existing projects we should approach to try and convince them to join our community. This would help us increase our portfolio and app catalogue, making our platform more attractive to users (= a larger catalogue of apps to install and use) and contributors (= a larger variety of projects to chose to work on). The community would grow with members of already active projects, thus increasing our reach with every project added. One would expect it would make KDE more attractive to a wider variety of sponsors.

The projects that joined us would be able to increase number of contributors (developers, artists, translators) working on their product, increasing the bus factor. They would be able to take advantage of KDE's infrastructure and services (like Promo), while at the same time increasing the probability of obtaining sponsorship and funding. Finally they would be working with like-minded colleagues.

We will approach the main developers of the project, preferably through a common acquaintance, and pitch our offer. To ensure we can accommodate the project, we will work with the onboarding project (T7116) members so we are ready to accept mature projects into the fold.

Wishlist:

@paulb 's personal wishlist:

Avoid

Projects that overlap in functionality and/or aim of working projects already within the KDE community.

TODO

Add you ideas, comments or suggestions for projects to contact (and preferably a way to contact them) in the comments below.

paulb created this task.Nov 14 2018, 1:13 PM
paulb triaged this task as Normal priority.
afarid added a subscriber: afarid.Nov 14 2018, 2:15 PM

Here is my wishlist as well:

Although I don't know how realistic these proposals are. Probably the most feasible is Hydrogen but it doesn't hurt to try the rest.

paulb added a comment.Nov 14 2018, 3:36 PM

Although I don't know how realistic these proposals are. Probably the most feasible is Hydrogen but it doesn't hurt to try the rest.

It is okay to forget realism for the moment. We'll look at each project individually later.

ognarb added a subscriber: ognarb.EditedNov 18 2018, 4:35 PM

My wishlist is

Although I don't know how realistic these proposals are. Probably the most feasible is Hydrogen but it doesn't hurt to try the rest.

It is okay to forget realism for the moment. We'll look at each project individually later.

When and how do you plan to start this? Maybe we can prepare things for 19.04?

When and how do you plan to start this? Maybe we can prepare things for 19.04?

This process has nothing to do with including the programs in a specific bundle (like Applications 19.04). Most of the applications recently incubated started releasing on their own schedule.

apol added a subscriber: apol.Nov 19 2018, 1:52 AM

This process is called incubation, you can see how it works here: https://community.kde.org/Incubator

Lutris? I don't think this will ever gonna happen. It is a gtk+ application and their next major release (0.5.0) is going to use GtkHeaderBar 🙄

My wishlist:

In T10034#168055, @apol wrote:

This process is called incubation, you can see how it works here: https://community.kde.org/Incubator

But how do you approach a project? Is it someone from the board, form promo, any one? Is there a procedure for this?

afarid added a comment.EditedNov 22 2018, 7:14 PM

Another project which is interesting is FreeCad. It is still Qt4 but if the community can help porting it to Qt5 that can be a bonus to make it join KDE.

Lutris? I don't think this will ever gonna happen. It is a gtk+ application and their next major release (0.5.0) is going to use GtkHeaderBar 🙄

Oh, that is a shame. It would've been SO COOL to have Lutris.

My wishlist:

Clementine is my player of choice but there are too many audio players already imho.

In T10034#168055, @apol wrote:

This process is called incubation, you can see how it works here: https://community.kde.org/Incubator

But how do you approach a project? Is it someone from the board, form promo, any one? Is there a procedure for this?

Anyone can start the process. No special procedure: get in contact, show them the benefits and the process itself, as described on those pages.

Another project which is interesting is FreeCad. It is still Qt4 but if the community can help porting it to Qt5 that can be a bonus to make it join KDE.

FreeCad is already moving to Qt5; Debian for example enabled the Qt5 build.

paulb added a comment.Nov 22 2018, 7:56 PM

Clementine is my player of choice

I like it too.

but there are too many audio players already imho.

Yes, it would conflict at least with VVAVE and Elisa. That puts it in the "not a priority" box.

FreeCad is already moving to Qt5; Debian for example enabled the Qt5 build.

Now that is interesting.

paulb added a comment.Nov 25 2018, 6:29 PM

I'm going to tentatively add Natron to the list. According to this article, the two remaining developers have a lot of trouble in advancing the project. The program uses C++ and Qt, albeit older version of both, but they want to push conversion to more modern versions, which would mean converting to Qt5. To me it looks like a prime candidate for being "rescued".

paulb updated the task description. (Show Details)Nov 25 2018, 6:29 PM
richardbowen added a subscriber: richardbowen.EditedNov 25 2018, 8:56 PM

I think that's a good idea, pulling in projects that would benefit from the help of the KDE community. I came across one as well: https://github.com/rochus-keller/CrossLine. No idea if the developer want's assistance but the project is based on Qt4. Maybe he would be interested in porting to Qt5.

I think that's a good idea, pulling in projects that would benefit from the help of the KDE community. I came across one as well: https://github.com/rochus-keller/CrossLine. No idea if the developer want's assistance but the project is based on Qt4. Maybe he would be interested in porting to Qt5.

+1

That is an interesting looking project indeed.

An other small project, that I would love to add to the list: KtikZ. This project already use some KF5 libraries and is still often updated.

From a user point of view, KiCad could benefit from a KDE user interface. It’s a well known and probably great EDA tool, but every time I try to get started, the bad UI stops me. (But that’s common for almost all EDA tools I know.) (Yes, it’s UI could also be great with wxWidgets, which it uses currently.)

From other points of view, KiCad developers luckily continue improving KiCad, but they don’t seem to have problems with the UI.

Thanks for the suggestions, @davidhurka and @ognarb. These are both look very interesting and we will include them into the list of projects to approach.

rooty added a subscriber: rooty.Jan 17 2019, 10:28 PM

Hey if in any way possible: **medInria**
It's an up and coming medical imaging platform.

ixoos added a subscriber: ixoos.Jan 18 2019, 7:44 PM

What about https://gitlab.com/carlavilla/Qtemu/? Gnome has it's "own" Gnome Boxes, Qtemu was ported to qt5 not too long ago, and now the dev, polishes it.

paulb updated the task description. (Show Details)Jan 21 2019, 10:04 AM

I wouldn't worry too much about avoiding projects which overlap with existing KDE projects for aims, there's plenty of those within KDE already. Unrelated technologies are a bigger issue (I'm thinking of Thunderbird as being unsuitable when in the past it was looking for a new home, but it uses very different technologies.)

My reasoning is I wouldn't want to hurt projects that may be long-standing within KDE by bringing in a similar project that may absorb resources they need. In an ideal world, people would try and merge two similar projects with similar aims and underlying technologies, like... I don't know... Kontact and Kube. But that doesn't seem to happen and often all it leads to is a rift. If there are already overlaps which cause discomfort within the KDE community, don't you think drafting projects from outside can create more problems? If we were considering approaching a project and contributors to an existing KDE project had reasonable reservations because the new project may cause a rift with the KDE one, shouldn't the opinion of the KDE contributors prevail?

I honestly don't know the answer to these questions, so any insight will be helpful to me.

lydia added a subscriber: lydia.Tue, Jan 22, 6:10 PM

My reasoning is I wouldn't want to hurt projects that may be long-standing within KDE by bringing in a similar project that may absorb resources they need. In an ideal world, people would try and merge two similar projects with similar aims and underlying technologies, like... I don't know... Kontact and Kube. But that doesn't seem to happen and often all it leads to is a rift. If there are already overlaps which cause discomfort within the KDE community, don't you think drafting projects from outside can create more problems? If we were considering approaching a project and contributors to an existing KDE project had reasonable reservations because the new project may cause a rift with the KDE one, shouldn't the opinion of the KDE contributors prevail?

I honestly don't know the answer to these questions, so any insight will be helpful to me.

You are correct. If we spend resources on recruiting new projects let's spend them on areas that we don't already cover of possible.

GB_2 added a comment.Tue, Jan 22, 6:12 PM

The Calamares installer also seems like something we could adopt: https://calamares.io

afarid added a comment.EditedTue, Jan 22, 11:39 PM

Here is my wishlist as well:

Continuing along the kreative suite line here are 3 more:

In T10034#174271, @GB_2 wrote:

The Calamares installer also seems like something we could adopt: https://calamares.io

There seems to be already KDE people involved so it seems interesting [[ https://calamares.io/team/ | [1] ]][[ https://calamares.io/about/ | [2] ]]. Although it makes me wonder why they haven't pushed for such a thing? Maybe a reason can be to stay "neutral"?

adridg added a subscriber: adridg.Thu, Jan 24, 10:50 AM

With my Calamares maintainer hat on: the decision to live outside of the KDE umbrella was taken before my time, but is basically this: make sure that the installer is seen as a desktop- and sitro-neutral approach, even when it uses KDE technologies. It's an installer for a whole bunch of distro flavors, although it's also enthusiastically used by a bunch of KDE-showcase distro's. I don't want it tied to only the KDE-showcases though.

So it's not going to move, for the foreseeable future.

That said, here's a little checklist of what I would consider, before moving a project under the KDE umbrella:

  • Website. https://calamares.io/ is served from GitHub pages. Existing workflow is through Markdown pages which I can locally test with Jekyll. Forwarding requests to a KDE-thing serving websites should preserve the domain name. (A transition period, to eventually en up with calamares.kde.org or kde.org/applications/calamares, would be acceptable).
  • Wiki. Needs an application-specific wiki. I suppose community.kde.org/applications/ would house a sub-tree, and while I much prefer the Markdown-based GH approach, I can understand that c.k.o uses MediaWiki.
  • Translations. Existing translation work in Calamares is done through Transifex. So there would need to be capacity in the KDE translation teams to handle the extra workload (507 strings and growing, in 59 languages). There needs to be import from .ts to the form KDE translations use. In the hope of attracting some of the external translators, a web-based translation workflow is probably necessary.
  • CI. Currently uses Travis. This is straightforward to move over to b.k.o, although workflow does depend on email notifications of build failure and IRC-notifications of build results. Calamares is Linux-only, needs to have a way to limit CI builds to that.
  • Bugs. Needs a simple way to report bugs that supports templates and visible screenshots in the text. Most bugs are reported by distro-packagers, so the BR capabilities are pretty good, but it's an important time-saver for me to see screenies in-context. The actual bug workflow isn't all that important to me: there's "open" and there's "closed" and I don't use GH labels all that much -- this is probably because it's a relatively small project.
  • Issues: Calamares doesn't have a forum or mailing list, so communication happens on IRC (for transient synchronous bits) or GH issues (for non-transient, async). This includes brainstorming about new features and discussions about bugs. Needs notifications with content.
  • Pull Requests. Features do come in from downstream. And having some kind of formal review in place is necessary. Wouldn't have to be in a forked repo, necessarily. With the KDE git setup and manifesto saying that everyone can commit everywhere, this would be a social problem to be solved more than anything else.

So from a developer point of view it doesn't really matter to me: I have git, qgit, a shell, and KDevelop and that's it. Moving an existing loosely-knit community (downstream, plus translators) is a different thing.

From a user point of view, KiCad could benefit from a KDE user interface. […]

I just found this roadmap for the next major release: http://docs.kicad-pcb.org/doxygen/v6_road_map.html

Somewhere it really smells like Qt, so using KDE Frameworks could help much:

Give KiCad a more modern user interface with dockable tool bars and windows. Create perspectives to allow users to arrange dockable windows as they prefer.
[…]

  • Take advantage of the advanced UI features in wxAui such as detaching and hiding.

Maybe the VDG can help here:

  • Study ergonomics of various commercial/proprietary PCB applications (when in doubt about any particular UI solution, check how it has been done in a certain proprietary app that is very popular among OSHW folks and do exactly opposite).
  • Clean up menu structure. Menus must allow access to all features of the program in a clear and logical way. Currently some functions of Pcbnew are accessible only through tool bars
  • Redesign dialogs, make sure they are following same style rules.
  • Check quality of translations. Either fix or remove bad quality translations.

Most Qt-y:

  • Develop a global shortcut manager that allows the user assign arbitrary shortcuts for any tool or action.

IMHO they still need configuration dialogs which really configure anything useful. (And sorry for failing at markup.)

Adding a new project for this "Kreative suite"

And annotating Rosegarden (https://rosegardenmusic.com/) so @jriddell and @tcanabrava said in TG promo group that they attempt to attract it to KDE before (and @dfaure is a good contributor for the project.

In other sector, I think that Free software world need a great engineering tools "user friendly" so I give "+1" to attract Freecad project like said @afarid.

filipf added a subscriber: filipf.Mon, Feb 18, 8:15 PM

I'd propose PulseEffects (https://github.com/wwmm/pulseeffects)

Why?

  • already a fantastic program
  • one of a kind, the program has no (serious) competitors
  • written in C++
  • only one developer more or less, could use KDE's help with things like design, translation etc. and with being more widely shipped
  • developer is super-friendly

The issue is that the interface is GTK right now, but I still think it's worth exploring this collaboration.