Skip to main content

Bet on the little guy

3 min read
: On the internet, simple and open formats always win. From HTTP to JSON to Markdown, the lightweight underdog consistently defeats its heavyweight, proprietary rival.

When one tells the story of the internet, a David and Goliath motif emerges. Every time a technical challenged is faced, a new standard is needed, or a new design pattern takes center stage, two camps eventually emerge:

  • One camp, generally constituting more “enterprise” users, needs super serious tools for super serious business. This could be big business or big data. Doesn’t matter. If the new file format can’t scale to a million records on day one, well then, to them, it’s not a format.

  • The other camp, the hackers, are the little guys. They prefer to start small — to take existing, proven methods, things that are already baked into the patchwork that is the internet — and co-opt them to rise to this new cause.

We saw this in the early days of the internet when every new service would pick its own port and protocol, rather than using HTTP, which we eventually realized was the only sane way to go. We see this more recently with XML giving way to JSON as the internet’s lingua franca, with SOAP’s craziness yielding to REST’s simplicity. The list goes on. Complex, heavyweight approaches that may be elegant on paper gain traction early on as proprietary or custom-built solutions, but eventually a dumber standard emerges as the true winner. To name a few:

  • Everything → HTTP
  • XML → JSON
  • SOAP → REST
  • SAML → OAuth
  • Adobe PDF, Microsoft Word → Markdown
  • ESRI Shapefile, Google KML → GeoJSON, TopoJSON

The internet is fundamentally a different animal from the desktop, both culturally and technically. Interoperability reigns supreme. Sure, many complex formats were first-out-the-gate to tackle a problem, and they did it well. Today however, with the abundance of smarter tools, we don’t need that complexity at the core. Microsoft Word is great for making paper, but things like Markdown and HTML are quickly becoming the .docs of the web. What lessons can we learn from the “winning” solutions?

  • Open > Closed, Simple > Complex, Pragmatic > Perfect
  • Dumb formats, smart tools
  • Easier to upgrade a tool than a standard, experimentation is key
  • No APIs to learn, no SDKs to install, no licenses to buy

Complexity only serves to raise the barrier to communicate and goes against the very purpose of the internet: connecting things. Look to the formats that don’t have the 40 page PDF’d white papers. The ones that weren’t “opened.” The ones that don’t need SDKs or APIs just to function. If you can’t open it in a text editor, don’t trust it.

Bet on the little guys. On the internet, they have a tendency to win.

Originally published July 2, 2013 View revision history
Share

More to explore

Word versus Markdown: more than mere semantics

5 min read

How we consume content has changed dramatically over the past 30 years, yet how we author content remains relatively unchanged. Markdown forces you to write for the web.

Open source, not just software anymore

8 min read

Open source has always been about the right to modify, not the right to contribute. As those workflows spread beyond software, we may need a new word for what we're really doing.

Seven ways to consistently ship great features

6 min read

The best developers I've worked with don't just write code. They over-communicate, write features before code, ship the smallest delta possible, and optimize for users over maintainability.

Open source is (not) insecure

5 min read

The idea that open source software is inherently less secure than its closed source or proprietary counterparts is untrue and stems from fear, uncertainty, and doubt (FUD).

Ben Balter

Ben Balter is the Director of Hubber Enablement within the Office of the COO at GitHub, the world's largest software development platform, ensuring all Hubbers can do their best (remote) work. Previously, he served as the Director of Technical Business Operations, and as Chief of Staff for Security, he managed the office of the Chief Security Officer, improving overall business effectiveness of the Security organization through portfolio management, strategy, planning, culture, and values. As a Staff Technical Program manager for Enterprise and Compliance, Ben managed GitHub's on-premises and SaaS enterprise offerings, and as the Senior Product Manager overseeing the platform's Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub's Product team, Ben served as GitHub's Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →

This page is open source Help improve this article on GitHub