The ESLint Logo Story:
How Non-Programmers Can Shape Open Source
Every day, millions of developers see a logo I designed. It took me just a few hours in 2016, yet it appears in their IDEs, conference presentations, and official documentation. If you've ever felt like you're not "technical enough" to contribute to open source, this story might change your mind.
I mostly struggled with JavaScript because I never invested the time to learn it properly. I wanted to change that, and I started reading the book "Professional JavaScript for Web Developers" by Nicholas C. Zakas in the summer of 2013.
The book gave me the confidence to understand JavaScript, rather than fighting it. Still, I was hesitant to call myself a "software developer", especially seeing the work of open source maintainers and how much impact they have. I started following them on Twitter to stay informed and up-to-date with the ever-changing front-end ecosystem.
Designing the ESLint Logo
On January 27th, 2016, while scrolling through my Twitter timeline, I saw a tweet from Nicholas C. Zakas, posted five minutes before, asking for non-code contributions to the ESLint project, ranging from design work to community support.
https://x.com/slicknet/status/692454724168069120
Remembering how much his book helped me on my journey, I wanted to help and give back to the open source community, and I replied:
https://x.com/omerbalyali/status/692456284239589378
I didn’t get any response on Twitter, but I saw he posted a link to the GitHub issue #5083.
After 10 minutes of seeing the tweet, I replied on GitHub that I can help with the logo and website redesign.
@nzakas: [...] An updated logo - we like the current one, but would like to evolve it. We also like the color scheme (purple!). We'd just like an update to the logo and typography that would be good for stickers, tshirts, and more.
Source
The brief was simple: redesign the ESLint logo without a drastic change, so that brand equity can be retained. It wasn’t a “redesign from scratch,” but rather an evolution to make it versatile for any application, especially as a small icon.
Less than 24 hours later, I asked for feedback for the first drafts of the redesigned ESLint logo and the new website.
The first option I proposed ultimately became the final logo, with some minor tweaks. The entire process occurred in GitHub issue #5085. I later signed ownership transfer documents to the jQuery Foundation (now OpenJS Foundation), which registered it as an official trademark. The only behind-the-scenes part was the legal paperwork; everything else is accessible online.
Construction Steps
Construction of the logo grid was so simple:
- Draw a perfect hexagon, and draw a rectangle around it.
- Copy the hexagon and rectangle, rotate them 90 degrees, and place the smaller rectangle inside the outer hexagon, with the smaller rectangle touching the outer hexagon.
- Copy the inner hexagon and rectangle, and place them inside to create the “inner hexagon”.
- Subtract the rotated hexagon from step 2 from the outer hexagon.
- Round the corners of both hexagons (from steps 1 and 3) to make them more refined.
ESLint itself is about systematic perfection–it identifies minor inconsistencies and fixes them to improve our code. This logo grid, with its mathematical accuracy, was an ideal fit. Ironically, the grid was perfect on paper, but somehow the final logo isn’t; the inner hexagons are slightly larger or smaller than they should be. It was a mistake but faith it seems. Like ESLint itself, which doesn't create perfect code but guides us toward it, this logo isn't mathematically perfect, but it is perfectly functional.
Designing in the open, receiving feedback from the community, and discussing the entire process exclusively on GitHub issues was an enjoyable experience for me. I was glad to write that tweet; it was my first real contribution to an open source project.
Impact and Reach
Today, ESLint is one of the most popular and crucial open source tools, with ~100 downloads every second. It's integrated into most JavaScript development workflows.
From product launches to conferences, it has been shown everywhere.
Watch on YouTube: https://youtu.be/GjvgtwSOCao?t=2360
Seeing that hexagon in presentations and daily in millions of developers' IDEs — including mine — is surreal. I’m proud of the work I did, but this popularity isn’t about the logo or who designed it.
A logo is just a vessel; it only matters if the thing it represents matters. Nobody wakes up excited about linting JavaScript. They use ESLint because it solves real problems: catching bugs before they reach users, making JavaScript more reliable, and helping teams maintain consistent code.
My contribution was small, my investment was merely a few hours, but the impact of that small contribution is unbelievable.
Infrastructure at Scale
It may seem unusual to some that a small contribution can have a significant impact, and I’m not just referring to the logo design, but rather how open source contributions work in general.
Source: npmtrends.com/eslint
ESLint is not an outlier in this trend; all successful open source projects exhibit similar scaling patterns. But exponential growth means exponential dependency. And dependency implies fragility.
Securing Open Source
Today marks the end of the 5th #MaintainerMonth, with this year’s theme being “Securing Open Source”. Given the infrastructure fragility we just explored, this focus couldn't be more timely.
We rely on open source software in every facet of life, from healthcare to city infrastructure, from entertainment to AI advancements. Yet maintenance is left to volunteers who invest their time, well-being, and money freely. While many companies support open source initiatives, most of the work is still done by volunteers worldwide.
Projects like ESLint play a crucial yet overlooked role in securing our infrastructure by enhancing code quality and identifying issues early. But the responsibility cannot be left to volunteers alone.
Corporations of all sizes benefit from open source, yet their contributions are underwhelming compared to the value they receive. Initiatives like Sentry's Open Source Pledge demonstrate practical steps: donating "$2,000 per year per developer" is something any corporation can start immediately.
Securing open source means more than patching vulnerabilities—it means ensuring these projects remain vibrant and welcoming to new contributors. This is where individual contributions become crucial, because sustainability comes from the community, not just corporate budgets.
Beyond Code
Individual contributions are crucial for the future of open source, but who counts as a contributor?
Consider how startups form: someone identifies a problem, experiments with solutions, and builds something that compounds over time. Open source projects follow a similar pattern but operate differently than commercial ventures—the most valuable resource is human capital, and A-players ("A" stands for high agency).
Yet, despite the need for diverse skills, our biases tend to favor the idea that these projects require only programmers. Just like startups, open source projects require community building, design, documentation, user support, and strategic leadership. Currently, these responsibilities are either missing or assigned to maintainers alongside their technical work. This isn't sustainable and explains why many crucial projects struggle to scale.
Shaping Open Source
There's never been a better time to contribute to open source. As AI makes code generation increasingly automated, the human skills that projects have been lacking become critically important.
In an increasingly uncertain work landscape, open source offers something different: a model where your contributions speak louder than your job title, where teams organize around impact rather than office politics, and where you can align with projects that genuinely matter to you. Open source has already proven that high-agency, distributed collaboration can produce remarkable results when people focus on merit rather than hierarchy.
Small contributions today can compound exponentially, just like my few hours designing a hexagon that millions now see daily. As traditional work structures continue to evolve, the open source approach to organizing productive work may become increasingly relevant. Now is the time to invest in this compounding value. Instead of waiting to see what happens, we can shape our future by shaping open source—and it starts with a simple willingness to contribute, no matter how small.
Impact Over Metrics
Even after writing this entire article about non-code contributions, I hesitate to call myself a "contributor" - a few hours designing a logo while others spend nights maintaining projects? If you're thinking, "I could never contribute enough to matter," you're feeling exactly what I still feel.
We often obsess over the wrong metrics when, in reality, real impact comes from simplifying, not adding complexity. My few hours designing that hexagon now appear in millions of developers' IDEs daily—that taught me more about meaningful contribution than any GitHub streak could.
You don't need to be a full-time maintainer to contribute meaningfully. Find an open source project that needs your skills and ask how you can help. Take one task from their overwhelming to-do list. Small contributions matter more than contribution graphs.
Here is a guide to get you started: How to Contribute to Open Source.
Community and Commitment
None of this would have happened without the ESLint team—Nicholas C. Zakas (@nzakas), Alberto Rodriguez (@alberto), Burak Yiğit Kaya (@BYK), Ilya Volodin (@ilyavolodin), Kai Cataldo (@kaicataldo), Kevin Partington (@platinumazure), Mark Pedrotti (@pedrottimark), Michael Ficarra (@michaelficarra), and others—welcoming my offer to help.
When maintainers welcome non-traditional contributors, they do more than improve their projects—they expand the entire open source community by showing that everyone has something valuable to offer.
Inspired by that experience, I've made a commitment to contribute more actively to open source, creating and sharing projects that others can learn from and build upon.
To all maintainers: your work matters more than you know. Every time you welcome a non-traditional contributor, you're expanding what's possible for someone else. Thank you for building systems that reward human agency.