The next billion programmers (won’t use Git)
The next billion programmers won’t have computer science degrees or speak English. They’ll be on Chromebooks, or their phones. They’ll touch code in smaller ways and it will only be a part of their job: they might be considered marketers or analysts or designers. And they may not use Git or Github.
Git was created in 2005 by Linus for the Linux kernel, in a world where you had to assume a computer would go offline at any moment. Three of the top five Stackoverflow questions are about Git. There are 15+ books about Git. Github’s intro tutorial to Git is 25 parts. Git is horribly broken, and thus so is Github.
Here are four ideas for what a next generation Github might look like, ready for the next billion programmers:
1.Simplify the Git interface to optimize for daily workflows
Pull requests. Rebase. Remote origin. GitHub does no handholding for those unfamiliar with the underlying concepts of Git, in fact, it even invents some jargon of its own! And that’s a huge problem. Renaming “pull request” to “submit for code review”, using visuals to make unintuitive best practices like rebasing easier, and designing the interface in a task-oriented manner would go a long way.
2. Assume all code is online, all the time
Git assumes contributors are usually offline but more than 10 years after Git’s origin (git it?), this is rarely the case. If you assume everyone is online– like Google Docs– you can do things like live commenting as functions change over time, imagine pre-emptive code conflict warnings, native text editor pair programming and live snippet sharing.
3. Invest in Github’s people network
The majority of programmers don’t contribute to open source and so Github’s profiles are pretty barren. The fact that I search for most programmers by defaulting to Google is a lost opportunity for Github– I don’t do the same for books. Github should try making profiles more rich by focusing on learning and the journey of being a programmer. Of course, a job network is an obvious next step here as well, which is critical for turning Github’s illusion of a network effect into a real one.
4. Invest in Github’s code network
Github is also well-placed to take advantage of the so-called “serverless” architecture. Imagine LibLib: a library of libraries, written in any language and callable in any language with standardized input and output formats– sort of like a souped up ready-to-deploy playground for an Amazon Lambda-like service. You could use the best datetime library if that happened to be in Javascript, and a great auth library written in Python, all hosted and forkable on Github.
What does the toolchain for the next billion programmers look like?
I’ve written the above as if I were Github, but I think there’s a fair chance they’ll miss out on a lot of this. And that might just be an opportunity for you.
I’m actively investing in this area, so please give me a ring. To receive future posts via email, sign up here. This post was conceived with Jess Peterson in August 2015.
