> ## Content Index
> Fetch the complete content index at: https://www.antoinebuteau.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Lessons from Tom Preston-Werner
- URL: https://www.antoinebuteau.com/lessons-from-tom-preston-werner/
- Published: 2026-05-26T23:05:02.000Z
- Updated: 2026-09-05T03:07:56.000Z
- Description: Tom Preston-Werner co-founded GitHub, popularized the pull request, and created Jekyll, Semantic Versioning, TOML, and RedwoodJS. His path clarifies how bootstrapping, open infrastructure, and clear interfaces can reshape collaborative software development for generations of teams.
- Author: Antoine Buteau
- Tags: Profile, Tech Entrepreneurs & Founders Profiles

Tom Preston-Werner co-founded GitHub, popularizing the pull request and shifting how software is built collaboratively. He is also the creator of Jekyll, Semantic Versioning, and TOML, and more recently, the full-stack framework RedwoodJS. This profile gathers his practical insights on bootstrapping, open-sourcing infrastructure, and designing clear interfaces.

![Visual summary of operating lessons from Tom Preston-Werner.](https://www.antoinebuteau.com/content/images/2026/05/lessons-from-tom-preston-werner-profile-infographic.webp)

## Part 1: Founding GitHub and Building a Community

1. **On the Wikipedia analogy:** "You could think of GitHub as a bit like Wikipedia in that you have a bunch of people coming together, working on the same document, to make it better." — [*Source: Mixergy*](https://mixergy.com/?ref=antoinebuteau.com)
2. **On social coding:** "I want people to use this for every reason... to extend the use cases for GitHub." — [*Source: TechCrunch*](https://techcrunch.com/?ref=antoinebuteau.com)
3. **On the resume of the future:** "People want to know not where have you worked or what have you worked on there. They want to know what open source projects have you worked on and can I see your code." — [*Source: GitHub Developer Recruitment*](https://github.blog/?ref=antoinebuteau.com)
4. **On trust vs. micromanagement:** "Micromanagement is symptomatic of a lack of trust. The remedy for this ailment is to hire experts and then trust their judgment." — [*Source: Tom's Blog*](https://tom.preston-werner.com/?ref=antoinebuteau.com)
5. **On early community authenticity:** "Building that core group of 'True Believers' was possible because we were authentic... it didn't feel like some big company that was doing it to make a bunch of money." — [*Source: Mixergy*](https://mixergy.com/?ref=antoinebuteau.com)
6. **On starting early:** "By choosing to build early on top of a nascent technology \[Git\], we were able to construct a startup with basically no overhead, no competition, and in our free time." — [*Source: Tom's Blog*](https://tom.preston-werner.com/?ref=antoinebuteau.com)
7. **On the adventure of life:** "When I'm old and dying, I plan to look back on my life and say 'wow, that was an adventure,' not 'wow, I sure felt safe.'" — [*Source: Tom's Blog*](https://tom.preston-werner.com/2008/10/18/how-i-turned-down-300k.html?ref=antoinebuteau.com)
8. **On rejecting corporate stability:** He chose to decline a $300,000 offer from Microsoft to fully commit to bootstrapping GitHub, prioritizing ownership and control over a guaranteed high salary. — [*Source: Tom's Blog*](https://tom.preston-werner.com/2008/10/18/how-i-turned-down-300k.html?ref=antoinebuteau.com)
9. **On taking investment:** When GitHub eventually took VC funding, it was specifically to partner with Andreessen Horowitz on scaling operations, not out of a need for survival. — [*Source: GitHub Blog*](https://github.blog/2012-07-09-investing-in-github/?ref=antoinebuteau.com)
10. **On testing in production:** Testing new code against the entire user base is risky, making feature flags and canary deployments essential for successfully scaling software. — [*Source: Chatterbug Insights*](https://youtube.com/?ref=antoinebuteau.com)

## Part 2: "Optimize for Happiness" and Bootstrapping

1. **On venture capital incentives:** "VCs want to see quick success or quick failure. They are optimizing for money." — [*Source: Optimize for Happiness*](https://tom.preston-werner.com/2010/10/18/optimize-for-happiness.html?ref=antoinebuteau.com)
2. **On defining your own success:** "If you're like me, then you care more about building a kickass product than you do about having a ten-figure exit." — [*Source: Optimize for Happiness*](https://tom.preston-werner.com/2010/10/18/optimize-for-happiness.html?ref=antoinebuteau.com)
3. **On the core metric:** Rather than relentlessly chasing revenue, founders should measure their company's success by asking if they are actually optimizing for happiness. — [*Source: Optimize for Happiness*](https://tom.preston-werner.com/2010/10/18/optimize-for-happiness.html?ref=antoinebuteau.com)
4. **On infinite runway:** "One way to do this is by bootstrapping a sustainable business with infinite runway. When there are fewer potentially catastrophic events on the horizon, you'll find yourself smiling a lot more often." — [*Source: Optimize for Happiness*](https://tom.preston-werner.com/2010/10/18/optimize-for-happiness.html?ref=antoinebuteau.com)
5. **On the benefit of scarcity:** Not making a lot of money early on forces a team to be more clever and deliberate in their technical and product decisions. — [*Source: Mixergy*](https://mixergy.com/?ref=antoinebuteau.com)
6. **On survival:** "If you're bootstrapped, your customers' happiness with what you offer is the only thing that will keep your business alive." — [*Source: Optimize for Happiness*](https://tom.preston-werner.com/2010/10/18/optimize-for-happiness.html?ref=antoinebuteau.com)
7. **On internal morale:** "Making your customers happy also makes for a happy support team that don't have to handle too many angry tickets!" — [*Source: Optimize for Happiness*](https://tom.preston-werner.com/2010/10/18/optimize-for-happiness.html?ref=antoinebuteau.com)
8. **On continuous iteration:** "Never lose focus on the product. Always be iterating. Always compare to the best of the best and be better." — [*Source: Optimize for Happiness*](https://tom.preston-werner.com/2010/10/18/optimize-for-happiness.html?ref=antoinebuteau.com)
9. **On company culture:** Employee well-being should be prioritized directly, creating an environment where the team actually enjoys the software they build. — [*Source: Optimize for Happiness*](https://tom.preston-werner.com/2010/10/18/optimize-for-happiness.html?ref=antoinebuteau.com)
10. **On early autonomy:** Avoiding outside funding in the early days allows a founding team to maintain complete control over the product direction and culture. — [*Source: Optimize for Happiness*](https://tom.preston-werner.com/2010/10/18/optimize-for-happiness.html?ref=antoinebuteau.com)

## Part 3: The Philosophy of Open Source

1. **On open-sourcing defaults:** Companies should open-source almost everything they build, from general-purpose tools to infrastructure libraries. — [*Source: Open Source (Almost) Everything*](https://tom.preston-werner.com/2011/11/22/open-source-everything.html?ref=antoinebuteau.com)
2. **On the "secret sauce":** The only code a business must keep closed is the specific logic or data that provides a direct competitive advantage or compromises security. — [*Source: Open Source (Almost) Everything*](https://tom.preston-werner.com/2011/11/22/open-source-everything.html?ref=antoinebuteau.com)
3. **On public code quality:** Developers naturally write cleaner, more modular, and better-documented code when they know the public will be scrutinizing it. — [*Source: Fast Company*](https://fastcompany.com/?ref=antoinebuteau.com)
4. **On the force multiplier:** Open-sourcing projects allows a global community to spot bugs and suggest features, effectively expanding an engineering team for free. — [*Source: GitHub Blog*](https://github.blog/?ref=antoinebuteau.com)
5. **On evaluating talent:** Open source functions as a living portfolio, allowing companies to evaluate a developer's real-world code quality before offering them a job. — [*Source: Hunter Walk Interview*](https://hunterwalk.com/?ref=antoinebuteau.com)
6. **On building superfans:** Releasing high-quality free tools creates massive goodwill, turning casual users into vocal advocates for a company's paid products. — [*Source: Tom's Blog*](https://tom.preston-werner.com/?ref=antoinebuteau.com)
7. **On moral obligation:** Because modern software relies heavily on existing open-source infrastructure, developers have a moral duty to give back and prevent duplicated effort. — [*Source: Open Source (Almost) Everything*](https://tom.preston-werner.com/2011/11/22/open-source-everything.html?ref=antoinebuteau.com)
8. **On the open source contributor:** "It's every person that has ever contributed to an open source project because they believe that when we work together and share our best accomplishments, we raise the bar." — [*Source: Hunter Walk Interview*](https://hunterwalk.com/?ref=antoinebuteau.com)
9. **On giving back:** "A single line of code written by an open source contributor could run trillions of times a year... without that developer ever earning a dollar for it." — [*Source: Hunter Walk Interview*](https://hunterwalk.com/?ref=antoinebuteau.com)

## Part 4: Treating Content Like Code (Jekyll & Git)

1. **On the hacker approach to blogging:** "While I'm not specifically trained as an author of prose, I am trained as an author of code. What would happen if I approached blogging from a software development perspective?" — [*Source: Blogging Like a Hacker*](https://tom.preston-werner.com/2008/11/17/blogging-like-a-hacker.html?ref=antoinebuteau.com)
2. **On using version control for prose:** "First, all my writing would be stored in a Git repository. This would ensure that I could try out different ideas and explore a variety of posts." — [*Source: Blogging Like a Hacker*](https://tom.preston-werner.com/2008/11/17/blogging-like-a-hacker.html?ref=antoinebuteau.com)
3. **On static site minimalism:** "Complexity would be kept to an absolute minimum, so a static site would be preferable to a dynamic site that required ongoing maintenance." — [*Source: Blogging Like a Hacker*](https://tom.preston-werner.com/2008/11/17/blogging-like-a-hacker.html?ref=antoinebuteau.com)
4. **On software entropy:** "It seems almost inevitable that software projects become more complicated over time. Unless simplicity is a core requirement, complex features are constantly added." — [*Source: Blogging Like a Hacker*](https://tom.preston-werner.com/2008/11/17/blogging-like-a-hacker.html?ref=antoinebuteau.com)
5. **On the value of writing:** "The act of transforming ideas into words is an amazingly efficient way to solidify and refine your thoughts about a given topic." — [*Source: Blogging Like a Hacker*](https://tom.preston-werner.com/2008/11/17/blogging-like-a-hacker.html?ref=antoinebuteau.com)
6. **On teaching Git:** "Most people try to teach Git by demonstrating a few dozen commands and then yelling 'tadaaaaa.' I believe this method is flawed." — [*Source: The Git Parable*](https://tom.preston-werner.com/2009/05/19/the-git-parable.html?ref=antoinebuteau.com)
7. **On mastering version control concepts:** "Until you understand the concepts upon which Git is built, you'll feel like a stranger in a foreign land." — [*Source: The Git Parable*](https://tom.preston-werner.com/2009/05/19/the-git-parable.html?ref=antoinebuteau.com)
8. **On frictionless branching:** "Creating new development branches has become so simple that you'll want to take advantage of it all the time... indeed it becomes possible to create a new branch for every feature you begin!" — [*Source: The Git Parable*](https://tom.preston-werner.com/2009/05/19/the-git-parable.html?ref=antoinebuteau.com)
9. **On Git's architecture:** At its core, Git is a beautifully simple, content-addressable filesystem that allows for an amazing wealth of functionality to spring into existence. — [*Source: The Git Parable*](https://tom.preston-werner.com/2009/05/19/the-git-parable.html?ref=antoinebuteau.com)

## Part 5: Readme Driven Development

1. **On flawed execution:** "A perfect implementation of the wrong specification is worthless." — [*Source: Readme Driven Development*](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html?ref=antoinebuteau.com)
2. **On writing before coding:** "Until you've written about your software, you have no idea what you'll be coding." — [*Source: Readme Driven Development*](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html?ref=antoinebuteau.com)
3. **On undocumented perfection:** "A beautifully crafted library with no documentation is also damn near worthless." — [*Source: Readme Driven Development*](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html?ref=antoinebuteau.com)
4. **On the specification middle ground:** "There must be some middle ground between reams of technical specifications and no specifications at all. And in fact there is. That middle ground is the humble Readme." — [*Source: Readme Driven Development*](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html?ref=antoinebuteau.com)
5. **On what a Readme requires:** It should contain a description of the project, clear examples of how to use it, and a list of the most important interfaces. — [*Source: Readme Driven Development*](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html?ref=antoinebuteau.com)
6. **On thinking through the API:** Writing the Readme first forces a developer to explicitly define the API and user experience before getting bogged down in backend implementation details. — [*Source: Readme Driven Development*](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html?ref=antoinebuteau.com)
7. **On identifying bad design:** If a feature is difficult to explain clearly in the Readme document, it is likely too complex or poorly designed in the code itself. — [*Source: Readme Driven Development*](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html?ref=antoinebuteau.com)
8. **On parallel workflows:** Once the Readme contract is established, frontend developers can immediately start building against the defined interface while the backend is still being written. — [*Source: Readme Driven Development*](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html?ref=antoinebuteau.com)
9. **On guaranteeing docs:** Writing documentation before the code prevents the common scenario where developers finish a project and are too exhausted to write instructions. — [*Source: Readme Driven Development*](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html?ref=antoinebuteau.com)

## Part 6: Creating Clear Standards (SemVer & TOML)

1. **On dependency hell:** "In the world of software management there exists a dread place called 'dependency hell.' The bigger your system grows... the more likely you are to find yourself, one day, in this pit of despair." — [*Source: SemVer Spec*](https://semver.org/?ref=antoinebuteau.com)
2. **On meaningful versioning:** "Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next." — [*Source: SemVer Spec*](https://semver.org/?ref=antoinebuteau.com)
3. **On version lock:** "If the dependency specifications are too tight, you are in danger of version lock." — [*Source: SemVer Spec*](https://semver.org/?ref=antoinebuteau.com)
4. **On version promiscuity:** "If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity." — [*Source: SemVer Spec*](https://semver.org/?ref=antoinebuteau.com)
5. **On predictable rules:** Semantic versioning functions as a simple, strict contract that dictates exactly how version numbers must be assigned and incremented. — [*Source: SemVer Spec*](https://semver.org/?ref=antoinebuteau.com)
6. **On major version anxiety:** Developers shouldn't be afraid to bump major version numbers; they are a communication tool for breaking changes, not a sacred milestone of completion. — [*Source: Tom's Blog*](https://tom.preston-werner.com/2022/05/23/major-version-numbers-are-not-sacred.html?ref=antoinebuteau.com)
7. **On clear configuration:** "TOML aims to be a minimal configuration file format that's easy to read due to obvious semantics." — [*Source: TOML Spec*](https://toml.io/?ref=antoinebuteau.com)
8. **On predictable data structures:** TOML was specifically designed to map unambiguously to a standard hash table, removing the parsing complexities associated with YAML. — [*Source: TOML Spec*](https://toml.io/?ref=antoinebuteau.com)
9. **On naivety as a strategy:** "Stay a bit naive of how everyone else does it just so that your solutions really are as novel as they can be." — [*Source: Whiskey Web and Whatnot Podcast*](https://podcasts.apple.com/us/podcast/whiskey-web-and-whatnot/id1552729990?ref=antoinebuteau.com)

## Part 7: The Journey to RedwoodJS

1. **On the two backends problem:** While building Chatterbug, the team found themselves maintaining both Rails controllers for the web and a GraphQL API for mobile, creating frustrating duplication. — [*Source: Full Stack Radio*](https://fullstackradio.com/?ref=antoinebuteau.com)
2. **On unified data:** Both web and mobile applications are just clients; maintaining separate data paths is inefficient and inevitably leads to inconsistencies. — [*Source: Full Stack Radio*](https://fullstackradio.com/?ref=antoinebuteau.com)
3. **On explicit code over magic:** Moving away from the hidden magic of Ruby metaprogramming, he embraced the explicit nature and predictable one-way data flow of React. — [*Source: React Podcast*](https://reactpodcast.com/?ref=antoinebuteau.com)
4. **On accidental framework creation:** Many engineering teams waste time essentially "building their own framework badly" by trying to manually glue React, GraphQL, and backend routing together. — [*Source: Syntax.fm*](https://syntax.fm/?ref=antoinebuteau.com)
5. **On the full-stack Jamstack:** RedwoodJS was created to fill the market gap for a framework that natively codified React frontend, GraphQL API, and serverless backends into one cohesive unit. — [*Source: Syntax.fm*](https://syntax.fm/?ref=antoinebuteau.com)
6. **On product-first architecture:** Startups spend too much time wiring infrastructure; frameworks should provide integrated defaults so engineers can focus strictly on the product. — [*Source: ShopTalk Show*](https://shoptalkshow.com/?ref=antoinebuteau.com)
7. **On framework design goals:** The overarching philosophy of RedwoodJS is simply to make the "easy things easy and hard things possible" for developers. — [*Source: Syntax.fm*](https://syntax.fm/?ref=antoinebuteau.com)
8. **On decision fatigue:** By choosing Prisma, GraphQL, and strict directory structures out of the box, the framework intentionally reduces the setup fatigue that plagues the React ecosystem. — [*Source: ShopTalk Show*](https://shoptalkshow.com/?ref=antoinebuteau.com)
9. **On modern conventions:** RedwoodJS aims to be the "Rails for the JavaScript age," applying the lessons of convention-over-configuration to a fully decoupled architecture. — [*Source: Frontend First*](https://frontendfirst.fm/?ref=antoinebuteau.com)
10. **On developer experience:** Frameworks must define a clear "happy path" that natively includes authentication, testing, and database migrations from day one. — [*Source: React Podcast*](https://reactpodcast.com/?ref=antoinebuteau.com)

## Part 8: Investing and Systemic Change (Preston-Werner Ventures)

1. **On venture fund design:** Preston-Werner Ventures operates on the principle of being exactly "the venture firm we wish we’d had early in our startup journeys." — [*Source: Preston-Werner Ventures*](https://pwv.com/?ref=antoinebuteau.com)
2. **On founder-led capital:** They prioritize a hands-on approach, ensuring the fund is led by active founder-operators who provide deep technical guidance rather than just capital. — [*Source: Preston-Werner Ventures*](https://pwv.com/?ref=antoinebuteau.com)
3. **On portfolio networks:** There is immense value in community; connecting hundreds of founders through shared knowledge platforms accelerates mutual growth. — [*Source: Preston-Werner Ventures*](https://pwv.com/?ref=antoinebuteau.com)
4. **On human-centered tech:** The fund specifically seeks out category-defining companies that successfully translate frontier science into practical, user-facing products. — [*Source: Preston-Werner Ventures*](https://pwv.com/?ref=antoinebuteau.com)
5. **On climate moral imperatives:** Through the 128 Collective, they view the climate crisis fundamentally through the lens of inequity and moral obligation. — [*Source: 128 Collective*](https://128collective.org/?ref=antoinebuteau.com)
6. **On systemic climate solutions:** Rejecting pure tech "silver bullets," their foundation prioritizes policy, advocacy, and democratic public control of the clean energy transition. — [*Source: 128 Collective*](https://128collective.org/?ref=antoinebuteau.com)
7. **On questioning market forces:** They actively challenge the assumption that purely market-based solutions alone can rapidly or fairly solve global systemic issues. — [*Source: InfluenceWatch*](https://www.influencewatch.org/?ref=antoinebuteau.com)
8. **On backing rule-breakers:** Across both software and climate philanthropy, the core thesis is to empower founders who are willing to rewrite the rules to build an equitable future. — [*Source: Preston-Werner Ventures*](https://pwv.com/?ref=antoinebuteau.com)
9. **On wealth distribution:** By signing the Giving Pledge, the Preston-Werners committed the majority of their wealth to explicitly fund progressive systemic change and climate justice. — [*Source: 128 Collective*](https://128collective.org/?ref=antoinebuteau.com)