Boudhayan.tex

\chapterwithauthor{Boudhayan Gupta}{Deals with the Devil}

\authorbio{Some would say his childhood was misspent, but when you a put a computer, a CD with a Linux distribution, and the permission to do anything one pleases with the two in front of a 13-year old boy, there's only one way it can end. After acquiring ninja Linux skills, picking up a couple of programming languages, and enrolling for an undergraduate course in Computer Science and Engineering, Boudhayan Gupta broke into the KDE Community in early 2015, eager to help in the ongoing effort to port software to KDE Frameworks 5. Today, he maintains KDE's screenshot utility, is a system administrator, and a member of KDE e.V.. In the very rare few moments when he's not studying or devoting time to KDE, he can be seen trying to learn as many languages and read as many books as he possibly can.}

\noindent{}It is the middle of autumn, almost exactly nineteen years to the day KDE was born. An e-mail has just been posted to the community mailing list. The e-mail is barely 20 lines long, and contains a very simple suggestion. Over the course of two months, this thread will grow to over two hundred e-mails, split itself into multiple threads across three mailing lists, with nearly a hundred people participating, putting on clear public display the passion the people have for not just what KDE builds, but what the community stands for. This debate and the resulting action will lay down precedent for services the community will offer to its members in the future. This is the story of what happened, and how it changed our community for the better.

\section*{Free Software Isn't Just About Freedom}
Free software is about freedom; that is what the free stands for. Free software isn't gratis software, it's libre software. But free software isn't as much about freedom as it is about control, and making sure that that control remains with the widest possible populace. Free software abhors any action whose possible consequences include loss of control over the software by any member who currently has it. In the context of free software, we can define freedom in terms of the control the users of the software has over how they use it, with whom they share it, and how they change it.
The KDE Community recognizes that simply making sure users have control over how the software is used, modified and shared isn't enough to guarantee a healthy ecosystem fostering the development and use of free software. Like the users, contributors must also be guaranteed certain freedoms, defined in terms of control over how they contribute to the project. The contributors dictate how they want to develop the software; the kind of tooling they want to use, the kind of workflows they want to maintain, and the ways in which they communicate, among others. To guarantee these freedoms to the developers, the community must do everything in their power to ensure control over our infrastructure ultimately remains in the hands of the contributors.

\section*{The KDE System Administrators}
The KDE System Administrators (whom we really should call Infrastructure Engineers, since that describes their role more accurately) are responsible for maintaining the infrastructure that supports the activities of the community. This extends to beyond supporting the development of software. A considerable chunk of the infrastructure exists to provide spaces for people to collaborate on tasks of any sort, be it administrative, financial, or related to development. The KDE System Administrators exist to meet the technical needs of the community.
To ensure that it does always meet the needs of the community, the system administrators need to ensure that they never find themselves in a position where they are unable to provide what the community requires, because services provided by other providers which the community relies on do not let us do things we need to do. This is why we host our own source code management servers instead of relying on one of the large proprietary hosted services. We simply cannot let other service providers dictate what we are allowed to do with our infrastructure.
This example is pertinent because of the subject matter of the aforementioned email thread. The email thread was a request from an active developer asking for the presence of KDE’s code repositories on GitHub.

\section*{KDE on GitHub}
It was clear from the very beginning that hosting our repositories on GitHub and having all our activity take place there would not be tenable, because of the loss of control over our infrastructure that would entail. Among other things, we wouldn't be able to ensure:
\begin{enumerate}
 \item The availability of code hosting and code review services, as if GitHub decides to change their services, for technical or financial reasons, and their services are no longer in line with our technical or financial requirements, we would find ourselves without a place to publicly host our code, and coordinate our development activities.
 \item The integrity of the code repositories, since a breach in their security would allow code in the repositories to be altered. While our own infrastructure is also susceptible to such a problem, if such an incident happens on our own infrastructure, the accountability is shared by the community and getting recourse is infinitely easier. Our response to such an incident would be tailored to our needs, which cannot be guaranteed for a hosted service.
\end{enumerate}
At the same time, the code being present on GitHub has distinct practical advantages. Some of the more important ones include:
\begin{enumerate}
 \item Code visibility. A vast number of people who are just beginning their journeys in the world of open source software are simply not aware that open source code exists outside of GitHub, thanks to the brilliant publicity and ubiquity GitHub has achieved. Having code available on GitHub would ensure the code will be discoverable by such people.
 \item Developers’ credibility. A lot of employers simply look at a person's GitHub profile to find a prospective employee's publicly available code, and evaluate their suitability for the job. Having KDE's code on GitHub, with the commits made by a developer showing up in their profile would make a vast amount of code available for these prospective employers to peruse, as well as display the developer's ability to cooperate with other developers and contribute to a shared codebase.
 \item An offsite hot spare. If KDE's infrastructure were ever to go down, having our code on GitHub would ensure that the code would continue to remain accessible while we work to bring our services back online. Also, since it is possible to clone a repository from GitHub and push new commits to our infrastructure, this would lessen some of the load on our systems.
\end{enumerate}

Eventually, a solution was found. GitHub has a feature wherein organizations are able to host mirrors of their own self-hosted Git repositories on GitHub, which we would make use of. These mirrors can be made read-only, and all extra features of GitHub (such as the wiki, the bug tracker, etc) can be disabled for these repositories. All the KDE System Administrators would need to do is to push new commits from our master Git server to GitHub, in addition to our own read-only mirror network.
It took us a month since the first e-mail\footnote{\url{https://mail.kde.org/pipermail/kde-community/2015q3/001507.html}} was sent to decide to have the mirror set up, but the actual work was conducted over a 36 hour period between September 16 to September 18, 2015. First, we realized that the URL github.com/kde was already in use by a user who had no activity, and therefore our first task was to liaise with GitHub and get the organization assigned to us\footnote{\url{https://mail.kde.org/pipermail/kde-community/2015q3/001704.html}}. Then I got to work cooking up the scripts that would push the repositories we wanted to our new shiny GitHub organization. On September 17th, I finished up that work and handed the scripts over to the Git infrastructure maintainer. As I went to sleep in India, he woke up in New Zealand, reviewed the scripts and added them to those we already ran when new commits were pushed to our master server. On the 18th, we were able to announce to the world that KDE was now present on GitHub\footnote{\url{https://mail.kde.org/pipermail/kde-community/2015q3/001717.html}}.
The discussions on the mailing lists continued, and we reached a few ideological conclusions regarding how we would engage with proprietary hosted services outside our control. We concluded that for practical reasons we could never shut them out, but that we should never rely on these services to fulfill our core requirements. Additionally, we concluded that we should always work towards bringing people on these hosted services to our own infrastructure.

\section*{KDE on Telegram}
The KDE Community has always relied on IRC (Internet Relay Chat) to provide online chat rooms where people can get together and discuss development. IRC has developed a subculture, and people hang out in IRC channels to meet new people, socialize online and discuss as much off-topic content as on-topic content. IRC has a special place in the hearts of seasoned people in the open source world.
It is interesting to note that with all the care that we take to retain control over every bit of our infrastructure, we don't actually host our IRC services ourselves, instead delegating it to Freenode, a community run by people with strong ideological ties to the free software culture, many of whom are also associated with the KDE Community. It is one of the very few cases where we can trust an external provider to host services for us.
During the preparations for our annual mentoring program in 2016, we realized that there was an entirely disjoint set of people who were active participants in the KDE Community, but had never ever used our IRC services, and were therefore invisible to the people who regularly used IRC to keep in touch with their friends in the community.
Part of a generation of people never exposed to the wonders of IRC, instead, these people used Telegram, a service that provides encrypted one-on-one and group messaging services. Telegram has apps on mobile phones, all major desktop operating systems (including GNU/Linux), and a very functional website to fall back to if all else fails. Unlike IRC, which uses its own ports (which may be blocked at workplaces and universities) and requires dedicated clients, Telegram simply works over encrypted HTTP, over standard HTTP ports, and simply requires a web browser to function. Telegram allows the transfer of images and files, has native support for emoticons and “stickers”, and works on the go with their lightweight mobile apps. There is only one problem with Telegram: it is run by a for-profit entity whose interests may not always be in line with KDE's.
While we could never officially endorse the use of Telegram, with the precedent set by having our repositories hosted on GitHub, we could extend our support to people using the service. Telegram users also being active participants in the KDE Community, we owe it to them to make it feasible for them to participate in discussions happening on the IRC channels. We also owe it to our IRC users to be able to join discussions happening on Telegram.
The solution to this was simple. We used one of our servers to run a bot. This bot would read messages from an IRC channel and post the same messages on the Telegram group. It would also read messages from the Telegram group and post them on the IRC channel. This way, Telegram users keep themselves abreast of the conversation happening on IRC, and IRC people get to participate in the discussion happening on Telegram. Everyone is happy.

\section*{A Happy Ending}
In some countries, KDE is still not old enough to be of legal drinking age. Over its 20 years of existence, the community has learned lessons, and incorporated these lessons into their way of conducting their activities. There were important lessons learned from these two experiences.
Firstly, with a community this large, there is always going to be a difference of opinion, and some of these opinions may be incompatible with each other. Pleasing everyone is impossible, but there is always a compromise to be found for people who are willing to find it.
Secondly, shutting users of proprietary systems and services out is never an option. Trying to find a solution that would enable such users to use our services and participate in our community is the only responsible thing to do.
Finally, KDE is as much a sociopolitical movement as it is a group of technical geniuses building great software, and it shows. KDE is what it is because of the people; people who have poured their heart and soul into the community and the software, and who voluntarily take ownership of the community's positions and actions, products and activities. The political and social stands the community takes on issues is its identity, and forms the basis for commanding the respect it deserves.
KDE is now 20 years old, and the community is primed to make itself grow for 20 more years, and then 20 more after that. If there is anything we can be sure of, it is that experiences like this will continue to happen, and such stories will continue to be written.