The keynote at GitHub Satellite 2019 in Berlin last month was a model of crisp story-telling. The comms team did a bang up job. The opening narrative was engaging and emotionally powerful. It asked us to think about our place in the world, our role as collaborators, at a very deep level. It began, as some of the best stories do, at cosmic scale, with a black hole. Not just any black hole, but the black hole at the center of the Messier 87 galaxy.
Doctor Katie Bouman led the team that created the algorithm for Continuous High-resolution Image Reconstruction using Patch priors (CHIRP), and we were honored that she made an appearance at the event. It’s definitely worth watching the official video on that score. 

GitHub’s keynote expressed the value of collaboration at scale, particularly the value of telemetry data based on this collaboration. It demonstrated the value of a hosted platform in allowing new approaches to software maintenance and management, for example search and replace (grep and replace) globally, even across different codebases in multiple repos. GitHub has been delivering new features at a furious pace recently, and is finally beginning to significantly leverage it’s incredible data assets based on instrumenting the work of software developers everywhere to create new products and services.  Key themes in the keynote were global interconnectedness, collaboration, sponsorship and security.

What Katie (and a global team) Did

As Doctor Katie Bouman made very clear in her presentation, science is collaborative. Scientific breakthroughs don’t happen in isolation. The image of the black hole was based on the work of scores of people. At a simple level, Bouman said:

“My role has been about combining techniques from astronomy and computer science”

Software isn’t just eating the world, it’s eating the universe. I had been told beforehand that Bouman would feature in the keynote, so I must admit that just for a moment when she appeared on screen I wished she’d been able to make it to Berlin in person. Then this happened.

The complete team who worked on to capture the first black hole picture on stage during @natfriedman keynote at #GitHubSatellite pic.twitter.com/jSYf7h5Qu3

— Anupam Dagar (@anupamdagr) May 23, 2019

We met Andrew Chael, Dr Kazu Akiyama, Sara Issaoun, Dr Lindy Blackburn, Dr CK Chan and Dr Roman Gold. So cool!

Bouman also then thanked all the open source contributors whose work the team had used. GitHub had analysed its data, based on the projects used such as Numpy, to discover that 21,485 people had contributed to software projects that had been used to create the image of the black hole. It’s just contributors all the way down.

image above from this delightful Twitter thread by Tierney Cyren

GitHub had reached out to contributors who in some cases, until that point had no idea they had helped to underpin Chirp. I am pretty sure everyone in the Satellite crowd at that point felt like a small yet important part of a far far bigger whole. I did. 

GitHub then announced two new features at this point playing to the contributor insights theme

Community contributors – a maintainer can get to know their extended team by looking at Insights in a repo, which will now provide a list of folks that have contributed to the project’s dependencies. Whose shoulders is the project standing on?

Dependent repositories – a feature which provides some signal about the popularity of a package. “Used by” indicates how many other packages rely on it.

Hygiene, Dependency, Currency

GitHub had made its point about planet scale collaboration. But with so many parties involved, the potential attack surface grows exponentially. That’s a whole new planet scale challenge. The next section of the keynote introduced Shanku Niyogi, GitHub SVP Product, and the key theme for him was security in an age of mass dependencies.

Security at the moment is frankly a bit of a mess. While the package management revolution with tools like NPM and Rubygems has made developers more productive, it also opens up worrying new attack vectors.

Yet another shoe dropped in November 2018 when event-stream a Node.js module with nearly 2M downloads a week was compromised. It was injected with malicious code programmed to steal bitcoins in wallet apps, after the project was taken over by a new maintainer (it was a social engineering attack). The vulnerability specifically targeted a bitcoin walled called Copay, but it could have been general purpose and far far worse. If it could have been worse than means someone will make it general purpose and try the same style of attack again and it will be worse. Our open source software supply chains are out of control. This was a failure of both governance and code.

One reason security is currently such as a mess is human factors, made more complicated by corporate factors. Folks often don’t want to publicly admit their code has a breach, so they can end up in a confrontational stance with people that identify potential breaches, as they look into it and fix the issue. Generally someone that identifies a breach will take it to the maintainer first but state of the art in Common Vulnerabilities and Exposures (CVE) is not good. Bounty programs can help align incentives but the industry needs to establish a standard set of common social and technical protocols to make the vulnerability disclosure discussion easier, with a trusted place to have that conversation. 

With that in mind GitHub introduced a tool for maintainers to create security advisories (now in beta), which could begin to shape a standard format over time. Importantly this tool also creates a private space to bring together researchers, maintainers, developers, and security teams before publishing. 

Jessie really likes this feature:

https://twitter.com/jessfraz/status/1131569352069865472

Once a vulnerability is published, GitHub could offer services such as scanning repos and notifying maintainers. To that end GitHub also announced a partnership with White Source on vulnerability libraries. GitHub Dependency Insights offers an overview of the security state of your dependencies, and also license information.

Things get useful with automation and GitHub had news on this score, with the acquisition of Dependabot, also announced during Niyogi’s keynote. Dependabot automates dependency updates for Ruby, Python, JavaScript, PHP, .NET, Go, Elixir, Rust, Java and Elm apps. GitHub can now not only potentially scan for dependencies, but also automate security fixes to rectify them. Dependabot monitors your code for dependencies and then automatically creates pull requests to update your libraries to required versions. Currency is one of the most important factors in improving code security, so this tuck in acquisition is very welcome. This kind of good hygiene is so important with modern code with many dependencies. It’s like having GitHub continuously flossing and brushing your teeth for you. GitHub already had some related functionality – for example token scanning, ensuring developers don’t leave authentication tokens in their code.

Another interesting possibility would be for a maintainer to have a button to ask GitHub for help with a vulnerability, with code savvy security architects acting like on call SREs to help people deal with issues. The great majority of developers aren’t security specialists, so GitHub could do a lot to help out if a CVE was found in a library that a lot of important projects relied on. This was not announced at the show, but it would make for a really useful service. 

Sponsorship and The New Patronage Economy

The last major strand of the keynote came in a great presentation by Devon Zeugel, introducing the new GitHub Sponsors platform, kind of like a patreon for developers. I wrote about this kinds of model here – obviously a tip jar isn’t going to pay the bills for most developers, and it won’t offer US healthcare insurance – but anything that reduces friction in making payments to developers looks like A Good Thing. Some projects could be self-sustaining; some developers have huge followings. For now the program is in a limited beta – anyone with a GitHub account can sponsor anyone with a prequalified Sponsored Developer account, with recurring payments. 

To my mind one of the most interesting facets of the product development is that the payments are managed by Stripe, which has some sophisticated multi-payment systems designed expressly for “Gig economy” platforms and users. I am not a fan of the gig economy term in general, in that it can be used to both describe very well off people taking advantage of digital platforms, or less well off people being taken advantage of by digital platforms. On the whole though software developers are reasonably well paid, and there is a structural difference between a developer getting paid and an Uber driver getting paid for their work. The Sponsors function will become more interesting as we see, for example, corporate accounts, where a bank, insurance company or retailer easily paying a developer, or set of developers, that maintain a library or project they rely on. The nature of the firm is always up for grabs. 

A nice touch is the GitHub Sponsors Matching Fund, which matches up to $5000 per sponsored developer in their first year of sponsorship. One major concern is that network effects are going to network effect, power laws are going to power law – that is, a vanishingly small proportion developers are going to take the vast share of sponsorship money, unless this is very very judiciously managed by GitHub.  

The Friedman Effect

In closing I think it’s worth talking a bit about Nat Friedman, himself, who took the reins as GitHub CEO last October. He has made a substantial difference to GitHub in a short space of time, most visibly and importantly in his, and now the company’s, bias to shipping. GitHub’s culture was already changing, as he arrived. The company had just shipped Actions, an important new capability, but Friedman took that momentum and added more velocity. A company that rarely seemed to ship anything now ships useful new functions pretty much every week. It was instructive that in weeks proceeding Satellite GitHub shipped a a few cool new things – such as notifications for gists, and GitHub on the go, improving the mobile experience. Employees seem energised by the change. Developers certainly are. Picking up the pace of development was particularly important given the pace of product development at GitLab, with its monthly release cycles, and strong sales execution.

Friedman is also hiring well – to supplement an already strong talent base. Niyogi brings a wealth of experience with him from Microsoft and Google Cloud. I also found out at Satellite that GitHub is hiring Erica Brescia to run operations – she’s a very smart, likable operator, having sold her last company Bitnami to VMware.

Friedman is a nerd, he’s one of us, and he has been in the open source trenches for years. GitHub is going to continue moving ever more quickly. One of the toughest jobs for Friedman will be managing the balancing act of turning GitHub into a broad platform, while sustaining an ecosystem of partners while it also competes with them. But shipping new features is definitely no longer a problem.

 

Here’s a bonus video of my thoughts from GitHub Satellite.

GitHub and GitLab are both clients. GitHub paid for my travel and expenses to Berlin.