Introduction

I am running for DPL with a singular goal. The creation of Debian US and EU Foundations. I largely view my candidacy as a referendum on this goal and its details.

Operationally, I would reconstitute the DPL-Helpers team to assist the DPL.

Rationale

The rationale for these changes is to enable Debian to move faster on issues, such as financial, legal and trademark issues. The DPL should have the option of delegating some administrative duties so that they can concentrate on setting the direction of the project, representing the project, and getting buy-in from the members to move important issues forward. IE: Debian Project Leaders should have more time to lead rather than be buried in the set of administrative tasks they currently face, and history has shown that volunteers alone aren’t enough.

Why can’t we do this all with volunteers, like we do everything else? Although for many technical tasks, it’s fairly easy to do the work as part of our paid day jobs, or as part of other technical roles, we might have because the skills required are many times a natural fit for technologists, for other non-technical tasks, like accounting, lawyering and such, it’s very difficult to find enough people to volunteer to do these things, who are able to give them priority. At the very least, the qualified pool of volunteers that are interested in these issues, but are also technologists who are interested in Debian, is much smaller than for technical or creative tasks.

Why create our own orgs when we have existing ones? We’ve had mixed results over the years working through TOs (Trusted Organizations) that aren’t Debian-focused. It’s no secret that SPI is Debian’s most Trusted TO. It’s also fairly well-known that the service quality provided by SPI to Debian has varied greatly over the years.

Currently, SPI’s service levels have improved greatly, due to their own use of paid help, but there was a time when the service they provided was bad enough that it was hard to justify maintaining the special relationship. Note, this was largely due to limited volunteer cycles, and a wide-ranging mandate, to support many projects.

The biggest challenge of late is that SPI has had a philosophical change. SPI has indicated that they no longer believe that Debian, which was SPI’s founding member project, is their most important project, and all projects must be treated equally.

Some ways that this is manifesting are, 1) the DPL is no longer a special member of SPI invited to all meetings, 2) without informing us, after 10 years of de facto practice, SPI stopped waiving their standard 5% fees on DebConf sponsorship payments, this has cost Debian approx. 16,000 USD since the unannounced change became effective 3) SPI would like to close the Debian Paypal account, for the simple reason that they can’t give all member projects their own Paypal accounts. (Another large SPI member project, PostgreSQL, has their own foundations to deal with these issues.)

In addition, our historically preferred European Trusted Org, FFIS, has become non-functional for all intents and purposes, to the point we now ask people not to donate through FFIS, and have removed them from the list of current Trusted Organizations.

Overview

When establishing these foundations, I would start with Debian US, as I am based in the US (New York City). The Foundation's board would be elected by the Debian Project Members, and the DPL would automatically be a full member of the Foundation's board. (Initially a temporary board may be assembled by DPL to bootstrap.) Board members must be Debian Project Members but otherwise should have no geographic restrictions.

Once the Foundation is operational, an early goal would be for the Foundation to hire a part-time administrator (20 hours per week) who would take direction from the DPL and the board and would be available to assist the DPL, and Debian's various bureaucratic teams, including but not limited to DPL-helpers, Treasurer,  and Trademark.

Another goal would be to establish a Debian Europe. France and Switzerland would be at the top of the list of jurisdictions in which to base a foundation, as we have strong TOs there. I would coordinate with both and see if they might want to evolve their organizations into a Europe-wide entity or assist in founding a new one.

Over time, I would expect these two entities to become our primary Trusted Organizations in the US and Europe, but don't expect to end relationships with our current TOs, SPI, Debian France, and Debian.ch.

Some similar entities to look at would be FreeBSD Foundation, the United States PostgreSQL Association, and PostgreSQL Europe.

If you share my goal to establish these entities, please feel encouraged to reach out and let me know, and indicate if you are able to help.

Commitments made during the campaigning period

I will perform the following duties that would be expected of any DPL.

In addition, I commit to the following course of action regarding the Foundations:

In addition, I have the following non-Foundation related goals and plans.:

About me

I've been involved in free and open source communities for almost 15 years, a Debian Project Member for almost 7 years, and have been leading NYLUG (New York Linux Users Group) for over 10 years. I first became involved in Debian in 2008, as one of the first bid team members of what was to become DebConf10. I've been involved in the Treasurer, Trademark and DPL-helpers teams as well. I have done fundraising for Debian and Debconf over the years and helped Debian get a Paypal account through SPI. I expect to have at least 10-15 hours a week to work on DPL-related tasks. I estimate it will take 6-12 months to create the US entity.

Rebuttals

Jonathan Carter

I'd like to congratulate Jonathan for running for DPL again as it's less common than it should be.

Membership nomenclature:

I don’t believe we should refuse to use the term Debian Developer anymore because someone hijacked it to falsely represent themselves.

As a member of the minority of Debian Developers that joined the Project for contributions unrelated to packaging, when I initially joined the project, I had a strong preference for the term Debian Project Member. However, I came to realize my initial reluctance to use Debian Developer was a manifestation of "Imposter Syndrome", and have grown to use the terms interchangeably, depending on the audience I am addressing. Rarely do I use the term non-uploading Debian Developer, but have, when it's needed for clarity. My choice largely depends on what will be the most understood or useful in context.

I was a little dishearted to hear that Jonathan chose to delay his Project Membership to pursue full uploading rights. I don't fault Jonathan for this, as I've seen other people express this preference before, but it seems a sign of a bigger issue, and makes me wonder if today there is a stigma to being a non-uploading Debian Developer, at least by those pursuing membership.

My ideal long-term future for Debian would be one where the vast majority of Developers only had upload rights to the packages they maintain, as I do not believe that 1000 people all need upload rights to 60,000 packages, and think these rights should be granted very selectively, and only as needed to Developers that have project-wide responsibilities. For example, to active members of Debian Security.

Ideally such rights would be aligned with rights in salsa. It doesn't make much sense that you can upload a package where you cannot edit the source and you can edit the source of a package (e.g. the Debian group = collab-maint) but not upload it at least to delayed queue.

I understand that such a change would be impractical today, and we are very far from achieving a consensus, so it's NOT something I an actively pursuing, but more of a seed for thought, and suspect to get there we’d have to have it be a change we phase in over a long period of time.

Clearly we have work here as a project, but I don't think it's going to be resolved by a GR to stop calling ourselves Debian Developers. I'd prefer to continue to leave that choice to individual Developers and work with DAM and Webmaster teams to make sure the process and documentation for application strongly decouple membership and project-wide uploading rights. (Currently it treats non-uploading status as an anomaly/exception, which may be contributing to the perception.)

Sruthi Chandran

I'd like to congratulate Sruthi for running. Although I have no issues with Sruthi's expressed high-level goals, I would very much like to see specifics in order to fully evaluate them. Sruthi is leading DebConf 22 preparations. Even though this is over two years away, there is a lot of preparatory work, and much of it is deadline-driven. Also, it's generally expected that bid teams for future DebConfs are heavily involved in organizing the ones that happen earlier. I would personally encourage Sruthi to run for DPL after DebConf 22, as that would no longer be competing for her time, and would also give her more experience working in the Debian project.