Also in Guides

Intentional creation

Most of my time goes toward professional engineering on for-profit teams, but I’m most known for my volunteer work on the other two sectors of computing: the public and the personal. Being pulled in these three directions traces back to my roots, raised on Mac computers in research labs, relying on public school PCs, and ultimately thriving on the free culture of the web. 

Growing up, I remember riding on the back of my dad’s bike to the lab where he was work-studying as a virology resident. As soon as I could smell the phenol and ammonia, I’d head straight to the lab Macintoshes, playing with CorelDraw when it was installed, and system settings otherwise. Or maybe just watching all of the After Dark screensavers again. Even now, I wonder how sitting at those lab machines built up my stamina for long coding sessions as a programmer.

My first real attempt at programming was in high school. I still didn’t have my own computer, but I had a Knoppix live CD with Python. So during lunch, I’d mess around with scripts, HTML, and CSS for 20 minutes at a time. I didn’t bother saving anything because I still thought I’d go into graphic design. At some point I realized I’d taught myself Photoshop, but I couldn’t teach myself how to build Photoshop. Yet. That challenge drew me to major in computer science circa 2005. 

In college, I finally had a solid internet connection (10 megabits symmetric!), and joined the club of students who set up and ran software for other students in our dorms. Among other small services, I administered a MediaWiki instance. There was a tightness to the community, with more shared purpose than a modern-day social network. I host the still-active wiki today, with newer generations carrying the admin torches.

This love for wikis started when I lived in Iran, accessing Wikipedia over dial-up, and that love has only deepened as bandwidth increased. Throughout my career I’ve been obsessed with projects that work toward a public good, and are also themselves a public good. Wikipedia embodies this meta-public nature: Software creators develop the free software, which creators use to contribute free content, all built in public, for the public. 

The work is never done, but who can resist the meta-public appeal?

The path to open source

In 2012, I was three-and-a-half years into my time at PayPal when I got invited to participate in a Wikimedia Foundation hackathon. I still hadn’t published much open source work besides snippets on my blog. Then all of a sudden, those years of MediaWiki tinkering were made very real. I was in the room with core maintainers, and I realized how global the community was. The creators around me opened my eyes to the global reach and potential for impact of FOSS.

For the hackathon, we built a prototype focused on improving article quality, called qualityvis, and got second place. I still carry the now-tattered Timbuktu bag we got as a prize, and I’m still close with my teammates. One was interning at the Wikimedia Foundation and has now become Legal Director there, and the other went on to found a well-known recruiting SaaS startup. It’s been 10 years and I still want to go back and fix parts of qualityvis, an impulse that must be felt by every true maintainer. Thankfully, Wikimedians, like most members of a mature FOSS community, understand that the vast majority of work is never truly complete.

The hackathon did force me to actually use my GitHub account. The many projects that followed furnished a proving ground for patterns, libraries, and practices which would go into GitHub on nights and weekends, and get incorporated into my professional work some day in the future. The productivity of this flow led me to be a firm supporter of open source contributor clauses for employees, whether statutory or independently-developed, like GitHub’s own BEIPA. It’s a win-win-win for employees, employers, and the FOSS ecosystem.

Seeing the trees through the forest

After being exposed to the crowd at the hackathon, it felt as if the doors of the community flung open and I was in the middle of this huge forest. It felt infinite, almost limitless. As time went on, I got to know the trees that made up the forest. Each had their story, with their own interests, and hackathon projects long overdue. In retrospect, I was the odd one out by not being overcommitted.

I often think about how my experience with open source began in this smaller, more personal group. The expansion to include the vastness of the open source universe was a great kickstart, but it’s those tighter-knit groups that drive my passion. Nothing pulls me back in like a long-time collaborator emailing to ask, “Can you address this issue over here?”, or “Can you remind me how this works?” 

I may have a few packages with millions of downloads, used by tens of thousands of developers, but my interactions with that group are precious few. I’m sure they run into each other at conferences, but I’d struggle to call it a community. Without hesitation, I’d take close collaboration with one contributor on a repo with 20 stars over a repo with 20,000 stars. It brings back that feeling I had in school where it’s not as much about support work as it is about connection and conversation. The stars are good for reach and recognizability, but those 20,000 stars might only get you two solid collaborators. There are other paths to those connections, but I’m extra grateful to those special collaborators I now call friends.

I worry for new, would-be open source contributors who don’t find that connection, for whom the broader community is too broad, a community in name only. For all its strengths, “FOSS” can be faceless. Community-building is advancing, but there’s still work to be done to create structure and shared purpose, even if it’s a camaraderie of circumstance, like being in the same class or cohort at Software Carpentry or the Recurse Center.

Putting community and connections first 

In 2019, I became a Python Software Foundation Fellow for services rendered to the community. Part of it was due to my FOSS contributions over the years, and my Enterprise Software with Python project. I’ve given a lot of conference talks, and we have a 1,000-person meetup that I co-founded here in the Bay Area with Moshe Zadka, another hugely influential Pythonist about town. We just wanted to connect to more people, deepen relationships, and find collaborators. 

We’re here in Silicon Valley—so what were we doing if not meeting other developers who are also driven to software excellence? Besides being a good excuse to see friends we knew, the meetup gave us a proving ground engineered for prototyping conference talks. The key was that we almost always had 3-4 speakers, with short talks, but not so short as to require heavy editing by the speaker: 15 minutes. Our goal was that one Pyninsula talk would put a speaker halfway to the conference circuit, should they choose that route.

In 2018, we had six talks debut at our meetup that went on to get accepted and presented at PyCon US. We’ll probably never repeat that again, but we had some quality ideas come through that are still making waves today, like Trio and the Black Python formatter (meetup link). Both projects seek to improve their users’ lives by fostering new standards and communities. Trio is Nathaniel J. Smith’s attempt to make concurrent Python easier to write correctly through concepts like nurseries. These ideas are now finding their way back into asyncio, as well as into Java and Swift. Black was Łukasz Langa’s attempt to create a first-resort code formatter like gofmt, and is now maintained by the core Python Software Foundation. Both are foundations for larger projects and communities, and align well with my ideals for approaches to open source. I’m incredibly proud to have played a small role in supporting them.

When you look at the other Python fellows, many of them have an outsized contribution in terms of community and facilitation, like organizing PyCons. My libraries and other technical work may have been a factor, but mostly, they provided something to talk about. I always encourage would-be members of the community to pursue all avenues of participation, don’t just wait for technical ones.

Some Python, a little music, and record-breaking photos

Right now, my projects break down into three groups: 

• Content projects

• Python libraries

• Wikimedia projects

As far as content, I’ve spilled quite a bit of ink on software versioning. I maintain calver.org, a guide to time-tested versioning best practices, and zerover.org, CalVer’s tongue-in-cheek counterpart. I also maintain a large directory of open source Python applications, Awesome Python Applications, with the thesis that real-world applications are a valuable reference for application developers, and we live in a land of plenty thanks to FOSS. Maybe it’s my parents’ academic background that inspires me to spend all my time researching and writing the open source equivalent of review articles.

On the Python front, my most popular library on GitHub is boltons, which embodies my inner inclusionist. At last count, it’s around 250 tools, utils, and recipes that adhere to a couple basic architectural rules. In terms of most downloads, that’d be hyperlink, an implementation of the classic RFC3986 URL used by a few projects, most notably the Twisted framework. As far as my most active project, that would be glom, a higher-order declarative data operator for use within Python. All that and much much more is documented here.

But staying true to my open source origins, I spend the most time on Wikimedia projects. The 2012 hackathon buddies and I started Hatnote as a place to host and discuss all of our explorations into data-driven wiki life. It’s a decade-long journey at this point, and still surprisingly maintained.

My current focus is Montage, a niche application for coordinators and jurors in the Wiki Loves Monuments competition (WLM), which is the largest photography competition in the Guinness Book of World Records. It’s meant to preserve the heritage of these beautiful, institutionally-recognized monuments. With hundreds of thousands of submissions, it’s like the Olympics of taking pictures for Wikipedia, except it happens every year.

Aside from the great community, it was actually a sad story that inspired me to participate in WLM. A few years back, WLM got pictures of Nepal that were previously unphotographed (no free, open source, licensable photos). A few months later, a big earthquake hit and a lot of these monuments were destroyed. Iranians of a sufficient age will recall the earthquake that hit Bam in 2003 and understand why I helped organize WLM Iran. Stories like this one remind us of how important software can be to whole cultures. 

This importance translates to a level of developer fulfillment rare in for-profit computing, but common in the public space. Software is our means of expression. In an ideal sense, it can facilitate self-actualization—not just for the author of the software, but for everyone involved. Besides the open source contributor clauses I mentioned above, open source licenses are one way that people can stay connected to their expression in more than a professional capacity. It’s good to take a minute to choose the right license.

The evolution and stickiness of open source

Hopefully by now it’s clear that I’ve been a part of a few different communities, and collaborated with talented and passionate folks. I have a few thoughts on what makes communities work well, and hopes for where they will go next.

These days, open source development is trending toward professionalization. There are more career implications for part-timers and opportunities for full-time open source development. I’m encouraged by positive developments around paying the maintainers and standard codes of conduct. But these are low bars, incompletely addressing basic maintainer needs. 

The future of open source still needs a solution for the structural vacuum that occurs at the small scale. There are so many other interesting, scaled organizations that aren’t as structureless, like Wikimedia, Debian, and Ubuntu. Each one evolved its own unique arrangement, and a lot of those don’t scale all the way down. Most projects have less than one maintainer. 

Much of the logic for an organizational business doesn’t apply when staffing is 0.1 headcount. But there’s a really interesting space to explore around project/product management as a service for open source development. I personally grapple with prioritization and motivation. When this happens at work, a great product manager makes all the difference. I’d love to work with a non-technical manager who really cared about the project and could help prioritize tasks for the community.

There are a lot of folks like me who are fascinated and motivated by the purity of FOSS. But there’s a shift that’s happened, and a lot of folks now use open source as a career move or means to an end. And I can’t really fault them for that. I understand this is a privilege, and, at the end of the day, I just want everyone to recognize the true value of this community. 

I figure I’ll be in open source forever. I’ve got too much respect for the cause, and it’s just too lofty of a challenge to ever give up. And with as many friends as FOSS has gifted me, if I ever take a break, I expect them to always come knocking.