Some people would say I’ve lived nine lives of careers, from healthcare to the restaurant and newspaper industries. Regardless of where I’ve tread, I’ve always found my drive in creating a better environment for the people that surround me.
I didn’t go to school for programming. I built my own curriculum with feedback from my community, and was spoiled by a group of really good teachers who helped raise me up as a developer—a combination of engineering friends and people I met and hung out with in coffee shops, at meetups, and at hack nights in Portland, Oregon.
When I stepped outside my local community and was exposed to the bigger world of open source while trying to expand my skill set, I quickly realized how tough it was to learn new things, connect, and collaborate. I don’t like to work alone and am very operationally-minded, so that got my wheels turning about how I could contribute to make the experience more delightful for everyone. If a project fails, it should not be because we can’t get along or carve a clear path forward. Those are challenges I delight in solving.
Finding momentum as the translator between two worlds
When I was first learning, the Python community really welcomed me, and I got my first coding job through a bunch of Pythonistas. They didn’t want to program in JavaScript but admitted it was a necessary evil of the web team’s work. They liked my code and ability to work quickly, so they asked if I would turn to JavaScript as part of the job. I figured if they were going to pay me to do it, and learn, great!
Six months into my home-baked curriculum and project work, I joined a mobile engagement platform startup called Airship. I had code in production by the second day on the job, but hated not feeling like a great programmer from the start. I felt too junior in spite of everything I had learned with my local community. I was losing patience.
With the rest of my time, I took on community organizing to feel more impactful again, starting with PDXNode, a new-at-the-time Node.js meetup in Portland. Learning and contributing to Node.js was not intuitive for me, so I tried to consider how I could make it easier for other people (while I was simultaneously building my own knowledge).
Evolving the OpenJS Foundation
Around 2014, Mikeal Rogers needed someone to help him build out the education component of the Node.js Foundation (which has since merged into the OpenJS Foundation). At the time, there was this notion that JavaScript and Node.js were easy to learn, even though, in reality, they were not. We saw companies have great early success with Node.js adoption, so the demand for Node.js was extremely high, and we wanted to find a way for more people to learn.
Our smaller, local communities were having fun writing Node.js projects, but there was a quickly growing mismatch between available jobs and the coders who could fill the positions. The Foundation advocated for the coders by working directly with the hiring companies.
Node.js was more challenging to learn than JavaScript because it was newer, had minimal documentation, and a number of other reasons people love to argue about, so I set to work improving how developers learned Node.js. It wasn’t about taking front-end engineers and making them back-end engineers, but about how they could be more full stack. I focused my efforts on finding people interested in teaching Node.js, on defining the best way to teach it, and then cultivating all of that into the ecosystem.
I did attempt an unsuccessful documentation build-out. Documentation is forever challenging, and I appreciate anybody who does it well. Unfortunately with Node.js, the few people with deep knowledge and expertise were improving their part of the codebase and didn’t feel like they had time to write documentation. Still determined to find a way to help with getting hired to Node.js, I turned to the community to determine which Node.js areas you should know to hit the ground running, and which questions you should ask, and we built out a Node.js certification. This empowered a lot of folks from non-traditional backgrounds to be recognized for their skillset. We also encouraged educators and training groups in the ecosystem to create the content to help programmers prepare for the certification.
Even though it’s a global project with over a trillion downloads, Node.js is historically known to have a very fiery community with lots of infighting. By 2015, we were down to four core contributors because it had gotten so difficult to contribute due to the conflict. It was wild and terrifying when we finally said that outloud, but it enabled us to rebuild our community, align Node.js values, and improve governance.
We created a trusted moderation group of 10 people, including myself, who were appointed by Node’s 1,000+ contributors, to handle very serious, escalated moderation issues. We established a set of processes for how to equitably handle these escalations, and have seen other projects and foundations follow suit. I’m really proud of that.
I also helped form an alliance of technical and community contributors that focused on Node.js’s governance, code of conduct, and our Diversity, Equity, and Inclusion efforts. This eventually led to the Foundation trusting our guidance and adding a community seat on the board, which I was the first to helm. To the credit of everyone at the Foundation at the time, and on that board, this was unprecedented: It’s not normal for an open source foundation to have community liaison seats with board voting ability. But it was very interesting work because you have to go behind the scenes and sell the value of community and conflict management to those who don’t believe in it yet, whether that’s core contributors or corporate board members.
Removing obstacles to make room for work that matters
I returned to the private sector in 2018. By then, I had collaborated with many open source entrepreneurs and wanted to shift toward startups and empower them through my open source and community expertise. As the head of platform under Samsung NEXT Ventures, I drove the advisory support network and community for all the startups they invested in. Mapzen was an accelerator company at Samsung NEXT, and as part of my time there, I collaborated with other open source leaders at Samsung to help spin out Mapzen’s intellectual property and repositories into fully open source projects and a foundation separate from Samsung.
In 2019, a friend recommended I talk with the president of the Open Source Initiative (OSI) Board of Directors, and I joined through an appointed board member position after being really intrigued by the challenges they were facing in open source. Again, more than ever, there was this increased demand to define open source from a license standpoint and ensure the foundations on which projects are built remain strong. As more questions around sustainability and open source came up, I stepped up to the role of CFO and treasurer.
Whether you’re at a company or managing a group of friends with a common cause, conflict management is ever-present and challenging, but important. The conflict is healthy if you’re able to manage or resolve it, and makes for a better product and project because you’ve created a space where more voices are heard and considered. If nobody’s listening because the conflict has forced people to give up, I would argue it’s a single-use project, or will stagnate and fizzle out.
People from the ecosystem kept approaching us with these really great ideas and pressuring us (in the best way) to step up, but we didn’t have the resources. For example, when you work at a company, you answer to your boss and have HR when things get rocky for a professional setting. But is an open source project a professional setting? We want to respect the time of everyone involved—of the hardworking, mostly volunteer people who care and work just as hard as any company employee. At what point should open source have more formality or structure? These are questions I love to consider and help navigate.
We had to pause, look holistically down the road, and say, “Here’s the demand we have for solving these really big problems in open source. How can we empower the organization? Do we have the people we need on staff? Can we afford to hire more people? How do we help the organization get there?” For me, this part of open source is where I belong. I want to help solve these human-centric issues so everyone can get out of their own way. Then the community, and its work, has space to shine.
When I’m talking with developers–especially those who are just starting out—I often reflect on my early career. I like to say that you will care too much and want everything to happen now. It will happen, but you can't force it. What you want will come with hard work, timing, trusting your own instinct, and a lot of luck (and the privilege of who you know). And if it doesn't happen? The stuff that is coming is cooler than you could ever imagine.
