Mikeal Rogers has been with the Node.js Foundation since day one. His job as community manager for the foundation involved hands-on oversight of operations, from communications and marketing to conference planning, to running board meetings. Rogers’ main contribution, though, is organization and coordination within the Node.js open source community — particularly in scaling governance and processes as the project has accelerated from a dozen early contributors to many hundreds.
Rogers spoke with The New Stack to talk about his experience getting started in the open source world, working at the Node.js Foundation and becoming an open source governance principals guru.
First things first: you’re not going to be with the Node.js Foundation for much longer?
That’s right — in a few weeks, I’ll be packing up my desk. I’ve been here since the beginning, and things have really taken good shape. I’m ready to move on to something new, though I haven’t decided yet exactly what or where that will be.
What was your proudest accomplishment during your two years there?
Healing the io.js fork — it was a pivotal and difficult time for the community, but we emerged stronger. And better organized for sure. So saying I’m proud of that means being proud of bringing modern governance principles to a diverse and, at the time, kind of sprawling community.
How did you get started in programming?
I started programming at 13 — assembly, mainly, because I wanted to be a hacker and you needed to know assembly to be able to write buffer overflows. But mainly learning by taking other people’s exploits and manipulating them, working through their code. Even before open source was all that accessible, back when you sent patches on a mailing list, there was a community around the hacker scene and people would share exploits via IRC and hacked teleconference systems.
What led you to the open source world?
As I got more and more into the industry and into programming it was a natural fit to get into the OS scene because there was that same kind of community and support systems as the hacker world where I’d started. Which was crucial, because open source was not beginner friendly in the early to mid-90s. People who really knew what they were doing would go and collaborate. The hacker scene, though, was more a bunch of random kids showing up and they would help you out.
We talk about server scale, but not so much about community scale.
Now I think things are sort of flipped — the hacker scene has drawn inward, gotten more closed and even secretive, while the open source scene has opened up a lot more. You look at GitHub adoption and users, and how often they’re contributing — it’s not even a long tail, it’s a fat tail. More than half of the commits on GitHub are from people who commit less than five times a month, so they’re actively contributing but not dedicating their entire lives to it.
So tell us about governance, and how it’s crucial to open source.
We talk about server scale, but not so much about community scale. It’s difficult to go from being a single maintainer on a project requiring a few hours a week to their project hitting a growth curve that is suddenly two full-time jobs to manage. It’s what a lot of people hope for, but aren’t always ready to handle — so the idea is to scale up the community so it can support and maintain when that sudden progress happens. But there needs to be some structure. Open source has a culture around how things are done, and governance is how we make sure things continue to grow in a way that works.
I was really influenced in all of this by my work at the Open Source Applications Foundation, which had been founded (and funded) by Mitch Kapor, the founder of Lotus Development Corp and creator of the Lotus 1-2-3 spreadsheet program, to support wide adoption of free and open source software. [It’s] like the new Lotus Notes but for the modern era, with a lot of luminaries working on this open source project, like people from the original Apple Macintosh team.
At OSAF we really talked about the values and incentives you create around a project, and what are we encouraging by doing things this way or that way. And some of the older people might have been a little resistant to changing the way they did things, but we young’ uns ate it up. Not everything is a code problem; if you look at systems and processes as incentive structures, you can kind of code them to produce certain outcomes. And if you have negative outcomes, you can unwind the processes that got you there, and then often figure out which processes pushed people to leaning to this negative conclusion. The flip side of that is you can then produce systems that intentionally create positive outcomes.
OSAF ultimately did not pan out. There is a book called “Dreaming in Code” by Scott Rosenberg, about what a failure it was. I actually started work there the day after he stopped following OSAF, and you could already see who things kind of weren’t working out. So eventually Mitch moved the funding out, and I moved to Mozilla.
How/when did you come to embrace Node.js?
My friend Adam Christian (one of my oldest friends – we were two of the only hackers in our very small hometown) and I had built an open source testing framework, a Selenium competitor called Windmill. It was great —even by the admission of the creator of Selenium, it was better than Selenium. This is relevant because the week that Node.js was released, in November 2009, this tweet went out asking if anyone had written an HTTP proxy [aka the first edition of Node.js] that works with this. And nobody had, because it had been released for like a day. I’d just spent the better part of three years optimizing a proxy for Windmill, so I said to myself, “This is a great weekend project.” I sat down and in maybe two hours I had a functional proxy. I was blown away that it was only 80 lines, and when I benchmarked it, it was SO many times faster than the one I spent years building. Right then I literally said, “I am not going to write Python anymore — the future is clearly going to be Node.js.”
Node.js creator Ryan Dahl moved to SF shortly thereafter, and there was a culture here to work out in a fast dynamic way all the Node APIs and also talk about the kind of community we wanted to build. So I worked on early core stuff in Node and also one of the early ecosystem libraries. And early community stuff, I helped start NodeConf, which was the center of gravity for community building Node. Because we all knew it was going to take off. Back then it was inconceivable it would literally surpass Java in a decade, but we are on track to do just that. It’s a lot to take in.
What technical and/or business problems does Node.js solve?
We keep increasing the environments that developers have to contend with. If you build a product or use case out, you’ll have web front end, and then not just backend but API services you will be talking about, plus a mobile experience, a desktop experience, you may have to be on Internet of Things. On a small team, it is difficult to build on X number of environments — but Node gives a universal platform, with a half million package ecosystem. You don’t need to write that algorithm — there are more packages in the Node.js ecosystem than any other. So it allows application devs to write applications and not infrastructure. You can build faster.
Node is huge, it runs basically everywhere, which is sort of its own message.
What are the project’s current stats?
We have over 100 committers on the project — the number active each week fluctuates as we come into new releases and people get excited, but it is quite a few. We were down to about 3 contributors before the io.js fork happened, so we are definitely in a better place now.
How about the potential to monetize your involvement with the project?
The foundation is nonprofit, so I can’t really speak to open source monetization at the project level. But personally, I have definitely had an easier time finding jobs and negotiating salary thanks to my open source record.
Everyone who works in open source ends up being more attractive as a dev. You have a ton of public history beyond a LinkedIn profile. As a CTO looking to hire, you can look at their written communication skills, how they respond to criticism in a code review, when situations get escalated do they de-escalate or do things go nuclear — it’s a huge advantage for sure.
People who contribute to open source make more money than other developers with the same titles — it’s that valuable.
Any last words?
I just love the range and versatility and accessibility. Node.js can totally support enterprise, but all this new life also brings so many art projects and mad science and creative stuff going on. No other community out there has just that kind of openness.