Stop Hiding. Just Ask.

I came across an exchange on Twitter the other day that made me sad. In part:

Opensource newbie

It made me sad because I spent longer than I should have in a similar place: curious, interested, wanting to know more and also to have input, but being surrounded by people who’d been doing “this stuff’ for 20+ years. I was at a loss as to how I’d ever “catch up”, never mind be in a position to provide value.

Here’s the thing: I wound up in that place because I’d invested a good 20-25 years of my life by that point in making sure I was really competent. Competence and knowing what you’re talking about are things that are valued very highly in my family. Moreover, I grew up surrounded by engineers, who tend to enjoy arguing and sometimes pounce with delight on logical lapses or other types of weak arguments. So from an early age, I shied away from spending a lot of time on things that didn’t come naturally. Early in my career, I did the same: I carefully stayed in roles that didn’t require me to have any specialized knowledge. By my mid-30s, I was in a rather small box–one entirely of my own making.

Now, had anyone else told me I just didn’t have what it takes to do any particular kind of job, I most likely would have furiously plunged into proving them wrong. Instead, I took great care to avoid fulfilling the stereotype of the clueless (female) marketeer: I asked no questions that could be “dumb” questions. I’d quietly go read up on things on my own, but a lot of the time I didn’t have enough context to make total sense of what I read. Still, I avoided asking questions.

What finally did it was screaming boredom. I just didn’t want to keep doing what I’d been doing any more. I decided I’d rather be dumb than bored.

It was terrifying.

Eventually I found a colleague who was working in a similar area, but was coming into marketing after a long time as a engineer. We’ll call him Fred. Every so often I’d walk over to Fred’s cube and announce (pre-emptively, in my mind), “Hi, I have another stupid question,” to which he would helpfully reply, “There are no stupid questions, only stupid people.” And then proceed to explain both the theory and the depressing reality of whatever I was asking about. I have since learned to spot Freds fairly quickly, and over the last few years I’ve built up a wonderful network of Freds. Thanks to social media, most of them are not in a nearby cube, but several states or even a continent away–but that means I get a much broader perspective on whatever I’m curious about than if I just asked the person in the next cube whose vantage point on the world likely only differs from mine by a few degrees.

This brings me to a wonderful talk I unexpectedly attended a few months back. My daughter had been taking a Scratch class through Coder Dojo, and the last night of the session, the parents were all asked to gather in a different room for a pitch from one of the Coder Dojo cofounders, Bill Liao (@liaonet).

Liao opened by stating that coding is poetry, which won me over right there. To be good at poetry, he said, you have to be deeply fluent in a language, in a way you can be only if you speak it from a very young age. It goes without saying, perhaps, that when you learn to speak a language in a fluent, natural way, you do it by interacting with other people. Or as Liao put it,  “I learned to code in my bedroom, and I think working alone in your bedroom is a terrible way to learn to code. I think working with others on a project is a great way to learn to code.”  You can watch an abbreviated version of his talk below.

And this, in turn, brings me to a lesson taught to me by my friend Brent Salisbury (@networkstatic), who became active in OpenDaylight in its very early days. He was trying to convince me to get involved. “But Brent,” I protested, “I haven’t coded in 20 years, and I never got good at it even then.” He told me it didn’t matter. ODL desperately needed documentation. QA. “Play around with Python,” he said. “Hell, I’m dyslexic–if I can code anyone can.” The point being that any project in which people are doing things mostly on their own time–which is most open source projects–desperately needs help of all kinds, and will usually gladly welcome a range of skills, not just narrow technical ones. “I’m just learning how to code, but this is really interesting to me–how can I help?” is as good a door-opener as any.

And of course the way to make book-learning–or any learning–really stick is to try to use it. At Brocade, we have a couple of SEs who have spent most of their careers as network engineers, but are really excited about SDN. They’ve been delving into the documentation–both on the ODL site as well as the materials for my company’s distribution–and making notes about how it works in ways that make more sense to someone accustomed to running a network. I myself had learned about SDN and ODL from a more classical software perspective, so reading what they’ve written was really helpful to me, as they naturally point out very practical nits and concerns that hadn’t occurred to me. Now we’re in the process of converting their work into papers the bigger world can access, which should be helpful to a lot of other network engineers trying to get their heads around this stuff. Note: none of us is writing Java code. All of us are contributing to the growth of an open source effort. It takes a village.

Becoming an expert also takes a village. It’s why throughout history, you find innovation happens in clusters, where talented people gather, get to know each other, and exchange ideas. The lone genius is a myth. Mozart was mentored by Haydn, among others.

Ask for help, and ask how you can help.

A Simple Definition of “Open”

I wrote this into an internal FAQ today:

Q: What does “open” really mean?

A: “Open” is used in a variety of ways. An “open” API is an interface that uses standard protocols, tools and models and that can be written to by customers and third-party developers. An API is not, by itself, “open source”. Open source describes a development model in which anyone at all is free to download, improve upon and, with the agreement of the developer community, contribute code to a particular project. It is common to use open source components, often from many different projects, as building blocks of a proprietary piece of commercial software. Increasingly, there are open source projects, including OpenStack and OpenDaylight, which seek to deliver a complete and wholly open solution.

I like it, but given how freighted the whole topic is, it seems rather daringly simple and straightforward. So, dear readers, what nuances, caveats and gotchas am I missing?

Response: Open Networking: The Whale That Swallowed SDN

Art Fewell, whose views I greatly respect, has written a very good post on Network World entitled “Open Networking: The Whale That Swallowed SDN“. It’s a great historical summary of SDN 2011-present, with some noteworthy areas of concern. I agree with the general thrust of Art’s thesis, yet at many points I found myself thinking “Yeah, but…” I started to write a few comments on the Network World page, but the comments turned into a page, so here we are.

Here’s what I really liked in Art’s piece: Continue reading

Thoughts on SDN Consumability

I’ve been using the phrase “SDN consumability” here and there of late, assuming that there was nothing particularly revolutionary in the idea. The response, however, is typically a cocked head, an interested look, and a question: “What do you mean by that?”

So here’s what I mean by that:

In order for SDN to see mainstream adoption, SDN solutions need to be/have

  • Simple to operate – easy to deploy, low-to-moderate learning curve
  • Safe and reliable – tech is stable, nothing blows up, no one gets fired
  • No blue-sky requirements, limited DIY – tech and process migration support available

Continue reading