Hope for GitHub Pages

Short version

  • “+1” for Apereo adoption of GitHub Pages for this website.
  • I’m hopeful for applying this approach beyond blogging.
  • Static site generators have lots of advantages. Those advantages align with Apereo values and realities.
  • Call to action to use GitHub Pages more and better and thereby make Apereo websites better.


I’m really excited and supportive about Apereo’s adopting GitHub Pages for this website, and I’m hopeful about using it for more than just a blog.

Not only do I concur that this is a good idea,

(Which is to say, “+1”, in Apache parlance.)

Advantages of static site generator websites

Jekyll-driven GitHub Pages has tremendous advantages aligned with Apereo values and operations.

  • Driving the website by a public Git repository improves transparency. It means anyone can inspect the content and history of the site to understand just what is being said and the history of saying it. And anyone can inspect the program that generates the site from the content files. Not just the open source technology used in the abstract - the specific configuration, instantiation of that automation.
  • Driving the website by a public GitHub repository improves openness. It means anyone can propose a change. Anyone can even edit through the GitHub UI in a Web browser if working with text files locally is off-putting.
  • Driving the website by a public GitHub repository improves meritocracy. It means when anyone proposes a change, that proposed change can be publicly evaluated on its merits. GitHub Pull Requests and their review features are a beautiful thing.
  • Driving the website by a public GitHub repository improves collaboration. It means anyone can collaborate with anyone in any branches they need, in public or private forks if need be.
  • Modeling the website content as text files in a public GitHub repository better enables (much) better tools for working on the content. Programmers edit text files. A website that is fundamentally text files as content is more amenable to programmers and technically minded people doing great things efficiently. grep and its kin are beautiful and powerful. As is your text editor of choice.
  • Driving the website by an open and openly configured static site generator enables (much) better tools for working on the website framework. To the extent necessary, programmers can collaborate not just on the content but also on the “program” that generates the website from the content – the CSS, the templating, all the way through the free and open source static site generator framework itself.
  • GitHub Pages is much better aligned with affordable and sustainable Apereo operations practices. Apereo runs very thin on infrastructure and even thinner on staff and volunteer bandwidth to wrangle infrastructure. GitHub Pages adds zero to Apereo’s server and database footprint.
  • GitHub Pages websites are also free as in cheapness, which lines up well with Apereo funding levels. Apereo maybe should pay someone to develop awesome website content (arguable). Apereo definitely shouldn’t be paying anyone to host a website, operate its database, keep WordPress patched. Accept free-as-in-cheapness infrastructure for commodity website hosting and repurpose scarce resources for something more higher-ed-open-source-IT-aligned.
  • Static site generators enable higher quality results. It’s easier for web developers to collaborate on making a website much sharper, much snappier, much better when using sharper tools.
  • Using Jekyll-driven GitHub Pages eases future migrations. While GitHub Pages operates with panache, Jekyll is open source and generates a static website that can be served up from just about anywhere on just about any technology stack. Using GitHub Pages doesn’t entail vendor lock-in.
  • Using Jekyll-driven GitHub Pages eases future migrations. If Apereo ever wants to port this content to a different website management platform, well, all the content is just text files. It’s hard to beat that as a friendly starting point for laying hands on this content and importing it into something else.

(These are advantages of open source public-git-repository-driven static site generators more generally. Jekyll-driven GitHub Pages is a particularly nice implementation of an approach that can be achieved with more hassle using other specific technologies.)

Examples of use of GitHub Pages, outside and within Apereo

Okay, so GitHub Pages in particular, and static site generators more generally, are technically awesome. You might reasonably ask, why is this website nonetheless so very ugly?

I want to assure that GitHub Pages sites can be beautiful, usable, arbitrarily comprehensive, etc.

GitHub has a showcase of GitHub Pages examples. These are some of the more website-flavored examples:

We need not look so far afield to find examples of using GitHub Pages to make websites happen: there are usages within Apereo already.

  • CAS
  • OpenDashboard
  • OAE (note this demonstrates that GitHub Pages sites can have arbitrary hostnames, don’t have to be .github.io branded.)
  • Tsugi

Next steps

Better is better. Make things better, and then make things better again. Repeat.

I believe that static site generator approaches are better than database-backed-web-application approaches (WordPress, Drupal, even my beloved Ghost) for web sites, more often than not.

GitHub Pages-driven oaeproject.org feels more awesome, more beautiful, more full of potential to me than does its equivalent pages within apereo.org.

The next step is to do more of that. To keep making Apereo content better using better tools. And then to repeat.

I hope these steps will add up to a walk will be a walk out of database-backed website solutions and into static site generator solutions, for the better productivity, quality, openness, transparency, and sustainability of Apereo website delivery.


Opinions expressed are my own and are not necessarily those of Apereo, of my employer, of the uPortal project, or of other projects and organizations with which I am involved.

Andrew Petro

Related Posts

CAS 6.1.0 RC2 Feature Release

...in which I present an overview of CAS 6.1.0 RC2 release.

Apereo CAS as an OAuth2 Authorization Server

Learn how to configure CAS as an OAuth2 Authorization Server and configure Spring Boot client app to work with it

Apereo CAS - SAML2 Identity Provider Integration w/ Gitlab (also staring HAProxy and LDAP)

Learn how Apereo CAS may act as a SAML2 identity provider for Gitlab and run everything locally on a workstation with Docker and Java.

Apereo CAS - Keeping Healthy with Spring Boot

Learn how you may keep your Apereo CAS deployment healthy, monitoring its status using Spring Boot actuator endpoints and health indicators.

CAS 6.1.0 RC1 Feature Release

...in which I present an overview of CAS 6.1.0 RC1 release.

Apereo CAS - SAML2 Identity Provider Integration w/ InCommon

Learn how Apereo CAS may act as a SAML2 identity provider to integrate with service providers from metadata aggregates such as InCommon with various attribute release policies for research and scholarship, etc.

CAS 6.1.x Deployment - WAR Overlays

Learn how to configure and build your own CAS deployment via the WAR overlay method, get rich quickly, stay healthy indefinitely and respect family and friends in a few very easy steps.

Apereo CAS - Have you been pawned?

Learn how Apereo CAS may be configured to check for pawned passwords and warn the user, using the haveibeenpawned.com service

Apereo CAS - OohLala Mobile SAML2 Integration

Learn how to integrate OohLala Mobile with Apereo CAS running as a SAML2 identity provider.

Apereo CAS - Cranium Cafe SAML2 Integration

Learn how to integrate Cranium Cafe with Apereo CAS running as a SAML2 identity provider.