158 posts
AI agents that write code, open pull requests, and fix bugs aren't replacing developers — they're extending the same patterns of transparency, code review, and collaboration that have made open source successful for decades.
When I joined GitHub in 2013, I found a company that had fundamentally rethought how work happens. Thirteen years later, the lessons from that experiment are more relevant than ever.
How to set up a free and open-source grammar, style, and spell checker that can be run locally on your machine without sending data to a third-party services like Grammarly, preserving the privacy of what you type.
Leaders often face push back when they make tough decisions. Trying to "control the narrative" by ignoring or shutting down dissent is a bad idea. It erodes trust, invites negativity, and stifles learning. A better approach is to be transparent, open, and accountable. This builds trust, invites positivity, and fosters learning.
The cathedral and the bazaar are two contrasting styles of people management, inspired by the open source movement. The cathedral style is more hierarchical, controlled, and standardized, while the bazaar style is more decentralized, autonomous, and collaborative.
Learn more about how we use GitHub to build GitHub, how we turned our guiding communications principles into prescriptive practices to manage our internal communications signal-to-noise ratio, and how you can contribute to the ongoing conversation.
How the andon principle from lean manufacturing can help you spot and solve critical issues early on and foster a culture of transparency and collaboration within the software development process by encouraging anyone to "stop the line" when necessary.
Remote work requires communicating more, less frequently, because asynchronous communication involves less frequent, but richer communication, meaning there is less time talking about the work and more time doing it, allowing the system to optimize for throughput and flow.
When authoring a pull request, use the body as an opportunity to document the proposed change, especially the "why", and cross link any related issues or other PRs to create a trail of breadcrumbs for future contributors.
When working as a distributed team, be mindful of cultural differences, time zones, encouraging breaks between meetings, and connecting as humans.
Default to transferring context asynchronously. Hold colleagues accountable for being async first. If you receive a meeting invite without context, an agenda, or a read-ahead doc, consider politely declining.
GitHub isn't just for software developers. If you're in a non-technical role, you can use GitHub to follow along, collaborate with your team, track your work, and share information. This brief guide includes everything you need to know to get started confidently with GitHub.
This is the template I use to prepare for an extended leave (or to hand off responsibilities as I transition to a new role).
If issues, pull requests, and project boards are the best way to develop software, should they not also be the best way to manage software development?
How to implement 404 - not found pages for Jekyll and GitHub pages that automatically suggest similar URLs to the one requested based on your site's sitemap.xml.
Asynchronous work allows for remote work that's enjoyable and that actually works. Async increases inclusivity, produces better outcomes faster, encourages discoverability and permanence of context, creates space for learning, shifts knowledge workers to higher value work, improves work-life balance, empowers distributed teams, and enables parallelization and flow.
Chiefs of Staff manage the office of the CXO, improve organization effectiveness, solve problems without regard for organizational boundaries, manage the CXO's portfolio of responsibilities, shape organizational strategy and culture, serve as trusted counsel and advisor to the CXO, and manage the CXO and the organization's relationships and overall brand.
Absent working within systems that naturally capture and expose process, transparency takes effort. Leaders should hold one another accountable for spending the additional cycles to show their work through communicating not only what decision was made, but also how the decision was made, and why.
A customizable GitHub Action workflow that uses cURL, jq, and Twilio to notify you via text message when a web page or API response changes.
How I used Docker Compose, Ansible, and Caddy to re-over-engineer my UniFi Dream Machine, PiHole/AdGuard Home, and Cloudflare-based home network for ease of setup, maintenance, and management.
As open source projects grow, maintainers' most pressing challenges often shift from the technical to the administrative as they transition from managing code to managing a community of contributors.
Successful open source projects create a welcoming community by fostering productive conversations, promoting healthy collaboration, and de-escalating conflict when things get heated or off topic.
As your open source project grows, here are some practical steps you can take to help operationalize common governance decisions.
Technical Program Managers are responsible for communication, coordination, and facilitation, capturing and tracking the work that needs to be done, identifying, analyzing, and mitigating program risk, reporting up and across, managing relationships, resolving conflict, driving consensus, boundaryless engagement, and doing what needs to be done.
Reflecting on eight years of shipping at GitHub with a look at some of my most impactful ships.
If you're starting (or preparing for an interview) at GitHub, here are a few of my favorite posts to help you understand how GitHub works, its culture and communication patterns, and what it's like to be a GitHubber.
Analysis of what technologies power federal .gov websites - 2021 edition.
How I used a UniFi Dream Machine, VLANs to segment IoT, Pi-Hole to block ads, cloudflared for DNS over HTTPS, and Cloudflare Gateway to block malware/phishing to (over) optimize my home network for privacy and security.
Today marks ten years since my first post. Here's a look at my most viewed posts over the past ten years.
Trust and safety (abuse protection) is a critical part of your product, and it's a cost of doing business on the internet. It's a hidden "internet tax" that you'll need to pay, whether you want to or not.
I use web notifications for everything but @mentions, which I have pushed to me via email. I subscribe to lots of repositories to ensure I don't miss anything, but unsubscribe from any thread not immediately relevant to me to keep noise to a minimum. I also have a few tools I've built to customize GitHub notifications for the way I work.
How I think about the tools we use to communicate at GitHub across issues, projects, discussions, documentation, Google Docs, Slack, Zoom and in-person meetings, and email.
Successful open source projects rely heavily on automation to implement and enforce community workflows and to make contributing a more self-serve experience.
Successful open source projects do everything they can to set users up for success, well before that user interacts with their project for the first time.
When embracing remote work, you could have the best tools in the world, but without the necessary social norms, you're setting yourself up for failure. Here are eight cultural "rules" that represent the intangible of successful remote communication, regardless of your industry, your role, or what tools you use.
Most platforms offer some form of user blocking, user muting, or both. Here's a brief look at why GitHub has taken a bit of a unique approach to blocking that diverges from what you might see on other social networks and some of the special considerations that come as a result.
Lessons learned implementing a trust and safety framework for empowering open source maintainers to grow strong, semi-independent communities around shared technical challenges on GitHub.
With the new year upon us, I wrote down a few of my New Year's resolutions for sustaining and growing open source communities. How are you approaching open source differently in 2020?
In this talk from OSCON 2019, I walk through GitHub's approach to empowering maintainers to grow a federation of semi-independent, safe, and welcoming open source communities that can scale along side the code.
When joining an existing team as a Product Manager, you should tackle those tasks you know you need to tackle, build consensus around a shared product vision, and facilitate discovery for how you will get there.
How lawyers can adopt the workflows, tools, and philosophies of open source to make their legal practice more remote-friendly
When you're developing software, your job is to optimize for low-effort, high-impact initiatives that improve user experience and give you the best value in time and effort. The easiest way to do that is to focus on why you're doing things and who you're doing them for, counterbalanced by the effort required, not the other way around.
When responding to customer feature requests your answer should be in the form of "we're doing that", "we're not doing that", or "we might do that".
Contributor license agreements (a "nice to have" for many corporate-backed open source projects) create a contribution-hostile developer experience, require significant administrative overhead, shift legal blame to the party least equipped to defend against it, and are unnecessary given modern development tools.
There's lots of internet lore around open source licensing. As an attorney and an open source developer, here's my answers to common open source licensing questions.
After more than ten years maintaining open source projects, and now helping other maintainers to do the same, here's twelve things I've learned about growing healthy, vibrant communities around your open source project.
The hardest part of software development is not coming up with features to build, but instead, deciding what features will have the biggest impact.
Developers that I see consistently shipping great, user-centric features over communicate; write features first, then code; get it in users' hands, not on main; ship the smallest delta possible; appreciate that "Next iteration" doesn't mean "never"; always open issues; and optimize for users.
Your project README doesn't just communicate the "what" and "how", it communicates the "why", and serves as your most effective tool to combat open source scope creep and technical debt.
With GitHub's protected branches feature, you can grant collaborators permission to moderate comments, manage issues, or serve as project managers/team leads without the ability to merge pull requests or commit to master.
Celebrating everyday occurrences show others that you appreciate them as individuals and makes your workplace a better place to work
A bikeshed honeypot is an obvious flaw that you place in a proposal in hopes that others will fixate on the honeypot, diverting their attention from the aspects you feel more strongly about.
How I customize the hackable Atom text editor for writing prose and Markdown.
A short list of tips and tricks I offer to new employees when they join GitHub. Specifically, ship something in your first two weeks; spend your first month learning how to learn and how we communicate; about one month in you'll get overwhelmed; the challenge is in deciding what not to do; GitHub wants you to grow and learn; just do it; professional, not formal; and share your past experiences, but be prepared to unlearn things.
GitHub has a unique work culture. Here are seven traits that I've observed in successful GitHubbers over the years that I think make GitHubbers more effective. Specifically, professional, but not formal; ship early, ship often; if you see something, say something; curiosity and self-improvement; always be willing to help; contribute to the appreciation economy; and honesty, integrity, and authenticity.
When building a product, strive to absorb complexity on behalf of users, build features 80% of users will use, drink your champagne, optimize for the ideal use case, not the most common, let the user make the change, always provide an out, be as lean as possible, iterate, iterate, iterate, push logic to the edges, and be transparent.
Unless absolutely required, avoid custom, modified, or non-standard open source licenses, which will serve as a barrier to downstream use of your code.
Features aren't what make a product great. Being the best at solving a particular problem does. Every time you remove a feature that doesn't support your product's core use case, you're actually adding an implicit feature that does.
I've read quite a few books over the years about technology, open source, and business. Here are some of my favorite.
Product managers aren't allowed to have excuses, serve as team captain and user advocate, prioritize and sequence, communicate, coordinate, and facilitate, solve for what the customer's underlying needs, ensure the team ships v0.1 not v1.0, don't confuse urgent or measurable with important, capture every idea in an issue backlog, conduct research and strategic thinking, and keep up with industry trends
If you're about to open a controversial (or wide-reaching) issue or pull request, there are a handful of steps you can take to set yourself up for success.
The White House Open Source Policy is an opportunity to fold the map in half, and bring the innovation of Silicon Valley a bit closer to the Beltway. Limiting the impact of open source to a time- and scope-constrained pilot unduly delays a unique and long-needed opportunity to modernize government.
In product development, it's all too easy to optimize for power users and edge cases. The real challenge lies in nailing the out-of-box experience for 80% of users' needs.
How a WWII field manual can help modern knowledge workers identify those inadvertently sabotaging your organization today.
Whether collaborating on code, data, or prose text, there are lots of different strategies for using pull requests on GitHub. Specifically, just a heads up, sanity check, work in progress (WIP), early feedback, line-by-line review, and pull request to a pull request.
Open source has become somewhat of a Yelp for software, and with it, has the potential to shift the balance of power from software publishers to software consumers.
Twenty five microeconomic, macroeconomic, moral, transparency, participatory, and personal motivations why you and your organization should consume, publish, contribute to, and support open source.
Today, open-source-inspired collaboration tools are open, linkable, asynchronous, and naturally capture and expose process. Ask yourself if you're working the way you'd like to work, or just the way everyone else does.
By naturally capturing and exposing process and sharing it as widely as is appropriate for the subject matter, URLs render organizational context time and location agnostic allowing knowledge to move more freely within an organization on an asynchronous, discoverable, and opt-in basis.
Change aversion, lack of technocratic leadership, and heavyweight processes bred by distrust keep government IT 5-10 years behind the private sector
How open source workflows and philosophies can be leveraged by the enterprise to produce more modern software, even if that software ultimately remains closed source.
If you host your site on GitHub or GitHub Pages, an edit button (and thus encouraging collaboration around your content) is simply a matter of linking to an easily predictable URL.
Encourage proper voice, tone, and style by adding automated tests to your corporate blog.
Nearly three years later, the founding principles of project MyGov remain valid guideposts for any reform effort in government.
Whether you call it taste, culture, or zen, there are underlying assumptions that members of an organization rely on to resolve ambiguity in pursuit of the organization's mission.
Blog posts are a great way to tell users about ships, but it's all too easy to fall back on the marketing speak we're inundated with each day. Instead, use these tips to write user-centric posts for your corporate blog.
What IT procurement might look like, in a world in which government agencies adopt open source methodologies as their primary means of development
There is an emerging anti-pattern, whereby organizations review and discuss issues and pull requests in regularly scheduled, closed meetings, a practice that almost certainly sets the project up for failure.
GitHub is a great place to share your work with the world, but sometimes large organization wish to brand or showcase their open source efforts in ways that the standard profile page doesn't allow. That's where GitHub Pages comes in.
What is the appropriate copyright notice for opens source projects? Who is the copyright holder? What year(s) should you put? Do you even need a copyright notice in the first place?
There's another workflow that version-controlled, collaborative content enables: continuous integration for prose.
A quick analysis of the technology and capabilities that power each federal.gov domain such as non-www, SSL, and IPv6 support, or what server/cms they use
Believe it or not, just over a year ago, GitHub Pages, the documentation hosting service that powers nearly three-quarters of a million sites, was little more than a 100-line shell script. Today, it's a fully independent, feature-rich OAuth application that effortlessly handles well over a quarter million requests per minute. We wanted to take a look back at what we learned from leveling up the service over a six month period.
Two parallel efforts at modernizing the way government approaches technology are taking foothold in the Beltway: 18F and the U.S. Digital Service (USDS)
If you want to attract technical talent to your agency, focus on building an environment that supports innovation and innovators.
When it comes to open source, simply publishing code isn't enough. Open source is about fostering communities around shared challenges, and as the maintainer of an open source project, that responsibility falls squarely on your shoulders. Go out of your way to encourage, praise, and support each contributor and each contribution as if the project's success depended on it, because in reality, it does.
The way your organization works internally will necessarily be a mirror image of how your organization works externally, and if that workflow is closed or untrusting, you'll likely have trouble embracing to open source
Collections extends Jekyll's post and pages publishing functionality, and brings Jekyll's zen-like simplicity to all sorts of other types of content that aren't dated, but have a relationship with one another.
Best practices suggest that you should prime organizational pistons with an open source exercise, before you embark on your first highly publicized open source effort
Word Diff empowers you to be a Markdown person in a Microsoft Word world by automatically converting Word documents to Markdown each time you commit to GitHub, where they can be diffed, versioned, and collaborated on internally.
A quick glance at someone's laptop can tell you a lot about that person and their employer.
Federal-compatible Terms of Service (TOS) agreements are special agreements negotiated between the federal government and vendors who offer free social media, mobile, business and other digital tools. These federal-compatible TOS agreements modify or remove problematic clauses in standard TOS agreements, and allow federal employees to legally use these tools. With nearly 2.75mm federal government employees, learn how to get your foot in the door to an increasingly interested market segment.
14 simple apps to introduce open source to the uninitiated, lower the barrier to entry for atypical GitHub users to get started, and to show the power of adding smart tools to the edge of an otherwise dumb platform.
HTTPS ensures not only the privacy of the content you request, but also, protects the fact that you're even requesting it in the first place. HTTPS isn't just for secure transactions like online banking and e-commerce. HTTPS is for any website that adds to the public dialog.
There are two types of change agents in the open government/data/source community: geeks and suits, but despite being in an industry built almost exclusively on communications, they never talk to each other
When it comes to innovation in government, there's the law, and then there's the myth that surrounds it, a myth used to place never-ending bureaucratic obstacles in front of those who champion change.
As a geek, as a former government technologist, and as a life-long member of the open source community, here's three things I hope the White House Open Source Policy embodies.
Asynchronous communication through high-fidelity mediums like issues and chat eliminate the endemic "you had to be there" aspect of most corporate workflows, and reduces the need for a dedicated management class to capture, collect, and shuttle information back and forth between business units.
The Government Evangelist role at GitHub is about helping government agencies to ship software better, to fold the map in half, and bring the West coast a bit closer to the East coast.
There's been a lot of great momentum generated from the policy side, giving the geeks the environment they need to do what they do best, but that's just the start.
Government contractors have traditionally been slow to embrace open source software. Here's why government contractors are embracing open source with increasing frequency.
A high-level overview to highlight common legal issues government agencies may face when participating in the open source community
The next time you begin a new project, adopt a high-fidelity, electronic medium that allows you to capture and expose process in the form of a URL.
Agencies that simply publish code with no intention to foster community involvement, curate community feedback, or accept community contributions find themselves, almost without exception, engaging in an unsuccessful endeavor.
I've seen multi-million dollar contracts in government, the final deliverable for which, is a CD-ROM, in triplicate. That's not how modern software development works, and our code deserves better.
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).
Moving from the federal government, arguably the most bureaucratic organization in the history of the world, to GitHub, arguably one of the world's least bureaucratic, I learned that there were three key organizational differences beyond mere size and the lack of TPS reports.
Taxpayer funded code is often not open source because government prefers closed platforms, is inexperienced with open source workflows and culture, and creates software as part of a predominantly closed-source supply-chain.
The government's new FedRAMP requirements — intended to make it easier for federal agencies to make the jump to the cloud — actually make it significantly harder for agencies to keep pace with the private sector.
A quick analysis of the technology and capabilities that power each federal domain such as non-www, SSL, and IPv6 support, or what server/cms they use
Open source provides us with a handful of built in metrics to gauge a project's quality, even without reading a single line of code
As technology allows us to communicate with greater frequency and greater fidelity, we have the chance to make our government not only transparent, but truly collaborative.
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.
The key to innovation in government is engendering a greater appreciation of technology among non-technical stakeholders
Encourage deep-linking of content by providing anchor links when a user hovers over a heading in your Jekyll posts and pages
What we've been calling open source, may in fact be something else, especially when we start to use those workflows to collaborate on things beyond code.
The next time you publish a data source, whether in government or out, ask yourself one simple question. How can you optimize the experience for the data consumer?
The internet forces us to reimagine desktop technologies as vehicles for collaboration.
By choosing a static architecture over a more complex one for government.github.com, technology became a given, and we were able to iterate on improving the content itself,
The challenges we faced were overwhelmingly administrative, cultural and bureaucratic in nature. Here are 10 things I know now I wish I had known then.
It's time we start treating data with the same love and respect that geeks treat their code.
Minimizing friction (time to first commit) is essential to building a strong open source community
We often think of contributors as developers, but code is just one of the many ways to contribute to an open source project, and it's important to provide avenues of participation for non-technical contributors as well.
On the Internet, simple, open format reign supreme over their heavyweight, proprietary counterparts
Tools aren't the challenge, culture is. We should make it so ridiculously straightforward for government agencies to distribute information and build collaborative communities around shared problems that it would be criminal for them not to.
An automated process for converting ESRI Shapefiles to .geojson map files so that they can be more easily used with GitHub.com
Government CIOs should seek to build systems in a lean, iterative, decentralized, and open way
We should work to remedy the underlying culture, not its symptoms.
Developers should be experts at solving users' problems, not a particular language or technology
Countless technologies we take for granted today, began their lives as staples of the open-source development workflow
Hackers embody sharing, openness, decentralization — coding to improve the world
There are many aspects to 'making things' that open source just does better, and does so without traditional management structure.
To position itself in the context of next-generation CMSs, WordPress should conform to emerging internet conventions and expose all content via a RESTful API
If the internet is the primary medium by which content is consumed, shouldn't that be the primary medium for which content is prepared?
Open source, at its core, is actually not about code, but about connecting people around a shared vision to encourage collaborative problem solving.
Jekyll (and other static-sites) lead to simple, flexible, and reliable websites that allow for a renewed focus on what actually matters: the content.
The question for developers isn't how should the US government best license software, but how can the open source community help it to do so
When building consumer applications, favor simplicity over complex personalized dashboards which bombard customers with information.
When you are the only person that's ever going to see something, you're a lot more likely to "just make it work. Therefore write open source
Despite increasing public support (as well as a number of executive mandates) publishing public data in a machine-readable format is not as simple as pressing the "publish" button. Why? Equally important as exposing the information itself is fostering a vibrant developer ecosystem around it. By making the publishing agency, not the public, responsible for making information immediately useful, government can lower the barriers associated with consuming its data and introduce additional citizen services at little to no cost to the agency.
Today countless teams are using WordPress to drive collaboration and facilitate inter-team communication. Ben Balter will showcase some of the creative ways companies and organizations are using WordPress as the central hub of their day-to-day workflow: To organize and collaboratively edit documents and other non-web content, track and communicate their team's progress with one another, and extend WordPress to work with their existing tools and practices.
80% of enterprise uses open source; 2/3 contribute code upstream; and 1 in 4 have detrimental open source policy.
The Consumer Financial Protection Bureau (CFPB) accepted the first pull request by a member of the public to a US Federal government agency
The Consumer Financial Protection Bureau's (CFPB) new open source policy is a great start, but should go further
Among potential government and enterprise users, WordPress has a perception problem especially when compared to Drupal and other "serious" CMSs.
PHP (and the open-source software it powers) often gets a bad rap in many government and enterprise circles, but much of this unfortunate stereotype is the result of carefully crafted fear, uncertainty, and doubt (FUD).
Making the case for a GitHub-style, pull-request collaboration model within the popular WordPress CMS
A list of open-source alternatives to popular proprietary enterprise software solutions
By requiring that detailed specifications be outlined at the onset of the process, government procurement regulations encourage the less flexible, waterfall development techniques, rather than the more modern, agile development approaches used by the private sector today.
Increasingly slim federal IT budgets are best optimized by a concerted effort at realigning organization values around more agile approaches to software development
It's because you're not providing them the right opportunity. The talent you want would be happy to work in an un-air-conditioned garage in New Mexico if it meant the chance to change the world.
WP Document Revisions gained a huge feature today with the addition of integrated support for the popular workflow plugin Edit Flow
Analysis of the technical capabilities of and technology powering all US Federal Executive .gov domains
WordPress is different. WordPress is about content. WordPress is about simplicity. Out of the box, it's a clean, lean, and mean semantic publishing platform that makes broadcasting your ideas as effortless as possible.
Firms looking to seek a competitive advantage will begin to look past "it has to be expensive and complicated" and start looking toward open-source software, not as a misfit alternative, but as a viable player in the software space, but before that can happen the open-source community must strive to be the serious competitor they wish to be treated as.
WP Document Revisions is a document management and version control plugin for the popular content management system, WordPress. Think of it as an open-source and more intuitive version of the popular Microsoft collaboration suite, Sharepoint.
A workflow management and version control system building on WordPress's existing core competencies. By treating documents as a custom post type, users can leverage the power of WordPress's extensive attachment, revision, taxonomy, and URL rewriting functionalities.