(Looking for a better name)
Description
TL DR: Make recruiting active contributors into projects a priority and an ongoing task for the KDE Community.
The lack of new contributors to projects, even in flagship projects such as Plasma, Krita, GCompris and Kdenlive, threatens the long-term survival not only of each individual project, but of KDE itself.
In this proposal I will discuss how this problem is a major stumbling block to KDE's growth; how it will only get worse over time unless tackled head on; and finally how it can possibly be solved via a community-wide goal.
The Problem
KDE hosts many projects, most of which are small applications that, in true UNIX/Linux tradition, do one simple thing and do it well. Examples include AudioTube, Arianna, Tokodon, GhostWriter, Gwenview, Spectacle, etc.
If we take away the flyby contributions (which cannot be relied upon for continuous and stable development), these projects are often maintained by one or two people at most. According to the bus factor, this is already problematic in that it only takes one person to leave the project for development to be severely impaired or stopped.
Unfortunately, it is not only the smaller projects that are affected by the lack of a stable team of contributors. Plasma itself is only developed by between 8 and 10 people, Kdenlive by 2, GCompris by 2 and Krita by about 7. I assume the state of the development teams working on KDE's frameworks is equally bad.
In addition, many of the developers working on these long-standing flagship projects are aging, overworked and burnt out. As the adoption of KDE software increases, support alone will further increase the stress on our teams if nothing is done.
We urgently need to attract new skilled and dedicated contributors to these projects to ensure their survival, and by extension the survival of KDE itself.
What it will take
Until now, we have relied on mentoring programmes and organic word of mouth to attract new volunteers. The figures above show that these methods, as they stand, are not enough. For many long-standing projects, the number of volunteers has not increased, and in some cases has even decreased.
A more committed and multi-pronged approach is needed. Here are some ideas that could be put into practice by those working towards this goal. We could
- Leverage our current community, recruiting more aggressively over social media, through our contacts and through our KDE Network. This would have the added advantage of binding the Network nodes giving them a common goal and a clear sense of purpose.
- Create and support a permanent and stable recruitment team within KDE, with a paid contractor to manage it if necessary. This team would take on the mentoring projects, as these will be key to the recruitment effort.
I am not suggesting that the mentorship team should be absorbed by the recruitment team, but rather that the mentorship team should _become_ the recruitment team (since the main purpose of the mentorship programmes is recruitment anyway) by broadening its scope a bit and increasing its resources.
- Work with academic institutions, such as vocational schools and colleges, to try to get students to do their internships or final projects with KDE. At several events I have attended, the topic has come up organically from teachers and professors, so we have a potential untapped source of contributors there.
- Related to the above is working with companies. I have had a number of companies, mainly start-ups, ask how they can get involved in FLOSS projects. The idea of having junior developers learn the knowledge and ethos of FLOSS projects has resonated. It may be worth talking to MBition, KDAB, SUSE, Qt, etc., too. This would provide training for developers, and a pool of candidates for their own workforce.
- Change the way we approach mentoring to make it more efficient and self-sustaining. I explain how this could be done below.
Where would the resources come from to support all these new mentees?
- From a strengthened recruitment team. The mentoring team would take on the task of recruitment and would benefit from the additional support of volunteers working towards this goal. If necessary, the team could be further augmented with a contractor if this made economic sense.
- From the developers themselves. We would encourage harried developers to slow down development and spend time making it easier to bring new contributors into the fold. It's often argued that developers don't have the time to mentor and train new contributors, but why not? There are no quarterly targets to meet, no board of directors demanding more and more output. Development could slow down by 1/4 for, say, two years and KDE would not be affected in any significant way. So instead of 100 changes listed in the changelog, there are now 75, so what? This is not a big deal folks.
Also, the slowdown would only be temporary. The plan is that as more recruits are trained into the projects and become productive, development will speed up, and the recruits themselves will become mentors, freeing up the more experienced developers to do what they do best.
- From external organisations. Schools and companies would be encouraged to get involved in mentoring themselves, taking over some of the mentoring process and relieving the pressure on KDE to provide every second of the mentoring programme for every candidate.
This would have the side effect of (hopefully) encouraging companies to incorporate KDE technologies into their own products, and perhaps even get academic institutions to include KDE-based FLOSS development in their curricula.
- From increasing the number of mentees per mentor, i.e. let's mentor _groups_ rather than individuals. Not only is it more realistic (and more similar to what we do in KDE) to approach task-solving in a team of equals than as individuals, but my teaching experience has shown me that mentoring 3 or 4 mentees working together in a team is not x3 or x4 the work, quite the opposite: well-planned mentoring for a group would take advantage of peer-teaching, where members help each other.
How will we know we have succeeded?
We will know we have succeeded if we can increase the number of developers who contribute regularly to our core projects. To put a number on it, let's say our goal is to increase the number of regular contributors to Plasma, Kdenlive, GCompris, Krita and KDE Connect by 50% in the next two years.
Hopefully the project will develop its own inertia and recruiting new contributors will become just another thing the community does, like releasing new versions of our software every three months.
Projects this is built upon
This project would be like the 2018 Onboarding Goal, but more complete. While that goal focused on processing contributors once they joined the community and helping them become productive members of KDE, this goal would also (and mainly) actively implement ways to attract recruits from outside the community and build pipelines that would ensure a steady stream of potential contributors for the foreseeable future.
The mentorship programme has already started on its way to becoming more widespread by creating a dedicated website and adding new programmes such as the Chinese OSPP to the list of programmes offered. Developing the mentoring team into a full recruitment team would be the next logical step for the project.
Champions
I am willing to put work into this
I am interested
- @felixernst
- @fanzhuyifan
- @muelsyse
- @gabrielbarrantes
- add your name