Jekyll: Where content is truly king
GitHub recently launched government.github.com, a site dedicated to showcasing the efforts of public servants and civic hackers which, despite its technical simplicity, was more than six months in the making, a relative snail’s pace by any startup’s standards. By choosing a static architecture over a more complex one, technology became a given, and rather than iterating on challenges to sharing information, we were able to iterate on improving the content itself, which in the end fundamentally shifted the site’s focus and overall user experience.
Had we chosen to go the traditional WordPress, Rails, or really, any other route, we would have been distracted by and had been forced to dedicate a significant portion of our time to just getting things to work. Are the permissions right for this post? Is the SEO plugin working properly? Will it scale as expected on launch day? That’s all just technical noise, noise not even remotely necessary in many cases.
Instead, Jekyll, the static site generator baked directly into GitHub Pages, introduced a level of zen-like simplicity, that allowed us to focus on one thing and one thing only: content. Are we solving for the right thing here? Can we word this better? Is this line absolutely necessary? We knew it was going to work, so we were able to move on to more important things.
But there was another major advantage. By treating the content as code, we suddenly empowered ourselves to use a more evolved editorial workflow. Forks, pull requests, a running list of issues… the content truly was an open source project in itself, and as we close in on nearly 100 contributors, the content is only getting better each day.
Open source is about tackling shared challenges together; there’s no reason the philosophy need be limited to just code, and with dumb-simple tools like Jekyll which not only empower such workflows, but also free you up to focus on what matters, there’s no excuse for content not being king.
If you enjoyed this post, you might also enjoy:
- Why open source
- How to make a product great
- Why everything should have a URL
- Five best practices in open source: external engagement
- 15 rules for communicating at GitHub
- Twelve tips for growing communities around your open source project
- 19 reasons why technologists don't want to work at your government agency
- Open source, not just software anymore
- Four characteristics of modern collaboration tools
- Leaders show their work
- Eight things I wish I knew my first week at GitHub
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. Please help improve it.
Edit