Right at the edge of Facebook’s creation in 2002, I was studying journalism in college. My friends and I built a web portal for our campus, and even though the school didn’t understand what a “web portal” was, they gave us the resources. We built our campus’s version of Facebook using an open source CMS from a different Big 12 university.

I didn’t know what I was doing, full stop. But we had a grand old time building the software with open source resources and the school’s licenses for Photoshop and Dreamweaver. I didn’t have any money and I wasn’t interested in going to the campus computer lab all the time (back when schools still had those!). So I started using free tools like peer-to-peer shared Photoshop, GIMP, and Blender, which opened up a whole new world of software.

By grad school, I was quite tech-savvy compared to my fellow broadcasting students, so they asked me to be the teacher’s assistant for classes on how to build things like podcasts and web pages. They let me design the curriculum for the Electronic Communications course and we did all sorts of fun projects. Even if someone didn’t have their own expensive software they could still participate. Coupled with open source software, the web is a very expressive and powerful equal opportunity tool. I also taught them not to be afraid of writing code. The beautiful thing about the web is that you can make it yourself.

Having the confidence (and blind faith) to get involved

After I graduated with my master’s degree in mass communication, my partner and I moved to Boston. I was still doing multimedia projects and documentaries, but then my partner got a tip about a training director job with Bocoup, a web engineering firm. They were looking for somebody to run their JavaScript training business.

I knew how to build simple web pages at the time, but there’s a world of difference between that set of skills and the programming skills required to build web applications. I didn’t realize how large the delta was between them—but I had blind faith in my ability to learn.

Thankfully, Rick Waldron was one of my mentors at Bocoup, and taught me a great deal about open source and open source standards. I would talk to him about the meetings he attended for Ecma’s Technical Committee number 39 (TC39), which standardizes the JavaScript language under the “ECMAScript” specification. We also hosted a lot of events for the World Wide Web Consortium (W3C), which is the international standards-setting organization for web platform languages and technologies like CSS and ARIA.

All these people were making decisions about how something I would use was going to work. I guess I thought there must be some “CEO of the web” deciding how everything would be done. And then I realized it was just a group of people, working together like a team. The kicker was: If they could do it, I could too. So I started to research standards development, got involved, and published some of my research.

Solving for human interoperability

I definitely could do it, and ran full steam ahead—right into a wall of trolls. I know that if I’m here, I’m supposed to be here. But it was that type of hazing built around the idea that, “Everyone’s been through it and you haven’t really arrived until you’ve been trolled.” I’m really not into that perspective because it perpetuates a lot of negativity in tech and “standards culture”—just because someone was a jerk to you when you started out doesn’t mean you have to pass that on. Standards development is too important to shut people out of.

This was before codes of conduct were implemented for code repositories, which most groups now have. Helping create a positive working environment quickly became a big area of focus for me. Today, we have a really strong code of ethical and professional conduct at W3C. We also adopted a TC39 code of conduct that has made a difference in our discourse with each other, and with developers on GitHub. We can have passion and opinions, but we must also have respect and open-mindedness. Codes of Conduct give us a boundary and framework for communicating with each other.

Some people think, “The status quo is X, and we’ve been around for a long time and need deference to our longevity and the status quo.” People don’t often realize the impact of these entrenched attitudes on newcomers, who can quickly feel disheartened. In tech, sticking with the status quo for too long is also a sure path to deprecation—you have to update your thinking when you get new input!

The response I got to my ideas in 2012, 2013, and 2014 was challenging. Today’s experience is very different. Now, the perspective that we need to work on human interoperability is widely appreciated. The idea of providing training and resources for that kind of support and open collaboration is widely accepted, even expected.

When we’re working on an open source project, or an open standards project, we’re working on solving technical interoperability. My MO is solving for human interoperability. I work with many maintainers on programs that benefit a broader community. It’s not for marketing purposes, but for the purpose of enabling people to work better together.

There’s been this boom and bust pattern over the years, especially in our JavaScript ecosystem, of new projects that launch, do something slightly new or different, and then fall out of favor for another new project. It’s good for innovation, but can also quickly fragment our stacks, which ends up being disruptive. Over the long term, we ideally want to lay web foundations with the innovations that drive the most utility for the greatest number of people. We can allow that to become part of the soil of the web, if you will, and grow new things on top of it.

Standardization is about taking the organic bits that fall off the trees—all those ideas—and turning them into more soil so new things can grow. The programs that we work on through open source foundations, and through open standards consortia, should really be focused on fostering that ecology. What helps the main planters turn their ideas from cool open source projects to essential parts of the soil of the web?

Asking the tough questions to find the right solutions

There are a lot of different lenses we can look through when we say “open source,” which makes it difficult to be precise with what we’re talking about. Thankfully, people are starting to understand that open source means more than just the license. It also refers to the governance process under which it was created. It refers to the economics of how that project is consumed, used, and contributed to.

Open source also refers to a social component, and it’s becoming increasingly important to work through some of our thorny questions like SSPL licenses, ethical licensing, and good governance models for open source. Are sponsors good or bad? Is an open collective good or bad? How are maintainers and contributors paid for their labor? How do we make sure the person straight out of college gets educated about why standardization matters, and why open source as a concept is beneficial? What impact do these decisions have on the web?

These are big philosophical questions. Because we have different frames from which to view open source, it makes it all the more difficult and challenging to ensure we’re being as precise and comprehensive as we can in our answers.

An evolving art form that thrives on human collaboration

When I’m not advocating for open source and open standards, I like to read and learn. I also like street art, which feels a little like the open source community. It’s kind of an isolated activity, but you can also do it in public with other people. There’s this alley in Boston where it’s legal to paint. Anyone can walk by and talk to you while you work, or suggest adding something. Then two days later it’s gone because somebody paints over it—and that either makes it a lot better or not. But it’s always growing and evolving, just like open source.

I love working with people. People are awesome and creative. They can really surprise you, and it’s so fun to brainstorm and solve problems and see what we can accomplish together.

Helping people motivates me. I want to see other people find the thing they’re passionate about, then do it. Do it all the way. Do it and then reflect on it, and then go do it again. Everyone I work with teaches me a great deal and makes my work better, and I have about 100,000 people I’d like to thank. Find people who are there for you and cheer you on.

When somebody gives me their time, I know it’s a big deal because they could be doing literally anything else. So I want to give people my time. Whether it’s closing issues or listening to someone vent, or helping them work through a problem. Time is the thing that’s both paradoxically infinite, but you only have so much. It’s one of the most meaningful ways to help a maintainer or support a new contributor who wants to get involved. And we need to welcome and encourage everyone.