Buggy-whips, Violins, and GitHub Copilot

Jim Salmons
GitHub Copilot for Disabled Developers
10 min readNov 7, 2022

--

Thoughts on the Copilot v. Open Source Developers Class Action Lawsuit

Let me first state my obvious conflict of interest regarding the recently announced class action lawsuit between Microsoft/GitHub and a group of Open Source developers. As a dexterity- and mobility-challenged disabled developer — thanks to a severe spinal cord injury two years ago — GitHub Copilot has been a life-changing innovation that I have been thrilled to have available to me since I was granted access to it during the product’s Technology Preview program. Having said that, let me also admit to some discomfort of cognitive dissonance due to my empathy for the Open Source developer community having read the well-reasoned position statement at the lawsuit’s support-rallying website at GitHubCopilotInvestigation.com.

Rather than analyze and split hairs regarding the explicit assertions by each side of this legal action, let me provide some perspective by alluding to two similar situations in the history of technology innovation, followed by a bit of speculation about hoped-for technology evolution in the case of the future of software design and development.

Of Buggy-whips and Violins

Many of you will be familiar with the widely-shared folk wisdom of “If only the buggy-whip makers had seen themselves in the personal transportation parts-supplier business rather than as whip-makers, they could have survived the transition from horse drawn carriages to automobiles.” A 2010 New York Times article by Randall Stross provides a fascinating Paul Harvey-like “More to the Story” glimpse into this popular saying.

The way I want to think about this buggy-whip history lesson is not to look at the actual historical context of paradigm-shifting technology innovation, but to imagine a hypothetical situation that might have arisen in the time just ahead of the transformative wave of widespread adoption of the automobile.

Imagine we are in the late 19th Century immersed in the buggy-whip business. As an artisan-crafted product, these whips provide a good livelihood if you have the skills to make them. Unbeknownst to you and your whip-maker colleagues, an inventor comes up with an amazing Rube Goldberg-like machine to dramatically automate the manufacture of buggy-whips.

Seeing these machines for the obvious threat they pose to your way of life, you gather at the Buggy-whip Makers Guild to consider the situation and strategize a response, including possible legal action. While your guild and the whip-making Inventor are steeped in this contentious confrontation, the whole world makes a seismic shift with the introduction and groundswell adoption of the automobile. With this unexpected transformation of the personal transportation industry, both we Whip-makers and the whip-making machine Inventor are faced with the realization that our conflict is moot as we all confront the new era of horseless transportation.

Now, hold that thought for a bit as we shift our attention from a hypothetical technology innovation history lesson to a fascinating example that happened about the same time in the late 19th Century in the Markneukirchen region of Saxony, Germany.

There was a time that lasted for centuries where high-quality musical instruments were lovingly handcrafted by the most skilled artisans in the world. The names of Stradivari and Guarneri still inspire awe when we think about the most prized violins ever made. The skills to make such quality instruments were very real trade secrets closely guarded through a tightly regulated network of craft guilds that still exist today in various forms.

As the world paradoxically “shrank and expanded” in the 19th Century due to population growth and transportation innovation largely in the seafaring domain, the need and consumer interest in quality musical instruments grew dramatically. Instrument makers were hard-pressed to meet the demand. This surge in the marketplace especially brought stresses to the makers’ traditional guild-oriented industry which assured the skills of makers through a largely apprentice-based career development experience.

For whatever reason — I suspect its European geographical centrality was a factor — musical instrument makers congregated in and around Markneukirchen and built a thriving economy and social order based on making all types of musical instruments that is still the economic engine of the region today. Even some expat Italian violin-makers relocated to Markneukirchen due to guild politics and market control dynamics. While these Italian crafts-people joined with their Saxony compatriots to grow their guild-based violin-making capacity, consumer demand kept them perpetually in a production-constrained situation.

As you might have guessed, the Markneukirchen violin-makers eventually resolved their stressful market-driven demand through production innovation. Much like Henry Ford would do less than a hundred years later, the Markneukirchen violin-makers responded by incorporating a production automation strategy. Ford’s innovation was mass-production via a factory-based method. The Markneukirchen violin-makers response was a decentralized and distributed strategy more natural to the crafts-style production methods of high-skilled instrument making.

While traditional instrument-making was based on the maker’s intimate skills applied to the design and construction of a complete instrument, the Markneukirchen makers began to specialize. Some makers were very good at making violin pieces like the complex shapes of carved tops and backs. Other makers were particularly skilled at final construction and the subtleties of balancing volume and intonation as the various pieces are brought together.

The Salmons family Markneukirchen violin was made by Hermann Geipel, a Guild-registered violin maker who practiced his craft in the mid-19th through, I believe, early 20th Century as a resident of Markneukirchen. I took this violin for extensive refurbishment by renowned violin-maker Edward Campbell of the famous Chimney’s Violin Shop of Boiling Springs, Pennsylvania. When I opened the case he said, “Well, I know it is not what it looks like, but this is an outstanding copy of a Guarerius violin! Let’s take a closer look.” You can read more about the Salmons family Markneukirchen violin here.

Before long the instrument makers of the Markneukirchen region developed a network of skilled violin part-makers. Many of these skilled crafts-people were expert at what they did but were not members of the highly-controlled makers’ guilds. At some point, this production innovation that responded to the increased demand for quality musical instruments came to a head as the guilds resonded to the changes in the region’s manufacturing processes. The Markneukirchen violin-makers guild admitted its first members who specialized in part-making while not being engaged in the full craft of producing an instrument from start to finish.

None of us were around when the Markneukirchen guild members wrestled with this tradition-breaking question of recognizing the changes in their profession. And, of course, none of us were around for the hypothetical scenario where buggy-whip crafts-makers and the buggy-whip-making machine Inventor where steeped in their issue over control of the whip-making means of production just ahead of the advent of automobile mass adoption. My purpose is not to dwell on these scenarios for their own sake, but rather to use these allegorical tales to consider the context for the present conflict between the corporate developers of Github Copilot and the Open Source developer community.

Buggy-whips, Violins, and the Future of Software Design and Development

Having slid down the allegorical rabbit-hole of considering the plight of buggy-whip and violin makers in the perpetual march of disruptive technological change, what is the point of this contextual thought experiment? First, let me reiterate my personal bias and preference as I mentioned at the start of this article. No matter the course and outcome of the current Copilot class action lawsuit, I hope with all my heart that Copilot, specifically, and similar AI- and Machine-Learning-based assistive technologies will remain available and be given the creative space to evolve and flourish in service to the improvement of Quality of Life for those of us in the disabled community.

This said, I can also empathize with the Open Source developer community that foresees a cataclysmic disruption in the social and economic order of the domain of software design and development. Having had decades of software industry experience before the advent and evolution of the shared vision and value commitment to the foundational ideas of Open Source software, I certainly don’t want to see this radical innovation threatened or seriously undermined. I have witnessed firsthand how Open Source as a movement has transformed the software industry.

So what do I hope for in terms of the immediate future as characterized by the recent filing of the class action lawsuit by Open Source developers against MS/GitHub over the Copilot product? Evoking the “better angels” side of our human nature, I hope that this lawsuit is a context-setting “shot across the bow” moment that can usher in a sincere commitment from both sides of this conflict to engage in solution-finding collaboration that results in a better Copilot and similar products, and a stronger, long-term viability of the core values and human networks that make up the Open Source community and economy. Certainly GitHub is reasonably well-situated to walk this fine-line between both sides of this conflict.

Perhaps if Microsoft, GitHub, and other deep-pocketed AI/ML industry players provide significant seed funding and participation in an industry-wide task force organization to research, resolve, and accommodate this inevitable technical innovation’s impact, everyone on both sides of this issue will be better off and happy. Certainly money spent on constructive solution-oriented activity is far more beneficial than wasting human and financial resources on legal action that does little more than deepen the trenches and raise the walls that separate those on either side of this issue.

Turning to the longer view of what’s at stake in terms of the future of innovation in the evolution of software design and development, we can take note of insights gained by considering my tales of the buggy-whip makers and Inventor, and the guilds of the Markneukirchen instrument-making community.

In the hypothetical tale of the buggy-whip makers and whip-making machine Inventor, both sides were impacted by not having their attention directed to the larger and significantly more impactful disruption to their livelihood due to the introduction of the automobile. The Markneukirchen musical instrument makers’ guilds, on the other hand, avoided the potential disruption to the social and economic fabric of their community by recognizing and adapting to the incremental and inevitable change in methods needed to do musical instrument production at scale. These two tales each have something to consider as we contemplate the ever-accelerating march into the future of the means and value of software design and development.

The GitHub Next research lab is GitHub’s decentralized and distributed team of brilliant and highly-specialized researchers and engineers engaged in envisioning the tools and methods that will shape the future of software design and development. The Copilot team is among the R&D groups engaged in this activity.

No matter the outcome of the Copilot class action lawsuit, we are sure to be hurtling into a world of software development innovation that is moving so far and fast that our wildest speculations will likely be quaintly inadequate when compared to future reality. The methods and tools of software design and development will change so dramatically that future developers will likely rarely see or directly craft source code in the way we currently recognize as the routine activity of software development.

Copilot and other transformer-based code-generation models will evolve so quickly and far that Human-Machine “Pair Programming” will likely mean that source code slips into a proverbial “black box” of being there below the surface, but rarely seen or needed to be inspected and edited directly. Future developers will work in a world where they will not need to know or care what programming language is being used to build a current project.

Even if we restrict these AI-based Machine-Learning models by limiting their direct access to Open Source code repositories for domain-specific training, these ML models will continue to grow and generalize to the point that they will be essential to our abilities to get work done across many domains we now consider the province of human abilities and understanding. Constraining these generalized models from participation in our domain of interest will put the software development industry in a self-imposed inferior position with regard to creating the new world of human activity that will emerge in the coming years. Like the buggy-whip makers and whip machine Inventor, we don’t want to be so immersed in our immediate disruptive issue that we don’t recognize the far greater transformation that is happening all around us.

As these ML models get smarter and more generalized, so too will the evolution of software design and development continue to move from “Code is King” to “Data is King.” Crafting new software tools will become more about selecting appropriate Machine Learning models, understanding task data models, preparing effective model-training datasets, and configuring models and transactional workflows that achieve our project design and performance goals. As software frameworks become more aware of user interface design patterns and data transformation workflows, the need to explicitly design and build applications as we know them today will be replaced by the dynamic generation of user data views and workflow pipelines.

The human-machine interface and interaction experience we currently associate with the art and science of software design and development will be barely recognizable to the generations of future software designers and developers… if we even call ourselves that in the new world that is emerging before our eyes today and in the years ahead. Like the Markneukirchen guilds, it is incumbent on us to recognize and respond to the opportunities and challenges of inevitable change.

I truly hope that the Copilot class action lawsuit can be quickly resolved by its replacement with a positive and constructive collaboration among individuals and organizations who all know and love our shared joy at the creation, distribution, and use of software. And I hope I live long enough to see as much of this unfold as possible.

Happy Healthy Vibes from Colorado USA,
-: Jim Salmons :-

Jim Salmons is a seventy-one year old post-cancer Digital Humanities Citizen Scientist. His primary research is focused on the development of a Ground Truth Storage format providing an integrated complex document structure and content depiction model for the study of digitized collections of print era magazines and newspapers. A July 2020 fall at home resulted in a severe spinal cord injury that has dramatically compromised his manual dexterity and mobility.

Jim was fortunate to be provided access to the GitHub Copilot Technology Early Access Community during his initial efforts to get back to work on the Python-based tool development activities of his primary research interest. Upon experiencing the dramatic positive impact of GitHub Copilot on his own development productivity, he became passionately interested in designing a research and support program to investigate and document the use of this innovative programming assistive technology for use by disabled developers.

--

--

Jim Salmons
GitHub Copilot for Disabled Developers

I am a #CitizenScientist doing #DigitalHumanities & #MachineLearning research via FactMiners & The Softalk Apple Project. Medium is my #OpenAccess channel.