By Matt Asay
Contributor, InfoWorld | NOV 13, 2023 2:00 AM PST
Not everyone wants AI to do everything for them. Will the risk of losing transparency and visibility into code change how GitHub made collaborative coding so powerful?
Did GitHub just jump the shark? At GitHub Universe last week, GitHub CEO Thomas Dohmke declared, “Just as GitHub was founded on Git, today we are re-founded on Copilot,” essentially telling developers, from here on, we’re all AI, all the time. Dohmke was selling a bold future intended to keep GitHub at the center of developers’ universe. But in the process, he may have overlooked all those developers who just want “GitHub to be a functional/reliable code hosting platform that supports multiple source control options, and to evolve source control ecosystems,” as open source developer Geoff Huntley counters.
Perhaps even more tellingly, GitHub’s hard shift to AI may be overlooking the transparency that made Git—and open source—so powerful for developers.
Git didn’t originate source control for developers, but it dramatically improved it. Reflecting on his creation of Git, Linux founder Linus Torvalds lamented, “I really never wanted to do source control management at all and felt that it was just about the least interesting thing in the computing world.” Interesting or not, do it he did, enabling developers “to make their own private test repositories without having to worry about the politics of having write access to some central repository,” he explains. That “coding without drama” principle propelled code collaboration into the modern age.
Well, almost. It was really GitHub that took it to the next level, as Tobie Langel stresses: “GitHub gave open source visibility and lowered the playing field for collaboration by an order of magnitude.” GitHub made social coding incredibly easy, which delivered on the promise of open source.
GitHub doesn’t seem to see the dissonance. The company’s COO Kyle Daigle states, “We know developers love to learn by doing, and open source helps developers more rapidly adopt new technologies, integrate them into their workflows, and build what’s next.” What’s less clear is how GitHub views AI as the connective tissue between developers understanding and collaborating on code. “We expect open source developers to drive the next wave of AI innovation on GitHub,” he continues. But how are developers supposed to do that if they’re blocked from knowing how the code “sausage making” actually works?
Git made code and the collaboration around it permeable; AI does the opposite.
It’s not hard to see why GitHub would put all its chips on AI. According to its own data, 92% of developers are actively experimenting with AI. In fact, all the cloud providers are trying to outdo each other in pitching their plans for AI (perhaps at the expense of developers). There’s so much froth in AI right now, but also a sense that if companies don’t stake a claim in this land grab, they risk irrelevance, which again, makes GitHub’s move understandable.
It’s also arguably a Very Good Thing for developers, at least in part. GitHub paints the purpose of AI in glowing terms: “Everything we’re announcing is focused on one thing: bringing a holistic, productive, and seamless AI-powered developer platform to developers—no matter what you’re building.” The problem, however, is that none of the AI comes with the same inspectability that enabled developers to trust GitHub. There currently is no “open” in AI. However much we may want to talk about open source AI, it doesn’t exist. Not yet, anyway. AI remains a black box, one that cuts against the way open source developers have worked for decades.
GitHub’s bet seems to be that developers won’t care, that the magic of code completion will be a greater gain than losing visibility into source control is a loss. But so far, the response has not been enthusiastic. “I… am deeply uncertain that I actually want this at all,” notes outspoken open source advocate Adam Jacob. He’s not alone, as comments on his tweet attest.
Some of the backlash may be coming from “developers of a certain age,” as it were. As Ashley Williams adds, “I think they will win. I think they’ll make a boatload of money, and I think it might be a net positive for some parts of the industry. But as a ‘no longer their target audience,’ I’m certainly bummed out.” Put more positively by a less experienced developer commenting on Jacob’s tweet, “I think that’s the response of an expert practitioner seeing the Copilot results and knowing they can pretty quickly produce something better. As an infrequent programmer who often forgets, I find these tools make me MUCH more productive.”
This isn’t really the ultimate gripe that folks like Jacob or Williams have, however. I suspect most are on board the Simon Willison train. He has been an outspoken advocate for the added productivity AI can yield for developers. The worry is that by shifting the focus to AI, GitHub will lose focus on the original source of its popularity: making Git easy to use and collaborate around. Perhaps AI will now fill this role, but Git still has problems that need fixing, to Huntley’s point. Will these get buried in an avalanche of “let the AI take care of everything” marketing?
For companies with a large monorepo or, really, for the way most enterprise development works, GitHub’s standard pull request model doesn’t work well. This has given rise to stacked diffs in organizations like Google and Meta. “Stacking as a methodology empowers developers to bypass the delays of main branch dependency and permits continuous parallel development,” says Tomas Reimers, cofounder of Graphite. It’s a fantastic innovation, but not one we have with GitHub today, and not one we’re likely to get in an AI-focused GitHub of tomorrow.
“GitHub is at the center of all we do,” argues Darren Shepherd, chief architect at Acorn Labs. “I’d rather not [have it] go through some drastic hype-driven change.” Again, folks like Shepherd might not be the core audience for GitHub’s Copilot-anchored future. But in the rush to go all-in on AI, there’s reason to be cautious about losing the focus on the very thing that made GitHub work for millions of developers in the first place: the transparency of Git. Perhaps GitHub’s Copilot vision includes a doubling down on Git to further improve it, but if so, that got lost in the marketing hype.
Resource: Carey, S. (n.d.). Devs don’t want to do ops. InfoWorld. https://www.infoworld.com/article/3669477/devs-don-t-want-to-do-ops.html
MixedMug
We firmly believe that the internet should be available and accessible to anyone, and are committed to providing a website that is accessible to the widest possible audience, regardless of circumstance and ability.
To fulfill this, we aim to adhere as strictly as possible to the World Wide Web Consortium’s (W3C) Web Content Accessibility Guidelines 2.1 (WCAG 2.1) at the AA level. These guidelines explain how to make web content accessible to people with a wide array of disabilities. Complying with those guidelines helps us ensure that the website is accessible to all people: blind people, people with motor impairments, visual impairment, cognitive disabilities, and more.
This website utilizes various technologies that are meant to make it as accessible as possible at all times. We utilize an accessibility interface that allows persons with specific disabilities to adjust the website’s UI (user interface) and design it to their personal needs.
Additionally, the website utilizes an AI-based application that runs in the background and optimizes its accessibility level constantly. This application remediates the website’s HTML, adapts Its functionality and behavior for screen-readers used by the blind users, and for keyboard functions used by individuals with motor impairments.
If you’ve found a malfunction or have ideas for improvement, we’ll be happy to hear from you. You can reach out to the website’s operators by using the following email
Our website implements the ARIA attributes (Accessible Rich Internet Applications) technique, alongside various different behavioral changes, to ensure blind users visiting with screen-readers are able to read, comprehend, and enjoy the website’s functions. As soon as a user with a screen-reader enters your site, they immediately receive a prompt to enter the Screen-Reader Profile so they can browse and operate your site effectively. Here’s how our website covers some of the most important screen-reader requirements, alongside console screenshots of code examples:
Screen-reader optimization: we run a background process that learns the website’s components from top to bottom, to ensure ongoing compliance even when updating the website. In this process, we provide screen-readers with meaningful data using the ARIA set of attributes. For example, we provide accurate form labels; descriptions for actionable icons (social media icons, search icons, cart icons, etc.); validation guidance for form inputs; element roles such as buttons, menus, modal dialogues (popups), and others. Additionally, the background process scans all of the website’s images and provides an accurate and meaningful image-object-recognition-based description as an ALT (alternate text) tag for images that are not described. It will also extract texts that are embedded within the image, using an OCR (optical character recognition) technology. To turn on screen-reader adjustments at any time, users need only to press the Alt+1 keyboard combination. Screen-reader users also get automatic announcements to turn the Screen-reader mode on as soon as they enter the website.
These adjustments are compatible with all popular screen readers, including JAWS and NVDA.
Keyboard navigation optimization: The background process also adjusts the website’s HTML, and adds various behaviors using JavaScript code to make the website operable by the keyboard. This includes the ability to navigate the website using the Tab and Shift+Tab keys, operate dropdowns with the arrow keys, close them with Esc, trigger buttons and links using the Enter key, navigate between radio and checkbox elements using the arrow keys, and fill them in with the Spacebar or Enter key.Additionally, keyboard users will find quick-navigation and content-skip menus, available at any time by clicking Alt+1, or as the first elements of the site while navigating with the keyboard. The background process also handles triggered popups by moving the keyboard focus towards them as soon as they appear, and not allow the focus drift outside of it.
Users can also use shortcuts such as “M” (menus), “H” (headings), “F” (forms), “B” (buttons), and “G” (graphics) to jump to specific elements.
We aim to support the widest array of browsers and assistive technologies as possible, so our users can choose the best fitting tools for them, with as few limitations as possible. Therefore, we have worked very hard to be able to support all major systems that comprise over 95% of the user market share including Google Chrome, Mozilla Firefox, Apple Safari, Opera and Microsoft Edge, JAWS and NVDA (screen readers), both for Windows and for MAC users.
Despite our very best efforts to allow anybody to adjust the website to their needs, there may still be pages or sections that are not fully accessible, are in the process of becoming accessible, or are lacking an adequate technological solution to make them accessible. Still, we are continually improving our accessibility, adding, updating and improving its options and features, and developing and adopting new technologies. All this is meant to reach the optimal level of accessibility, following technological advancements. For any assistance, please reach out to