Sam Hartman: "The DPL job looks like it's going to be a lot of work, but not as insane as coming up to speed as an IETF area director."

The new leader of the Debian GNU/Linux project says one thing that is holding back the project is the length of time it takes to take decisions, with developers often getting frustrated with the tools and processes that are used.

"Debian is great for experimenting with lots of ways of doing things. We aren't always great at consolidating on the solution that ended up working best when we're done with those experiments," Sam Hartman, who was elected as leader for a one-year term on 20 April, told iTWire during an interview.

Hartman, who was born blind, has been with the project for nearly 20 years, and credits his wife with having given him the necessary motivation to run for the post of leader. "Her encouragement to go do what I believe in and run for DPL gave me the final confirmation that this investment in Debian was worth it for me," he said.

A computer science graduate from MIT in 1999, Hartman has handled complex technical roles for a long time. Asked about his use of Linux, he said it seemed as though he had always been using Debian. "It was a great Linux back in 1996 when my laptop became powerful enough that I could give up DOS," he said. "That was also around the time that Linux accessibility reached a point where I could depend on console applications talking."

Hartman said in 1999 and 2000, he and Mark Eichin — one of the security researchers whothe Internet Worm — were hoping to bring enterprise infrastructure similar to what they had seen through MIT's Project Athena and other efforts to the free software world.

"Naturally, Debian was our platform of choice," he said. "So I gobbled up the Developer's Reference and new Maintainer's guide and decided to tackle some nice small package. So how about MIT Kerberos? In all fairness, I had been working on Kerberos throughout my undergraduate career, so I was familiar with it. It was perhaps an ambitious start as a developer."

Hartman later worked as the chief technologist at the MIT Kerberos Consortium and got involved in the Internet Engineering Taskforce, the standards body that produces the RFCs. He served a three-year term as a security area director on the IESG.

"That job was crazy: every two weeks you had to read and comment on the security implications of every RFC proposed for approval," Hartman said. "At the beginning, I'd read RFCs and then follow up references trying to understand all the technologies that made up the Internet until I couldn't take it any more.

"Then I'd read mindless fiction until I could manage to get to sleep and like as not dream about aliens disrupting Internet routing convergence on an MPLS data plane. The DPL job looks like it's going to be a lot of work, but not as insane as coming up to speed as an IETF area director."

Hartman set up a consulting company after he left the IETF. "There, Debian continued to be important. We were working on Project Moonshot, a project lead by JISC in the UK to re-imagine federated authentication," he explained. "We needed to explore how our new authentication system would fit into a real operating system. Debian was our test platform. It had great tools for building derivatives. That got us started, but as our technology matured we were able to contribute it to the main distribution."

[The Moonshot wiki is supposed to be here; they recently sent out an announcement that their site would be down for a few days while they were fixing security problems in Confluence.]

Currently, Hartman maintains Kerberos and the Moonshot software in Debian. "I served a term on the Debian Technical Committee," he said. "Early in my Debian career I came up with the legal hack that allowed us to work around US export law and integrate cryptographic software into the main archive.

"The US wanted a detailed notification for every program that included cryptography. That was logistically challenging. So I asked the lawyers if we could notify the us that a particular program might contain cryptography. They said that would be fine and there would be no problem for over notification. So, we notified the US government for every package in Debian."

He works as a developer at a small start-up. "We sell collaborative spaces based on Debian. Four years ago, if you told me I'd be working as a key developer on a product that is all user interface — we ship rooms full of TVs as primary deliverables — I'd have said you were crazy. But that's what I do. Our company is just getting to a size where we're contemplating contributing what we can back to the community and Debian."

Outside his work Hartman says he teaches and explores love and connection in a neo-pagan tradition. "That spiritual work and Debian are the communities that are really important in my life," he added.

Hartman was interviewed by email. Detailed replies to some other queries are below.

iTWire: I take it that you were born blind; correct me if I err. How much has this been a handicap to your involvement with software? To what extent has it been a plus?

Sam Hartman: Correct. Whenever the world changes enough that I'm starting to worry about whether I'll be able to continue to use the latest computers, T.V. Raman goes and fixes things. He wrote the accessibility software that let me ditch DOS for Linux back in the 1990s; I still use it today. Whenever PDFs were becoming ubiquitous enough that I couldn't escape them I learned he was at Adobe working on accessibility software. And then when having a flip phone without text interfaces that I could really use was becoming unworkable, Google is coming out with accessibility for Android and there he is. He and the Debian accessibility team are my heroes.

But really in this field it doesn't get in the way too much. While Phoronix users were arguing that a blind developer couldn't care about graphics, I was busy using my GNOME laptop to debug a QT crash in a video app as we migrate our software to Buster at work.

I think being blind helps in one significant way. I can't rely on visual notes and had to spend a lot of my formative years in school relying almost exclusively on my memory. I learned a lot of tricks to make that work. The biggest was understanding how systems work well enough to split them into parts. It turns out that is the primary skill for computer security and network protocol work.

If you'd like to say something about your partner and kids, if any...

I didn't make it to Debconf last year because I was getting married. I did bring a bit of Debian to the wedding though and wore my Debian kilt (picture on the right).

I'm excited to be bringing my wife to her first Debian conference in Brazil this July. Her encouragement to go do what I believe in and run for DPL gave me the final confirmation that this investment in Debian was worth it for me.

You mentioned in your platform that you wanted to retain the fun element as far as involvement in Debian goes. To what extent does a code of conduct contribute to making something fun?

Like traffic signs and speed limits, codes of conducts themselves aren't fun, even though they are important. What is fun is spending almost 20 years in a community that cares about me and my contributions. What's fun is seeing members of the community grow in technical and social skill.

I was looking back at debian-vote discussions from 2006. We've come along way in respecting each other since then. Yet we can still disagree; we still express strong opinions.

We've got the code of conduct. We've made our commitment to respecting each other and inclusion. We're working on figuring out how to do that in a way that acknowledges that improving communication is an ongoing process and that social as well as technical evolution is essential to our success. We're never going to give up expressing those strong opinions or having passion for what we do. But we can add a healthy dose of compassion to the mix.

If you can highlight one thing that is holding Debian back, what would that be?

Decisions take a long time. Increasingly developers are frustrated with some of our tools and processes. Debian is great for experimenting with lots of ways of doing things. We aren't always great at consolidating on the solution that ended up working best when we're done with those experiments.

And, on the other side, what is the greatest strength of the project, the one thing that has kept it going through the years?

Our maintainers and their creativity keep us going. Shortly after the voting started someone announced a tool they had been working on that addressed one of the pain points (making the same change to a lot of packages) brought up in the election cycle. Individual maintainers can try new things. Often they catch on. That's a huge strength.

Debian is now a very mature platform. What directions do you think the project should take now to continue to keep itself relevant and a source of strength to upcoming projects that need guidance?

We should improve our workflows to make it easier and more efficient to contribute. I think Debian has a lot of value to provide as a base for application containers and can gain a lot from application containers like Flatpak and Snap. I hope we do that.

Debian is important even if lots of applications come from language-specific repositories. We provide base dependencies and provide a common interface when people care about stability and consistency more than the latest version. Where we add value, we should help people understand what that is. We should avoid getting in the way where we don't have something to offer.

Do you see any future for Debian as an operating system for other devices – tablets, for example?

That situation continues to improve. As an example you can run a Debian container on Chrome OS. I look forward to what's coming next.

Pulling together the efforts of more than a thousand developers, all (or most) of them opinionated, has been likened in the past to herding an unruly group of cats. How do you see it? Since nobody can obviously gain the support of everyone, what kind of split of opinion will satisfy you with regard to any initiative?

I come from the IETF so rough consensus and running code is dear to my heart. A lot of thought was put into RFC 7282; it has great advice on how much discussion you need. Generally, you need to understand the arguments and consider them. Repeating past that point probably doesn't help.

Debian is not the IETF though. We'll face situations where we cannot wait for rough consensus or where it's not worth the cost of that much discussion.

I think the DPL can get a good feel for whether more discussion is helpful. What I hope to bring to the process is guiding the discussions to an end when more rounds of repetition will not improve our result or offer more compassion.

Are you happy with the one-year term for a DPL or do you think that longer terms might be more productive in terms of getting changes implemented?

There's no way I would have run for a two-year term. It might well make sense to run for a second term if I'm being successful and enjoying the position. The job is emotionally involved enough that both the project and a DPL need a chance to evaluate whether things are working out. I do think that having DPLs stand for two years is valuable, but we have not had trouble re-electing DPLs when that made sense.

This question is not directly related to Debian, but more to your involvement with Kerberos. In recent years, there has been a push to create legislation so that backdoors can be placed in encryption software. The FBI-Apple case is one example; a second is from Australia, where a law was passed last year to make it possible to bypass encryption. What do you think of this trend? Does the end justify the means? Or will this push — Britain was first to pass a law known as the Snoopers Charter — be to the detriment of computer users at large?

When I started working on security software back in 1995, we were in the middle of the Clipper Chip and the US's first dance with key escrow and backdoors. Just as predicted there were bugs in Clipper.

Criminals by definition are not overly concerned with following the law. They will always be able to get crypto without back doors. If necessary, they can double encrypt so that even the government cannot tell unless it actually uses its backdoor.

I was not around for RFC 1984 and RFC 2804, but the arguments there still apply today. I was in the IETF plenary room when we decided to change the Internet to fight back against government spying. TLS 1.3 and the strong security of WebRTC are part of the response to that. I think that a more secure Internet, rather than legally mandated backdoors that the criminals will ignore, is more my style of security.

Anything else you would like to add?

Several voters hoped that the good ideas discussed during the campaign process would not be lost. Just after I reached out to thank the previous DPL for his work, I reached out to the other candidates. Jonathan [Carter] and I are starting with his idea for community meetings, but that's only a start. Unfortunately Martin [Michlmayr] doesn't have time to pursue most of his ideas, although we'll be coordinating mid-May to see what's possible. I am excited to be working with Joerg in all his roles.