Sam Hartman DPL 2019 Platform

Biography

I joined Debian back in 2000. Large corporations had a lot of advantages by having enterprise infrastructure that provided centralized authentication, authorization and provisioning. By watching Project Athena at MIT, I was familiar with how valuable this infrastructure could be. I had been working on Kerberos upstream throughout my undergraduate career. I wanted to make sure the same infrastructure was available to the free software community. So, I started packaging Kerberos and related software.

Back then, cryptographic software was split into the non-us distribution because of US export law. That made my work more difficult. I packaged the software, but also had to work with other maintainers to build support for Kerberos and other infrastructure technology into more and more packages.

Ben Collins reached out to a group of people to see if we could get cryptographic software into the main archive. My contribution to that effort was on the legal side rather than the technical side. A group of friends and I spent several days going line by line through the US export regulations to prepare a set of questions for lawyers. With Bdale and HP's generous support, the answers to my questions gave us confidence in a legal path forward. Others did the technical work to allow dak to provide the necessary notifications to meet the silly regulations of the day. Eventually, we were able to move cryptographic software into main and retire the non-us distribution.

I have continued to be involved in Debian since then. Some years I'm doing little more than maintaining packages; other years Debian becomes a key focus. In my work on Project Moonshot, Debian was essential to demonstrating how a new security mechanism could be integrated into an operating system. My work on Kerberos and Project Moonshot was all free software. Sometimes my employers have focused more on proprietary work, although I've always found myself at companies that support involvement in the free software community. Over the years, free software has become more important to me, and I've found that the freeness of a solution matters more to me when I'm looking at how to solve my computing problems.

I spent a number of years as the Chief Technologist at the MIT Kerberos Consortium. In that role we worked with a number of OS vendors and other stakeholders in Kerberos to balance the needs and evolution of our community. I also served a 3 year term as a Security Area Director of the Internet Engineering Taskforce.

When I'm not working on Debian or my day job, I'm writing, reading, learning to sail, or living life to its fullest. Over the past year, I've been learning how to DJ. That ended up starting with writing my own DJ software because what's out there is too visual for a blind DJ to easily use. It's not packaged for Debian yet because I need to get one patch upstreamed and write enough documentation that someone else would have a chance to use it.

Spirituality is very important to me: I spend a lot of time writing and thinking about how we can bring more compassion, connection and love into the world. Debian feels like home because it is such a diverse community and because we view our work as a way to make the world better, not as a vehicle for an ever larger paycheck.

Keeping Debian Fun

Lucas Nussbaum wrote an excellent summary of the DPL responsibilities. Of these, I think the most important is keeping Debian fun. We want people to enjoy contributing to Debian so that they prioritize it in their busy schedules. We want to make it easy for people to do work: processes and interactions should be streamlined. When people have concerns or things don't work out, we want to listen to them and consider what they want to say. We want Debian to be welcoming of new contributors.

Debian is not fun when we face grueling, long, heated discussions. It is not fun when we are unable to move a project forward because we cannot figure out how to get our ideas considered or how to contribute effectively. Debian is not fun when processes or tools are cumbersome. When key teams break down or get stuck, Debian is not fun either for the members of those teams or for those who depend on them. Debian is not fun when it isn't safe—when we are not respected, when we are harassed, or when we (rather than our ideas) are judged. I support our Code of Conduct.

There are several ways I plan to work to keep Debian fun:

Listening: Disagreement without Escalation

I had the pleasure to serve on the Debian Technical Committee. In that role the thing I look back to with the most pride is writing an explanation of why the release team might have rejected changes to busybox-static that the maintainer viewed as important. The maintainer didn't understand the release team decision and came to the technical committee asking us to either override the decision or help explain what was going on.

The feelings matter; having our emotional needs met is a critical part of a community being fun and safe. Back in 2012, I ran across Nonviolent Communication. NVC is an empathy framework that gave me the tools to work with and understand my emotions and where they came from. It's a framework for talking about things that are important to us and reaching connection, even when we disagree. When I realize that someone has heard what I am saying, my muscles relax and my breathing slows; I feel relief and sometimes joy, often even if my preferred option is not chosen. Debian needs more of this.

My thoughts about taking care of our emotional needs have been evolving for years but are certainly influenced and inspired by Enrico Zini's notes on his Debconf 18 talk.

Debian is a community. We need to give each other the tools we need to succeed in Debian. Part of treating our community members with respect is listening to them. When you advocate someone, when you fill out an application manager report recommending that someone join our community, and when you agree to be a sponsor, you're saying that someone is valuable enough to our community that we should spend resources helping them succeed. Success in a community is emotional not just technical.

However, explaining things, especially repeatedly, especially when others are focused more on convincing us they are right than starting by understanding, is draining. One reason I pick the example of busybox-static is that I wrote it, not the release team. They were off working on a Debian release, and I was busy trying to care for a member of our community.

One of my key roles as DPL will be to make sure Debian is a community where we can be heard, and where we have the opportunity to reach understanding regardless of whether our ideas are chosen. I will do this by personally participating in such mediation and recruiting others to these mediation efforts. Eventually, I hope many of us will get better at seeking to understand and avoiding escalating discussions on our own. Since my mail about compassion and init systems, I've been working to find a place to do this work. I talked about it when I joined the TC. The TC ended up not being the right place for that work.

And yet the work continues to be important. What I wrote about a maintainer who gave up their package rather than work with the TC is just one of a long series of escalations. We are aware of people who have left because they have become frustrated. I am not worried about the turnover: Debian continues to be a vibrant community that is fun for a lot of us. If these people were leaving because their needs (or even Debian's focus) had changed, that would be fine. I hope we can do better at avoiding people stepping away from the project bitter and frustrated. I hope we can offer compassion.

The mediation work is bigger than one person can handle. It's unclear how it should be organized. What is clear is that today, the DPL is at the center of that work. The antiharassment team also has a role. I volunteered to help them out at the beginning of the year and we're working to understand how I could fit into that process independent of the DPL race. Long term, it looks like the antiharassment team, account managers, and hopefully the DPL are planning a sprint. I think working on how to organize this mediation work so that we can succeed and avoid burn-out is an important agenda item.

As DPL, mediation and bringing compassion to Debian will be one of my key focuses. I have specific ideas on how I'd like to try doing the work, so I will be personally involved. However, building a team so that we can handle more than one DPL's worth of mediation and so that future DPLs can choose their own focus is as important as the individual mediation successes.

Decisions that Take Forever

We've lost a number of developers because they were frustrated with our tools and processes. One of the common complaints I've heard is that the wide variety of Debian workflows gets in the way when you want to contribute to a large number of packages. I know that for myself I find that our processes make it difficult enough for me to go fix an RC bug in a package that I don't maintain that I'm less likely to do so.

More than just the frustration with the tools and processes is the perception that making changes is difficult. We have a lot of discussions about potential improvements, but sometimes it is hard to actually make a decision. As someone recently put it on IRC, it's hard to move forward when one person's frustration is another person's desired property of the system.

I don't think the DPL can or should decide these issues. However, as DPL I would have a number of tools to drive these discussions forward, make sure we listen to our community, and eventually make a decision. Sometimes that decision will be that we like things the way they are. Even that is valuable: it brings closure to the discussion. If we do a good job, even proponents of other approaches will feel heard. Even if they leave it will be with more empathy and respect than we sometimes have today.

I have many years of building consensus both within Debian and within organizations like the IETF. I know how to summarize where we are in a discussion, point out where we have consensus, and what issues seem to be blocking consensus.

It is valuable for the DPL to consider these issues and figure out where having a decision would be beneficial. Generally that is areas where having wider support would help empower people trying to do work and where enough of the discussion has happened that we're in a position to reach a decision. Once we've decided a decision is beneficial, the DPL has a number of tools to drive that process even if a consensus is not possible.

The DPL can refer issues to the technical committee. So can any developer, but I think the DPL can do so in a way that is less confrontational than an individual developer. “We've discussed this as much as we can as a project; I think a decision is valuable to the project; here is where we got in our discussions” seems much less confrontational than asking to override some maintainer.

I think the DPL's ability to propose general resolutions is under-utilized. I think that having the DPL propose a GR including the major options could be a much less confrontational way to bring closure to an issue than having an individual developer propose a GR and seek seconds. If the process feels a lot more like polling the project and guiding the resolution to a policy discussion, I think voting can bring things to closure.

I hope to find ways to reduce the stigma associated with bringing important issues to a wider audience. I think it will always be the case that overriding a specific decision will come with a high price. However, often when we do face a controversial decision, we realize that there are broader policy question that could be answered that would inform future decisions. Once we get some distance from the original decision, I think answering these policy questions can be valuable. Sometimes it will be useful to answer the policy questions in a forum broader than the group making the original decision. Broadening the forum like this should not be seen as a lack of trust in any of our teams or decision makers: instead, it is working together in a broad community.

Point of contact: Explaining Debian

The DPL serves an important role as a point of contact for Debian. The DPL has an opportunity to explain Debian to other organizations and to the press. The DPL has an opportunity to understand the concerns of other organizations and help get them in contact with the right parts of Debian to make forward progress.

I think this work is very important and I think I'm good at it. I've had experience building these sorts of bridges in my former role as the Chief Technologist for the MIT Kerberos consortium as well as my roles within the IETF. I haven't had this role formally within Debian, but I regularly find myself as an advocate for Debian in other professional circles.

Speaking at Conferences

The DPL traditionally has played a role in representing Debian at conferences. Over the past couple of years I actually haven't attended many computer conferences at all. If I'm elected DPL, I look forward to spending more focus on conferences than I have recently. I think this is an area where I can grow.

Even so, I may not spend as much time at conferences as some past DPLs. I think this is an area where working with a team would work well.

Supporting Free Software

The free software community balances some interesting tradeoffs. There is more free software than ever before. Linux and open source software are widely accepted. However, a number of well-funded groups are working very hard to make sure that they control exactly how much freedom their users enjoy. They are working to avoid copyleft and to use free software as a platform on which their proprietary solutions are built. Even when software is free, it often connects to non-free web services. A user's freedom would be limited by the agreements surrounding these web services and by not having control of their data.

Debian plays a critical role in this community because we are a meeting place for upstreams, downstreams, and the entire spectrum of viewpoints on what free software should be and how we should protect our users' freedom. So long as you agree to follow the DFSG and Social contract in your Debian work, you are welcome here.

I think the DPL has an important role in working in this environment. The specifics tend to differ from year to year; Debian has the opportunity to support certain initiatives or make its voice heard. I don't know what 2019 will bring but acknowledge that it will be important and something that I as a DPL will focus on.

Supporting Ongoing Efforts

The DPL needs to support ongoing efforts. In many cases this involves simply staying out of the way until the DPL's help is needed. I support the ongoing effort in all of our delegated teams.

I'd like to specifically call out the efforts of the Diversity and Outreach teams. These teams work on cultural improvements within Debian and work to bring new members into our community. Both of these longer-term efforts are important to making Debian a fun community in the future.

Finances

I will continue supporting similar policies to approving expenditures followed by the current DPL. I specifically support approving expenses for attending Debian BSPs.

I've worked with budgets as large as Debian both as a small business owner and as a manager in larger organizations. In those roles, I had more access to financial information than I expect to have as DPL. My understanding is our money is spread across multiple trusted organizations each with its own policies and procedures. As a result it is challenging for Debian to get a complete understanding of its finances.

I will exercise an appropriate level of due diligence and will support the ongoing efforts of the treasury team. However, improving Debian finances and financial accountability is not something I expect to be a key focus if elected as DPL. It is great work, but this year, I think the human factors and keeping Debian fun are more important. I am very open to working with people who do want to move forward in this area.

DPL Team

There has been a lot of talk this year about making changes to Debian governance and creating a DPL team rather than a single DPL. I think that a DPL team is a great idea, but I don't see significant changes in governance required.

I suspect that the existing publicity, treasury, and several other delegations started out as tasks that the DPL performed but that that grew to be too big for one person to handle. For some tasks formal delegation will be appropriate. For others, simply working with people will be sufficient.

I think a team could help me in the following areas:

I'm open to using teams in other areas where the job proves to be bigger than we expect.

Overall, I think Debian is a great community. The landscape surrounding operating systems is changing and evolving rapidly. People are finding new ways to use Debian and the tools and building blocks we provide. Our universality is more important than ever. We can succeed as a community by capturing, embracing and building on these efforts whether they come from our members or outside.

I'm excited about Debian. I look forward to making a great community even better. I look forward to talking to all of you as we refine and explore the plans of all the DPL candidates over the next few weeks. Thanks for your consideration.

Rebuttal

Watching the initial Discussion has been exciting. We've seen a lot of interest in improving our project. Fortunately, in a lot of ways we can choose all of the above rather than choosing just one.

I believe that I'm the best choice for DPL because I am good at building consensus, decision making, and communication. However I look forward to working with the other candidates and the project as a whole. I'd like to take this time to explore how specifically I'd like to work with the other candidates.

Jonathan Carter

If elected, I'd like to work with Jonathan to implement a number of his ideas:

Joerg Jaspert

I was really excited to learn that Joerg is interested in working on a way to replace Debian source packages with Git. I think the project should support him and provide whatever help he thinks would be beneficial in confirming that's the direction we want and implementing a solution.

I look forward to working with Joerg in all of his roles.

Martin Michlmayr

Martin brought up two interesting ideas:

I'm excited by these ideas. Martin has not yet answered my question exploring how to address concerns raised the last time similar ideas were brought up. Assuming we can come up with good answers to those issues, I am very supportive of these ideas and would approach Martin and ask if he's available to drive his ideas forward.