“The OpenSSL Foundation has some very devoted people,” says Matthew Green, an assistant research professor at Johns Hopkins University and an outspoken critic of OpenSSL. “It just doesn't have enough of them, and it can't afford enough of them.”

The talent pool from which the foundation can draw is shallow to begin with. As Chet Wisniewski, a senior adviser at Sophos Security, explains it: “You need someone who's both a programmer and a cryptographer, which narrows the field down to a very small number.”

The fact that OpenSSL pays next to nothing constrains things further. Those who do help Henson out often juggle coding with full-time paying jobs elsewhere. Others can’t code for OpenSSL: Their employment contracts prohibit it, so they simply act as advisers. That leaves Henson responsible for 60% of the code commits (or sets of changes to the source code), twice as many as the next-most-prolific developer, Andy Polyakov, who's compensated some. Most of the code added in the past few years has been approved by Henson, or tapped out on his own keyboard.

The come-and-go, casual nature of the group means that hierarchies aren’t formalized. Marquess can’t say exactly how many people help out with its development at any one time, but directs me to a list on the foundation’s website naming seven active contributors. He points out that until April 23 the list was out of date — and included at least one person who is deceased.

As a result, OpenSSL's code is a slurry of cobbled-together snippets that work — but only just. It's strewn with developers’ comments to one another, sandwiched between slashes. Some of them are aesthetic, like, “BIG UGLY WARNING! This is so damn ugly I wanna puke ... ARGH! ARGH! ARGH! Let's get rid of this macro package. Please?” Some are outright petrifying, like the comment that reads, “EEK! Experimental code starts." They’re unflinchingly honest, yes, but they give an insight into the chaotic nature of the code that makes the program.

“OpenSSL’s code isn’t clear," says Kenny Paterson, a professor of information security at Royal Holloway, University of London, who's been working in cryptography research since 2000. "It’s a rat’s nest, full of stuff that’s been outmoded."

This stems in part from how its current funding structure affects its priorities: For now, OpenSSL’s development lives and dies by the OSF’s commercial income, almost all of which comes from putting in new features, rather than maintaining the old. The current setup means, Steve Marquess readily admits, that “the fundamentals of OpenSSL are being neglected. No one is hiring us to maintain the current code base.”

And of course mistakes can happen. When they do, there currently isn’t the money to pay a person, never mind a team, to go through the 456,332 lines of source code with a fine-tooth comb to find them.

There are plenty of people looking at the OpenSSL code, including professor Paterson, whose Information Security Group (ISG) at Royal Holloway is incentivized by the University of London to conduct research into OpenSSL and to spot bugs. But Paterson points out that there are significantly fewer people writing the code within the OpenSSL project than those on the outside looking in, scanning it for weaknesses — and the former are adding more stuff in, not taking stuff out and cleaning up the contradictions contained within the code base. The cruft of code has tripled in size from late 1998 and early 1999 when SSLeay became OpenSSL; on average 1,575 new lines of code have been added each month for the past 15 years.

Some 90,000 such lines of extraneous code have been removed in a week by the coders of LibreSSL, a renegade offshoot of OpenSSL, without affecting the way it runs. In among the confusing maze of OpenSSL code it was bound to be difficult to discover a simple mistake like Heartbleed.

“You and I can look at that code all day long and we're not going to find the Heartbleed flaw,” says Sophos Security’s Wisniewski. "These teams are very small and barely funded." (One concern is that big government does have the money, may have found the exploit, and could have kept quiet about what it knew.)

Marquess was well aware of the situation OpenSSL faced when, last December, he pulled his Subaru truck into the parking lot of the Woodstock Inn, a biker bar situated alongside Route 125 in Woodstock, Md., that advertises itself as the home of good food, good music, good friends, and good times.

The man Marquess was meeting, Matthew Green, the Johns Hopkins professor and critic of OpenSSL, was hardly a good friend. The tunes played in the bar weren’t all that great. As for good times, in the daytime lull when the two men met, the bar was pretty much deserted. And for what it’s worth, Green wasn’t that impressed with his $10 burger, either.

Marquess and Green’s meeting coincided with an allegation that the U.S. government had tampered with OpenSSL. The Guardian and the New York Times had recently published details — based on documents leaked by Edward Snowden — of an NSA decryption program, code-named BULLRUN, designed to circumvent and weaken the encryption software and standards that kept people safe online. Their conversation moved from BULLRUN to the state of OpenSSL’s funding.

“Steve agreed with me that it was ridiculous and we needed to make the [OpenSSL] toolkit better," says Green, "but then he told me how bad things were. It turns out there was only really one full-time developer, and that explained a lot of the problems."

“There’s a cumulative effect,” says Paterson. “There’s water building up behind the dam and with Heartbleed, the dam has burst.” In his opinion, those coding the SSL implementation aren’t blameless, though: “They are under-resourced,” he says, “but they don’t do themselves any favors.”

In the weeks since the dam did overflow, some have argued that taking OpenSSL private would have encouraged investment and mitigated against a trivial error potentially unlocking an enormous amount of private data. That would run counter to the beliefs of those involved in OpenSSL, though.

“Open-source projects are a fascinating phenomenon, and OpenSSL is almost a stereotypical example,” explains Marquess. “A handful of people get together, and they scratch their own itch. They write code because it pleases them. Because it’s open source and people find it useful, they build collaborative community forums where people can exchange ideas.”

Another major criticism laid against the group’s door is that the code is programmed in C, a programming language that has little to no built-in error checking. Had OpenSSL been coded in a safer language, goes this line of reasoning, the Heartbleed bug would never have occurred. That could well be true, but it’d be a gargantuan task that would involve translating nearly half a million lines of code, built up over nearly two decades, without introducing any more errors. All humans are fallible. OpenSSL, out of necessity, just relies on fewer humans than is ideal.