Eric S. Raymond on Keeping the Bazaar Secure and Functional

According to Eric S. Raymond, the internet is beginning to show its age and needs a little work. That includes not only the tons of "indispensable" legacy code being used by everyone from banks to online retailers, but digs deep into the infrastructure of the internet. For example, Raymond is currently involved with a project called NTPSec, which is working to make the Network Time Protocol (NTP), which is pretty much how every connected device tells time, bug free, secure, and up to 2018 standards.

"The internet is old enough now that we have service code that is in many cases pushing 20, 25-years-old," he told ITPro Today at last weekend's SouthEast Linux Fest (SELF) in Charlotte, North Carolina. "A lot was written at a time when practices were different. Some of it has security bugs now, so there's a need for people to go back and do what I call, 'code archeology,' cleaning up these huge massive old blobs."

In case you don't know, Raymond is somewhat famous in open source circles. With Bruce Perens, he's a co-founder of the Open Source Initiative, and served as the organization's president from its founding in 1998 until 2005. He's also the author of 1999's "The Cathedral and the Bazaar," which is still considered a must read for anyone interested in the open source development model. He's also no stranger to controversy, and has been criticized (and applauded -- pick your side) for his opinions on everything from the motives of women-in-tech organizations to the rhetoric of "free software" advocate Richard Stallman.

Related:Why Open Source Software is Moving to GitLab After Microsoft-GitHub Deal

At SELF he laid controversy aside to focus on the lessons he's learned from what he calls "code archaeology," which he says can benefit developers working on new projects as well as those working, as he's been doing, to fix ancient code.

"Apply code validators as much as you can," he said. "Static analysis, dynamic analysis, if you're working in Python use Pylons, because every bug you find with those tools is a bug that you're not going to have to bleed through your own eyeballs to find."

Because there's a big move these days to push non-cloud native legacy code into containers, I asked for recommendations to DevOps folks undertaking the process.

"Have it thoroughly audited by somebody that has a sense of architecture," he answered. "A lot of times these code bases turn into monstrosities because they get sort of randomly patched and hacked on by people who are thinking about this bug report or the next tiny feature, but they don't think about the over all integrity of the system because often nobody will budget for that. That's penny wise and pound foolish.

Related:Admins Aren't Patching Open Source, Says Black Duck Security Report update from May 2018

"It's a good thing when you have a legacy code base to occasionally unleash somebody on it with a decent sense of architecture and say, 'Here's some money and some time; refactor it until it's clean.' Looks like a waste of money until you run into major systemic problems later because the code base got too crufty. You want to head that off."

Raymond agreed that the later could prove to be something of a paradox, because if the refactoring is done well and no problems arise, the bean counters are left thinking they'd been talked into spending money unnecessarily.

"This is the same problem system administrators have," he said. "It's when they do their jobs right they look useless because nothing goes wrong."

Another thing devs need to think about, not only for the sake of those using their code today but for those who will be tasked with fixing bugs and security holes many years down the road, is documentation.

"Unfortunately, we don't have incentives that favor people doing that well," he said. "On my projects we tend to have good documentation because I am personally obsessive about that, but it's tough to find a project lead who's personally obsessed about the documentation. The best you can do ordinarily is hire a documentation specialist and compensate him or her properly, and make sure that documentation specialist is on the case and interacting with the developers through the entire lifetime of the project."

When I wondered aloud if bad documentation is just as much of a problem as no documentation, Raymond answered, "It's worse. At least if there's no documentation somebody might go in and read the code and figure out what's going on."

"Documentation is important," he added, "applying all the validators you can is important, paying attention to architecture, paying attention to what's clean is important, because dirty code attracts defects. Code that's difficult to read, difficult to understand, that's where the bugs are going to come out of apparent nowhere and mug you."

For a final word of advice, Raymond suggested that it might be time to consider moving away from some legacy programming languages as well.

"I've been a C programmer for 35 years and have written C++, though I don't like it very much," he said. "One of the things I think is happening right now is the dominance of that pair of languages is coming to an end. It's time to start looking beyond those languages for systems programming.

"The reason is we've reached a project scale, we've reached a typical volume of code, at which the defect rates from the kind of manual memory management that you have to do in those languages are simply unacceptable anymore. There's a new generation of languages that are slowly gaining traction, of which the two best known are Go and Rust. I think it's time for working programmers and project managers to start thinking about, how about if we not do this in C and not incur those crazy downstream error rates."

So, which of those languages does Raymond prefer?

"I personally like Go," he said. "A lot of people like Rust, but I find the entry barrier to coding in Rust pretty high, myself. There's this thing called lifetime management that you have to do, and it's actually pretty difficult. Also, the Rust people have not gotten their act together about a standard library. So at the moment, I'm putting my money on Go. However, I'm not religiously wedded to it. I think there may be other languages in that class that will turn out to be more important, but I see Go and Rust as sort of pointing the way forward."