Johnny Jazeix on KDE Blogs

GSoC: differences of expectations between students and organizations

Johnny Jazeix — Wed, 28 Jan 2026 00:00:00 +0000

I've been administering KDE's participation in the Google Summer of Code program for the last few years (and mentoring on some). This post is just some personal thoughts on the differences between what the KDE organization expects and what usually the applicants want (I'm not in everybody heads, it's assumptions from my experience). I don't provide any solution (because I don't have any) and there is no judgment (both point of views are valid), just a personal point of view.

Applicants point of view

GSoC is a individual competitive program which can be a huge boost to start a career. There are usually two major reasons for the applicants to participate in GSoC:

the money.
the experience and the line in the CV for real life work.

There is, for a lot of applicants, no genuine interest in the projects (at least at the beginning, the first interaction is often "I want to start contributing to KDE and prepare for GSoC"), and they mostly want a GSoC slot. Small digression, on one of my projects, two people already asked to contribute and if we were doing GSoC, but after telling them that contributions are welcomed and we will only propose a topic if we feel enough confidence that the contributor would stay after, they told us they preferred to choose another project.

Contributors consider GSoC as an end of their studies, not a project they want to contribute after: there is also a change of life to consider between university life and work life and a balance to achieve when starting the latter (which could be in a different town/country) which may be a reason for the drop of interest.

Organization point of view

GSoC is an opportunity to welcome new contributors to our community. The organization usually expects from GSoC:

contributors willing to contribute regularly to their projects.
implementation (partial or total) of the proposed ideas.
having a positive return on investment (is the time spent mentoring worth the result?)

GSoC is mostly a step to have contributors learning about the projects, and contribute in the long-term. Long-term is purposely vague; what we expected for the GCompris project was the contributor would contribute at least one year and mentor for the next GSoC (so a loop was present, and applicants would also gain an experience on mentoring, while giving some relief to the other experienced mentors) but it can vary depending on the project.

For the return on investment, mentors do not consider it good having spent more than three months mentoring for projects they could have done in less time they spent to mentor the contributor. Helping someone grow is always personally rewarding but we still hope this person will also show us the results of the teaching by improving our projects in the future.

Impacts of the differences

There is a huge difference on the expectations. What can we do to reach a common ground where everyone is happy?

Organizations cannot force anyone to contribute after the GSoC end.
If money is the main motivation to stay, most organizations will not have money to hire applicants to work after (and do we want to hire someone only motivated by money? No, it's not OSS values, we love passion).
Find ways to create a real interest for the organization. In KDE, we have the chance to have tons of projects with different topics (astronomy, education, digital painting, video editing, scientific plotting, games, desktop environment, system administration, internationalization, ...) where it is easy to participate to other projects from time to time and learn new things if we are curious enough.
Be stricter on the entry point for organizations: explicitly say in the beginning that we expect a long-term relationship not just the equivalent of an internship. It should reduce the number of applicants and only keep the ones with a genuine interest (if applicants are honest of course).
Organizations/Mentors could reduce their objectives of GSoC and consider that contributors are here to produce and spend less time on training/mentoring, expecting contributors already know the basics, but this would totally spoil the nature of the program.

Another track is to find the projects where contributors stay / don't stay and understand the difference. Most of the big KDE applications don't manage to keep their contributors, while smaller ones do. Maybe as a contributor, it's because it's more difficult to take decisions, feel included/listened on large projects because they have a high maturity level/long-term contributors and a well-defined vision? Whereas on smaller projects, there are fewer constraints from the existing environment and it feels more rewarding and motivating to contribute there?

To conclude, here are the statistics for KDE retention the last years:

Year	Started	Completed	Active after 1 year	Active after 2 years	Active after 3 years
2018	20	17	5	5	4
2019	24	22	9	8	8
2020	21	19	2	2	1
2021	16	15	8	6	3
2022	7	6	5	1	0
2023	9	7	3	3	2
2024	10	10	4	2	-
2025	15	12	6	-	-

That is, an average of 15 people sign up each year, of which

an average of 90% finish
44% continued contributing 1 year later
28% continued contributing 2 years later
22% continued contributing 3 years later

We would of course love having more contributors staying at least one year but it's almost half and a quarter that stay active for a few years!

Restoration of docs.kde.org

Johnny Jazeix — Sun, 18 Jan 2026 00:00:00 +0000

Edit 25/01/2026 documentation.yml is no more used, the documentation is built and published as part of the linux.yml and linux-qt6.yml pipelines. The post is updated to take this in account.

For the past few years, generation of user documentation at docs.kde.org was not working. After a few months on working on the related issue, we finally managed to make it functional again and it once again displays the documentation for almost 150 applications!

Previous issues

There were major issues with the previous workflow:

The documentation generation and publication were done on a dedicated machine.
It was a monolithic process: the generation of the documentation for all KDE projects was followed with the generation of the website and its publication.
Since the arrival of Qt 6, it was not possible to easily update the process to take it into account, so no new documentation was generated.

For ease of maintenance, it would be better if:

Each application took care of generating its own documentation
The website generation only cared about retrieving the existing documentation and building the website
We could have an easy way to reproduce it locally

Current solution

Update suse-qt610 image

We use the suse-qt610 docker image to generate the documentation. The different packages needed to build the html/PDF files and generate the website have been installed.

Generation of the documentation

We have created a new script generate-documentation.py that will generate the documentation and publish the documentation for a project to a specific registry. To ensure the documentation is well-generated, developers need to ensure that their project has:

'frameworks/kdoctools': '@latest-kf6' listed in its .kde-ci.yml
kdoctools_install(po) in its CMakeLists.txt

Local generation

To generate locally, you can use the following commands. First retrieve and run the latest image:

podman pull invent-registry.kde.org/sysadmin/ci-images/suse-qt610:latest
podman run --user=root -it suse-qt610:latest

Inside it, clone your repository (the example will use GCompris-teachers handbook):

cd builds
git clone https://invent.kde.org/documentation/gcompris-teachers-handbook
cd gcompris-teachers-handbook

Clone the needed repositories and export the environment variables:

git clone https://invent.kde.org/websites/docs-kde-org.git docs-kde-org --depth=1
git clone https://invent.kde.org/sysadmin/ci-utilities.git --depth=1
git clone https://invent.kde.org/sysadmin/repo-metadata.git ci-utilities/repo-metadata/ --depth=1

export KDECI_GITLAB_SERVER=https://invent.kde.org/
export KDECI_PACKAGE_PROJECT=teams/ci-artifacts/suse-qt6.10
export KDECI_CACHE_PATH=/home/user/caches/
export CI_COMMIT_REF_NAME=master
export CI_PROJECT_NAME=gcompris-teachers-handbook
export CI_JOB_ID="job_id"
export DBLATEX_BASE_DIR=$PWD/docs-kde-org
export SGML_CATALOG_FILES=$PWD/_install/share/kf6/kdoctools/customization/catalog.xml

Note: we only need the docs-kde-org repository because of PDF generation. There is some work in progress to reduce this dependency.

Retrieve the dependencies and build the documentation:

python3 -u ci-utilities/run-ci-build.py --project $CI_PROJECT_NAME --branch $CI_COMMIT_REF_NAME --platform Linux/Qt6/Shared
python3 ci-utilities/generate-documentation.py --project $CI_PROJECT_NAME --output-folder webdoc --format html pdf --branch $CI_COMMIT_REF_NAME --doc-dir _staging/builds/gcompris-teachers-handbook/_install/share/doc/HTML/

The output will be in the webdoc folder. You can copy this to your machine using podman cp CONTAINERID:/builds/gcompris-teachers-handbook/webdoc/ . (use podman ps to get the CONTAINERID).

Website generation

Now that each project generates its own documentation, we have reworked the existing website scripts to use these files instead of generating all of them again.

The script will browse all the projects in KDE which have i18n branches in their metadata and fetch the corresponding documentation (if it exists).

The last step is to generate the indexes for the website's search feature, using Xapian.

Local website generation

To generate locally, you can use the following commands. First retrieve and run the latest image:

podman pull invent-registry.kde.org/sysadmin/ci-images/suse-qt610:latest
podman run --user=root -it suse-qt610:latest

Inside it, clone the needed repositories and create the needed logs folder:

cd builds
git clone https://invent.kde.org/websites/docs-kde-org.git
cd docs-kde-org
git clone https://invent.kde.org/sysadmin/ci-utilities.git --depth=1
git clone https://invent.kde.org/sysadmin/repo-metadata.git ci-utilities/repo-metadata/ --depth=1

You will also need to generate a gitlab token from your invent account. Make sure the read_api scope is selected!

export KDECI_GITLAB_SERVER=https://invent.kde.org/
export KDECI_GITLAB_TOKEN=generated_token
export KDECI_PACKAGE_PROJECT=teams/ci-artifacts/suse-qt6.10
export KDECI_CACHE_PATH=/home/user/caches/
export PYTHONPATH=$PWD/ci-utilities/
export CI_COMMIT_REF_NAME=master
export CI_PROJECT_NAME=docs-kde-org

Generate the website, copy static files and run the xapian indexing:

mkdir -p logs
./kdedocgen.py -r -s -l doclogconfig.ini -c docgen_conf.ini
./create_generated_used.php work >website/generated_used.inc.php 2>logs/genused.log
KDECI_PACKAGE_PROJECT=teams/ci-artifacts/suse-qt5.15 python3 -u ci-utilities/run-ci-build.py --project $CI_PROJECT_NAME --branch $CI_COMMIT_REF_NAME --platform Linux/Qt5/Shared --only-setup-environment
KDECI_PACKAGE_PROJECT=teams/ci-artifacts/suse-qt6.10 python3 -u ci-utilities/run-ci-build.py --project $CI_PROJECT_NAME --branch $CI_COMMIT_REF_NAME --platform Linux/Qt6/Shared --only-setup-environment
cp -R _install/share/doc/HTML/en/kdoctools5-common website/trunk_kf5/en/
cp -R _install/share/doc/HTML/en/kdoctools6-common website/trunk_kf6/en/
cp -R search/ website/
./website/search/do_xapian_index.sh

The output will be in the website folder.

Website deployment

The website repository has its own scheduled pipeline (once a week) to generate the website and publish it.

The deployment is done using the ci-notary service.

Future plans

There are still multiple issues to tackle:

Most non-ASCII languages (CJK, Arabic...) are not supported for PDF generation. We have two contributors in Season of KDE who will dig into finding a solution to improve this!
We have several hardcoded paths/links to Qt 6/KF 6. We need to drop those for when Qt 7/KF 7 comes (edit 25/01/2026: this has been handled in this commit!).
Updating deprecated documentation where it makes sense.