From Novell to Now: Watching Tech Standards Take Shape

In speaking with Brian, one theme that comes through clearly is how much of technology’s foundation was laid not only by engineers, but by negotiations and power plays that happened far away from the lab bench. Long before today’s IT environment of cloud services and open-source platforms, networking itself was still a fragile ecosystem, shaped by a handful of companies and the distributors that carried their products.

Brian was among the first ten Novell instructors certified worldwide, a credential that, at the time, was almost unheard of outside of Novell’s own headquarters. It was the early 1980s, when NetWare was rapidly becoming the backbone of file and printer sharing for businesses. But Novell tightly controlled who could teach its material. That changed only after a standoff with distributors, who insisted on broader access. Brian recalls that the turning point wasn’t an engineering breakthrough, but a business ultimatum: if Novell didn’t open training beyond its corporate walls, distributors threatened to stop selling the product altogether.

The “blackmail,” as Brian half-jokingly calls it, worked. Within months, Novell’s training system expanded, and with it, the number of engineers who could properly install and maintain NetWare systems. For Brian, the experience underscored a lesson that has stayed with him: technology doesn’t rise to dominance solely because it’s technically superior. It survives because ecosystems — training, distribution, and buy-in from partners — form around it.

Standards Built on Politics as Much as Code

Looking back now, it’s easy to think of IT standards as the outcome of clean technical debates. In reality, the shape of modern networking was often determined by behind-the-scenes politics. Novell’s early control over training mirrored other moments in tech where gatekeeping collided with demand. Engineers like Brian, working at the distribution and instruction level, became the bridge that allowed technical knowledge to spread.

This wasn’t unique to Novell. Other standards battles, from Ethernet vs. Token Ring to the VHS vs. Betamax format wars, highlight how technical decisions are rarely only about performance. They are about alliances, licensing, and sometimes outright threats. Brian’s early career gave him a front-row seat to that reality.

What It Felt Like to Be There

Brian describes those years less as a time of technical mastery and more as a test of adaptability. Instructors were carving paths as they went, often teaching systems that were still changing with each release. He remembers the satisfaction of being part of a group of fewer than a dozen people worldwide who were certified to deliver that knowledge, a sense of pioneering, but also of fragility. One policy shift from corporate could have undone all of it.

At the same time, it felt like an opportunity to push the industry forward. Once Novell loosened its grip, training centers blossomed, and with them, the possibility of IT as a career path for far more engineers than before. Brian views that expansion as one of the quiet revolutions of the 1980s: not just the products themselves, but the opening of knowledge around them.

Why the Lesson Still Matters

What’s striking is how similar patterns repeat today. Cloud providers like Amazon and Microsoft now dominate by offering training programs and certifications that become de facto gateways into the industry. Engineers build careers around AWS or Azure, not just because of the technology itself, but because those companies control who gets certified and how knowledge spreads.

Brian’s Novell story feels like a reminder: innovation needs openness. Restricting knowledge may build short-term control, but in the long run, technologies thrive when people can access, teach, and modify them.

Closing Reflection

Brian’s early years with Novell are a window into the messy human side of IT history. The networking standards we take for granted today were born not just from clean code, but from bargaining, pressure, and the willingness of engineers to insist on wider access. The irony is that the systems designed to connect machines were themselves the product of very human connections — distributors, instructors, and a handful of people who pushed for openness.

Previous
Previous

Engineering in the Shadows: A Cryptographer’s View of Trust