Open Source in the Workplace

Chapter Six

Open Source in the Workplace

Engaging with open source software is part of your day to day, regardless of your organizational size or mission. To deny its impact and ubiquity would be as foolish as it is false. And yet “96% of the demand-side value is created by only 5% of OSS developers.” ²⁶¹ Where’s the disconnect?

Companies aren’t paying their fair share.

I suggest further: omitting open source engagement as an integral job responsibility is unacceptable from every perspective.

First, it is shortsighted corporate starvation to not empower their developers to work on open source. They consume this software to further business goals—improving it and their employees helps the bottom line. Second, it is personal closemindedness. Both fail to see the potential of open source as a skill to be trained. A craft to be honed. A profession to work purposefully within.

We don’t need more open source celebrities. We need more first-time contributors. We need more company tinkering time, corporate open source funds, unstructured learning, and trust to share out what we know. We need more engagement beyond our comfortable spheres of influence. This is the untapped potential energy of our industry. I’ve seen it ignite, as scarce as a lightning strike. What if we could harness it?

I said responsibility before and I meant it. I see open source engagement as a pursuit worth more than your current circumstances. You build it, consciously or not, as your lasting contribution to the corpus of our field. A field that is still in its infancy. We all gotta eat, of course. But more importantly, we all gotta survive. The advancements we make individually and together contribute to the symmathesy of products, industry, and culture. It will outlast your current paycheck, middle-manager, role, and company.

You Don’t Need Permission to Do Your Job

Open source software is unavoidable. Contributing to it should be as natural an action as consuming it. Chefs don’t ask permission to source new ingredients, tweak existing recipes, or create new dishes—creation is implied in their role. A chef that doesn’t do these things is a line cook. Each has their place, but one aligns better with the fluid landscape we operate in as developers.

I remember this mantra, “you don’t need permission,” came up when component libraries and design systems emerged. Many a thinkpiece was written on whether or not your company needed a design system. Perhaps it was a collective pep talk, or exercise in building toward a crescendo. I built one as a UX team of one, part style guide, part laboratory, without asking my boss. Instead, I showed him. He wouldn’t have understood why it mattered. And it didn’t matter to me, really, if he understood, because the team and product needed this new tool to better organize ourselves. And then, to my observations, the industry stopped debating whether or not we should create design systems. It became the obvious default to adopt and optimize.

We need to do this with open source engagement. We need to take the initiative to better our habitat. There are opportunities everywhere—you are bound to find a corner of the broader community that interests you.

Start small. Instead of buying a maintainer a coffee via a donation, spend a coffee cup’s worth of time contributing to their project. Don’t ask permission—use that ten minutes as an experiment. Tweak your hypothesis, find your interests on the spectrum of engagement, and report your progress at work. Open source altruism cannot be taught, but it can be modeled. Next time, pair with someone. Show them how approachable it can be.

You don’t need permission because your actions already interact outside the four walls of your business, whether you like it or not, into the legal sphere. There are external consequences of your work. It’s in your best interest to demand and obtain access to the outside world, as you are not shielded from it:

• You might remember online commentary about the potential liability of Uber engineers developing self-driving cars’ autopilot systems when a pedestrian was killed in 2018.²⁶²

• An individual was indicted by the US Government when his software was used by a third party to commit fraud on the Chicago Mercantile Exchange.²⁶³

• IT workers in Albania were “placed under house arrest for failing to update the antivirus software on government computers,” and could face seven years in prison if convicted.²⁶⁴

• Academic work is examining the legal liability software developers expose themselves to under International Humanitarian Law when autonomous weapons are involved.²⁶⁵ Did you know International Humanitarian Law is a nicer way to say war crimes?

• A thorough 2014 post-mortem of alleged software deficiencies suggested Toyota vehicles could unintendedly accelerate when the program monitoring the gas pedal crashed. (FIG 6.1)²⁶⁶

FIG 6.1: An excerpt from an independent post-mortem of Toyota unintended acceleration incidents. This would be funny if dozens of people hadn’t died.

Proprietary or open source, your actions as a programmer have consequences beyond keyboard and screen. It’s on us to reclaim agency. Agency in saying no to predatory or discriminatory algorithms. Agency in adopting the full spectrum of engagement by default. If your company doesn’t let you do that, after insistence, explore your options.

You are Part of Something Larger

The Web as we know it is, what, thirty-some years old? What other consequential human advancement is so close in the rear-view mirror? Do you think engineers thirty years out of the Wright brothers first flight were aware of their historic place at the inflection point of transportation? Did the “Penicillin Girls”²⁶⁷ steadfastly harvesting milliliters (weekly!) of the new wonder drug know the weight of their 1930s breakthrough? (FIG 6.2)

FIG 6.2: Two of the six women—Ruth Callow, Claire Inayat, Betty Cooke, Peggy Gardner, Megan Lancaster, and Patricia McKegney—trained to “farm” penicillin from fermenting mold canisters in the 1930s. Industrial scale production wouldn’t come for a decade. Copyright © 2017 Women working with penicillin cultures © Museum of the History of Science, University of Oxford

I wonder if there is there any other profession with as much richness, diversification, impact, reach, and potential as the Web. We aren’t making pamphlets, fansites, and toys here. We aren’t selling pants or posting photos. We are engaging in something greater. Do you see it? I don’t mean to self-aggrandize here—I am self-actualizing. Connecting the parts to the whole. According to the spectrum of engagement, there is always a vehicle to do this while at work—without having to wade at all into nights and weekends.

I challenge you to adopt this perspective, as Jeremy Keith outlines in his November 2021 talk, The State of the Web.²⁶⁸ We’re connecting society, propelling it forward, making it into something unimaginable even a generation ago. Let me emphasize and cast within open source structures. We consume and contribute within our own means, along the spectrum of engagement. But I suggest you should see the work at any particular job as an opportunity to execute your craft at a larger scale, beyond the function, user story, and product of the moment. The open source work you draw from is right there, a relay race with many lanes and runners. The starting blocks and finish lines may feel nondescript, but the baton is always ready for you.

It’s easy to throw around oft-guilt-ridden words like should. But I aspire to see should in a nobler light, if only this one time. You should engage with open source because it’s a tangible manifestation of something larger and more important. It might sound rote, like, you should recycle. But, I argue, respectfully, it’s not about you. Keith frames his talk around the 1968 Apollo 8 mission to orbit the moon. He reminds us that astronauts sometimes experience a phenomenon known as the overview effect²⁶⁹ when seeing the Earth from space. One ceases to see the world’s boundaries, substituting this mindset with both a unified vision of the whole and a motivation to think and act in its best interests. We can come close to experiencing the same via the Earthrise²⁷⁰ photo, taken from the same Apollo mission. Here we witness the Earth rising over the horizon of the moon. Quite the change in perspective. (FIG 6.3)

FIG 6.3: Earthrise, taken by Bill Anders aboard Apollo 8 in 1968.

If we choose to see the World Wide Web as more than memes, cat pictures, advertisements, and comment section vitriol, we can grow beyond our individual means and solve truly larger problems. Like crowd-sourcing complicated protein folding calculations,²⁷¹ connecting people needing sighted support with volunteers over video,²⁷² creating access to free wheelchair tech,²⁷³ finishing the knitting projects of late loved ones,²⁷⁴ or confronting the climate crisis.²⁷⁵ Open source work permeates these efforts, and so many others, consciously or otherwise.

We are inventing the industry as we speak, for worthy or ill intent—it will be what we make of it. We are so few that individual impact is still felt, in herculean efforts yes, but more so in nudges along the path by us normal folk.

Jenn Schiffer wrote that we are in a unique position to shape and course correct. She wrote, in a now-protected series of social media posts:

from my experience over the past decade, workers are making the tech stack decisions more than ever and that’s a lot of power i don’t think they have processed. and decision-making is labor. don’t let the toxicity of “passion” trick you into not considering your job a job. anyway, i prefer community-owned open source too and would love for that to happen without introducing a new flavor of exploitation.

The intersection of work and open source is no coincidence. Companies have been co-opting open source into their solutions more and more. Some of the original antagonists in the open source movement, such as Microsoft, are now among its strongest supporters. But remember, this is not without looking to their interests too. Employees with hands on keyboard are well-positioned to advocate for and adopt healthy value exchanges. Developers as a form of capital-L Labor are emerging everywhere, from successful unionization efforts at companies like Glitch,²⁷⁶ Kickstarter, ²⁷⁷and the New York Times,²⁷⁸ to software licensing and codes of conduct. The rise of AI while this book was written is challenging nearly every system, nearly any narrative we have. But it’s still humans at the wheel (so far), and that means we need self-efficacy. Ethan Marcotte no doubt channels all this better within You Deserve a Tech Union.²⁷⁹

Everything is Open Source

Open source is everywhere. Your employer is using it. You are too. If you can conceive of a technical concept, there is probably a project out there looking for help. Open source is everywhere—like, outta this world, man!—which I mean literally because NASA’s Jet Propulsion Laboratory publishes an open source flight software framework²⁸⁰ running the Ingenuity helicopter on Mars. (FIG 6.4)²⁸¹

FIG 6.4: A badge that GitHub displays for contributors to projects relating to the Ingenuity mission to Mars.

You don’t need to be a rocket scientist to realize there is open source representation up and down our entire stack:

• Servers: Apache httpd, nginx, Tomcat

• Browsers: Chromium, Firefox, Vivaldi

• Content Management Systems: WordPress, Strapi, Drupal, Ghost

• Static-Site Generators: Jekyll, Hugo, Eleventy

• Frameworks: Next, Nuxt, Svelte, Astro, Fresh, Django, Rocket

• Libraries: Express, jQuery, Moment.js, React, css-doodle, Lit, jsonwebtoken

• Tools: AVA, Size Limit, ESLint, Prettier, webpack, Changesets

• Runtimes: Node.js, Deno, Bun, Open JDK

The very programming languages we code with every day are often open sourced too. The TC39 committee proposes, documents, and tests new additions to the JavaScript language.²⁸² Standards bodies like the WHATWG²⁸³ develop the specification for HTML, fetch, URL and more. The W3C²⁸⁴ contains the CSS working group responsible for the development of new language features.

Take the CSS Nesting Module, at the time of this writing in Editor’s Draft status. (FIG 6.5) It’s on GitHub to look at and comment on.²⁸⁵

FIG 6.5: The Editor’s Draft of the CSS Nesting Module specification open for public comment.

Public feedback on syntax and behavior is encouraged from non-members, allowing us all to participate directly in the standards bodies that govern our foundational tools. You can observe library authors integrating functionality as it evolves,²⁸⁶ bringing the functionality beyond the theoretical and into more accessible formats for testing. What better way to level up your game than to help make the rules? Impress your coworkers and boss by being on the cutting edge of these emerging features and sharing out their progress toward adoption. The opportunities we have to engage across the spectrum, up and down the stack, create a near-certainty that something will pique your interest. Creating an outlet at work to act on those interests is part of your job. We consume, we contribute. A breathing exercise.

I shared before that this very pathway within the element’s journey was what empowered me to realize there was no speed limit on the Web—we are free to devote as much effort as we wish to this shared experiment. My contribution at the time was miniscule in retrospect, but it opened doors I didn’t know existed, pushed me to develop skills I never had before. Most importantly, the work connected me with people beyond my local bubble. I see this same spirit of innovation playing out within projects like houdini.how, a site devoted to the education and evangelization of the CSS Paint API. Your work, your team, and your company will benefit from your expanded perspectives and skills.

Gather Momentum

Starting and sustaining an open source effort in the workplace is both an effort in grassroots willpower and corporate organizing. Finding like-minded individuals helps coalesce energy around common problems and shared solutions. Consider forming a guild, unofficial club, meetup group, or even a Slack channel to organize and plan action. Accumulating allies and contacts helps accrue support at higher levels, giving early efforts a longer runway to prove success. We need to be vocal supporters of the efforts, internal and external, that we rely on.

We can do that with our corporate voices and corporate paychecks. Kat Marchán said on social media,

Maintainer after maintainer, the same story: corporate sponsorship of open source work was the main way anyone had time to contribute. So why are we pretending open source is a “pure” community endeavor and the solution isn’t just “give them more money from our deep pockets”?

Benefits, or Convincing Your Boss

Contributing to existing open source work is usually an easier task, requiring less permission and more forgiveness, as they say. So when your company chooses to open source its own intellectual property, focusing on the benefits of open source can assuage doubts and concerns. Here’s some straightforward arguments you can tailor to your situation. Open source work can:

• Raise the company profile: for better or worse, there is a prestige associated with open source work. You are swimming in larger waters. Participating in the marketplace of ideas. Let the analogies run wild.

• Aid recruiting and retention: many developers want to be working on open source. Working on projects while working keeps current employees from straying and attracts talent from elsewhere. Potential hires can see what and how you work before they even apply. This may filter out candidates before they even reach HR.

• Skill up employees: when every action is scrutinized, you have a tendency to improve your game. Engaging on the spectrum of engagement as maintainers teaches you to make more maintainable software.

• Prioritize the ecosystem: recognize the altruistic values of open source. This might align well with your company’s actions in other sectors, like activism, volunteering, or direct donations to charitable endeavors.

• Give us “free patches”: just kidding. This shouldn’t be in the pitch, though it might happen as a by-product.

Corroborate these ideas with the momentum from your in-house communities, external contributions, and a healthy dose of realism. Remind everyone how much open source you consume. I’ve found it to be a pretty easy sell when soapboxed a bit as the right thing to do. People want to do the right thing, but you need to show them what that is. Have a plan at the ready. Have a project in mind. Make it their good idea and you’ve recruited an ally.

Questions Needing Answers

So, you have their attention. This open source thing might work. Upfront think about common questions. These are the early gotchas that detractors and champions alike may ask about. Being prepared with answers may help you convince a stakeholder of the value of open source, or at least fill any awkward silence with a confident plan that lets you get back to work.

Buy-in Questions

Aspects that might stop your efforts before you have a chance to start. The concerns you might hear are:

• Won’t this take time away from …?

• How do we know we are successful?

• Sure. What’s next? Where do we start?

Legal Questions

Intellectual property and legal hurdles may need resolution before open sourcing anything you do on company time:

• Do we need a CLA process? What message does that send to the community?

• How are trade-secrets, company data, or patents handled?

• What license do you want to use?

Contribution-based Questions

Nitty-gritty details once you are up and running:

• Do we plan to only contribute new work? How do we enable employees to contribute outside the organization? When do we fork an existing project?

• Which projects make the best open source contributions? Are there some that should be avoided?

• What do we do when people leave the company?

• What if we don’t like the contributions we get?

• How do we ensure quality? (apply some of the automation lessons from earlier)

Security Questions

Safely engaging in open source communities:

• How can we make contributions and releases secure?

• Do we need two factor authentication on developer accounts?

• Should automated processes use developer secrets or single-purpose accounts?

Having answers to these questions will serve as a good first draft of real company policy. Your answers don’t even have to be right, yet, that’s for the whole team of stakeholders to align on. But it does demonstrate a firm grasp on the breadth of issues your company will encounter beyond git push.

Slow and Steady

Go slow at the outset to go further in the long run. This is a big flywheel to get in motion. Your company’s open source presence will grow with intentional effort and community-building. Sustain contributions once launched, lest your open sourcing efforts become a graveyard. One of the best ways to do this is to continue to use the software yourself, sometimes called unappetizingly “eating your own dogfood.”

I’m excited about the prospect of open sourcing code I write at work, and am happy for the opportunities that present themselves. But I acknowledge that not all projects are right to open source. Don’t pursue open sourcing a new project just for the sake of doing it or to check a box. Don’t open source something because your manager told you to (or because I did). In both cases you’ll be chasing a feeling of accomplishment that needs to come from elsewhere. Yes, we are trying to get buy-on from management, but not at the expense of readiness and resolve at the engineering level. Your team needs to be mature enough to operate at the maintainer level, transitioning many processes to an outward, public perspective. Open sourcing at the outset of a project may be easier than adapting an existing project. Have these conversations with your team and stakeholders. Know where everyone stands so you can direct the conversation toward the best outcome for you, your team, company, software, and community.

I’ve found success, when the stars aren’t aligned, open sourcing what I’d call the orbital bodies. Trying the whole planet, the flagship product, might be more than you can handle, or it might be too integral to the business model of the company. But an internal tool, generic libraries, an automation, these things are interesting candidates. Spotify open sourced their Backstage developer portal²⁸⁷ years ago and recently released some premium plugins. Many other companies have vast catalogs of projects that seem ancillary to their core customer offerings, and that’s okay! You can do that too.

Inner Source

Still not ready? That’s okay—there’s another coding strategy your company can adopt to build community. Inner source is the conscious application of open source principles to projects in the workplace—though they may not be wholly open sourced themselves. This smaller scope and population size is more manageable. Y’all should already be friendly, familiarized, and aligned to shared purpose. Inner source efforts still need good fundamentals like documentation and expectations exchanges. It’s a great outlet to practice and hone skills that benefit everyone, open sourcing or not. A spark of altruism and sponsorship from management helps get Inner source projects off the ground.

But developers and managers need to know that successful Inner source projects don’t happen by accident either. This isn’t the absence of all governance—this is intentional stewardship. Inner source projects are both products and communities. That means you might spend development time working on tasks that only improve community, like celebrating contributions, conducting webinars, open office hours, etc.

The shared context so important to newcomers in the open source community is important here too. Don’t let information become siloed or hidden away behind private team areas. Inner source projects need to be open by design, not by default. These projects need high-engagement to sustain themselves. That’s why it’s important to pick the right projects to rally around. They need to solve a generalized problem within your company and have enough users and applications to see continual development. A component library is a great example.

Maintainers need to plan avenues for contribution along the spectrum of engagement. Internal contributors need headroom to spend a bit more time on a story so that they solve for everyone and not only their product. Management needs to understand that resource allocation, cross-team goalsetting, and prioritization is harder the more teams you add to the equation here. A centralized group empowered to govern and shepherd contributions is important. You need a brain to keep it moving in the right direction, a janitorial staff to keep the lights on, and a steady roster of motivated helpers to keep development rolling.

The Inner source Commons organization²⁸⁸ brings together companies practicing Inner source development to share and advocate for successful patterns. They’ve documented over twenty patterns that organizations can adapt to their needs, covering four concept areas: Begin, Adopt, Grow, and Scale.²⁸⁹ If this looks reminiscent to the spectrum of engagement by now, I’ll consider myself successful. I’ve implemented and observed the effect these patterns can have on the health of a project. It’s really heartening to see that community can form around process, not just tooling.

An Inner source project can be a gateway to larger open source efforts, as your team will learn how to manage and communicate change for a wider audience. If it happens, it happens. You’ll know when you are ready.

Open Doors and Minds

I’m not trying to push you and your team to engage with open source. You need to find motivation within yourselves to do that. But don’t convince yourself that you aren’t affected by the outside world—and in acknowledging this, take action to shape it toward a more just, equitable, and useful place to work. We draw from the open source community every day, and I don’t mean owls this time. We are building something that will outlast all of us—it’s hard to even fathom. Recruit allies to advance your interests, and look beyond your current role to the larger currents of work flowing around you. Focus on the little things at first, what you can manage. The community will be better when you show up, even if you start small.

Chapter 7: Open Source Sustainability ➡️