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.

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
  2. On social coding: "I want people to use this for every reason... to extend the use cases for GitHub." — Source: TechCrunch
  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
  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
  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
  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
  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
  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
  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
  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

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
  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
  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
  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
  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
  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
  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
  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
  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
  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

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
  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
  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
  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
  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
  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
  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
  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
  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

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
  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
  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
  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
  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
  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
  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
  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
  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

Part 5: Readme Driven Development

  1. On flawed execution: "A perfect implementation of the wrong specification is worthless." — Source: Readme Driven Development
  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
  3. On undocumented perfection: "A beautifully crafted library with no documentation is also damn near worthless." — Source: Readme Driven Development
  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
  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
  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
  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
  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
  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

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
  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
  3. On version lock: "If the dependency specifications are too tight, you are in danger of version lock." — Source: SemVer Spec
  4. On version promiscuity: "If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity." — Source: SemVer Spec
  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
  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
  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
  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
  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

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
  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
  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
  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
  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
  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
  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
  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
  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
  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

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
  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
  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
  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
  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
  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
  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
  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
  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