As many open source developers recently found, Travis CI has stopped providing their service to the open-source community for free. There have been many other blog-posts, a long hacker-news thread, and tweets about the state of open-source development that I don’t need to repeat here. However, there are some trends and possibilities that I have observed and have not seen discussed widely, so here I go talking to the void.
Github workflows saved the day (Anecdotally, or at least just for me)
CI/CD is not a new concept, but arguably Travis CI popularized CI/CD for open source projects by being early and very easy to integrate with Github. I selected Travis CI when developing SpiceyPy; it had a fun logo, and it was straightforward to get working. Upon hearing the news about Travis CI, I switched to GitHub workflows, and anecdotally so did many other developers (my sources are mostly Tweets and hacker news comments). I will be curious to see metrics to back this up, but there are many other ci services out there (cursory checks of Google trends did not reveal anything clear), so maybe the impact of Travis departing the FOSS world did not shake things up that much.
Unintended Consequences of Travis CI changes
I was able to translate my Travis CI YAML steps into an equivalent Github workflow very quickly. So quickly that I was able to unify my Windows CI builds into the GitHub workflow allowing me to stop using the Appveyor service. I should also note that I started using Appveyor more than five years ago, so I was ignorant of more recent moves Appveyor made to support other operating systems or other CI services making similar moves. To be fair to Appveyor, the service worked very well for me for years, and it was free, but the urge to have a singular YAML file was too strong (more on this soon).
One YAML (syntax) to rule them all
I was also impressed by how flexible the Github workflow syntax was. For years, I maintained two similar yet incompatible YAML files for Appveyor and Travis that were both repeating the same logic with service-specific YAML syntax. Unifying those files was very satisfying from a DRY perspective, but it led to a broader question that motivated this blog-post: What truly differentiates the various CI services other than their specific configuration quirks? I am sure there are financial and ease of use trade-offs for enterprise customers, but consider just for the moment the simple Python projects not requiring Docker containers or higher-level orchestration of some kind. The CI workers’ requirements for these small projects are relatively minimal as they just need to run a few bash commands. The different CI services had slightly different YAML syntax, as they didn’t adopt a standardized way to implement the common logic. Theoretically, as some of these services open-sourced various aspects of their infrastructure, one service or the other could have adopted one style or another. Since Github workflows are open source (you can self-host runners), maybe that could become a standard. But paradoxically, if the CI services embrace a standardized YAML syntax, what incentive remains for users to continue using their service over another? It would seem to remove a large portion of the core engineering business to outsource this core infrastructure component.
Vertical integration and Vendor lock-in
The vendor lock-in move GitHub is making with workflows is apparent, and the other CI services simply do not have the same amount of eyeball time that GitHub gets for open source projects like mine. Thankfully, there are some mitigating facts that, for now, should keep the space competitive. First, Git is open source, and there are other free hosted Git services out there with their own CI integration, GitLab notably. Second, GitHub open-sourced their workflow action runner code allowing self-hosted runners with an MIT License. Other CI services could theoretically use the runners or modify their infrastructure to use the GitHub YAML syntax. The only issue I would see is that I haven’t found a published schema/spec/API versioning of the GitHub YAML syntax out there. In any case, nothing is stopping some other CI service from attempting to standardize their particular YAML for additional services to use.
In short, GitHub workflows allowed me to quickly switch CI services in a way that fit well into my current daily usage of GitHub for my projects. Many posts I have seen about the fall of Travis CI have discussed worrying trends in the open-source world. Still, I don’t think enough attention has been paid to the rippling effects of a large, diversified competitor entering a market filled with smaller players who are not their own cloud provider. I think that many of the smaller services will have to make moves to ensure they remain relevant. I doubt they can differentiate themselves for long with greater performance/more parallel jobs. The rise of ARM could make things a bit interesting as some CI services have native runners to offer up, but it seems like that is also a surmountable service for larger vendors to offer. I doubt GitHub’s CI offering would be attractive enough to switch GitLab users over, but it also seems the reverse is more likely if Microsoft decides they need to decrease their generosity. To be clear, I think GitHub/Microsoft would totally be in the right to do so, but I think that move would be poorly received. Maybe concerns over lock-in will raise the issue of CI workflows’ transportability to the point a community standard is adopted, but I could also just overemphasizing the difficulty of rewriting a YAML file once every few years.
Thanks for reading this meandering post. Maybe this was all extremely obvious to everyone, but you decided to keep reading to this point, so what does that say then? If I am just wrong about something or unaware of some trend, please reach out and let me know, nicely.
-Andrew
)