The Most Important Software Innovations

David A. Wheeler

Too many people confuse software innovations with other factors, such as the increasing speed of computer and network hardware. This paper tries to end the confusion by identifying the most important innovations in software, removing hardware advances and products that didn’t embody significant new software innovations. This paper presents its criteria for the most important software innovations and sources, the software innovations themselves, discusses software patents and what’s not an important software innovation, and then closes with Conclusions.

The results may surprise you.

To be a “most important” innovation, an innovation has to be an idea that is very widely used and is critically important where it applies. Innovations that are only used by a very small proportion of software (or software users) aren’t included. To be a “software” innovation, it has to be a technological innovation that impacts how computers are programmed (e.g., an approach to programming or an innovative way to use a computer). I’m intentionally omitting computer hardware innovations or major hardware events that don’t involve software innovation. People seem to confuse hardware and software, so by intentionally not including hardware, we get a different (and interesting) picture we do not see otherwise. For example, a court case in 1973 determined that John Vincent Atanasoff is the legal inventor of the electronic digital computer, but that’s a hardware innovation and thus not included. I’ve omitted other strictly hardware innovations such as the transistor (1947) and integrated circuits (1958). I’ve also omitted Ethernet, which Bob Metcalfe developed in 1973, for the same reason (Ethernet used early Internet Protocol software, so the software ideas already existed.) I’ve omitted inventions that aren’t really technological inventions (e.g., social or legal innovations), even if they are important for software technology and/or are widespread. For example, the concept of a copylefting license is an innovative software licensing approach that permits modification while forbidding the software from becoming proprietary; it is used by a vast array of software via the General Public License (GPL). The first real copylefting license (the Emacs Public License) was developed by Richard Stallman in 1985 - but since copyleft is really a social and legal invention, not a technological one, it’s not included in this list. Also, the “smiley” marker :-) is not included - it’s certainly widespread, but it’s a social invention not a technological one. We also have to define “innovation” carefully. An “innovation” is not simply combining two functions into a single product - that’s “integration” and usually doesn’t require any significant innovation (just hard work). In particular, integrating functions to prevent customers from using a competitor’s product is “predation,” not “innovation.” An “innovation” is not a product, either, although a product may embody or contain innovations. Re-implementing a product so that it does the same thing on a different computer or operating system isn’t an innovation, either. An innovation is a new idea. And in this paper, what’s meant is a new idea in software technology.

As a result, you may be surprised by the number of events in computing history that are not on this list. Most software products are not software innovations by themselves, since most products are simply re-implementations of another idea. For example, WordStar was the first microprocessor word processor, but it wasn’t the first word processor - WordStar was simply a re-implementation of a previous product on a different computer. Later word processors (such as Word Perfect and Microsoft Word) were later re-implementations by other vendors, not innovations themselves. Some major events in computing are simply product announcements of hardware, and have nothing to do with innovations in software. Thus, while the IBM PC and Apple ][’s appearances were important to the computing world, they didn’t represent an innovation in software - they were simply lower-cost hardware, with some software written for them using techniques already well-known at the time.

Occasionally a product is the first appearance of an innovation (e.g., the first spreadsheet program), in which case the date of the product’s release is the date when the idea was announced to the public. Some innovations are innovative techniques, which aren’t directly visible to software users but have an extraordinary effect on software development (e.g., subroutines and object-orientation) - and these are included in this list of software innovations. For the more debatable entries, I’ve tried to discuss why I believe they should be included.

I’ve tried to identify and date the earliest public announcement of an idea, rather than its embodiment in some product. The first implementation and first widespread implementation are often noted as well. “Public” in this case means, at least, an announcement to a wide inter-organizational audience. In some cases identifying a specific date or event is difficult; I welcome references to earlier works. For example, sometimes it is difficult to identify a “first” because an idea forms gradually through the actions of many.

Since I haven’t found some sort of consensus of what the most important computing innovations are, I’ve developed this list by selecting events from many other sources. I used many sources so I wouldn’t miss anything important, in particular, I used IEEE Computer’s historical information (including their 50-year timeline), the Virtual Museum of Computing, Hobbes’ Internet Timeline, Paul E. Ceruzzi’s A History of Modern Computing, and John Naughton’s A Brief History of the Future. I also used Janet Abbate’s Inventing the Internet in a few cases, but I tried to double-check everything in that source because (unfortunately) Abbate makes several errors that make its use as a source suspect. For example, Abbate (page 22) doesn’t realize that although both Strachey and John McCarthy used the same word (“time-sharing”) for their ideas, they didn’t mean the same thing at all. Also, Abbate (page 201) claims Steve Bellovin was at Duke, but this is wrong. I’ve also examined other sources, such as James Durham’s History-Making Components and A History and Future of Computing. Note that, in general, these sources mix computer hardware and software together. Another source is the “Software Pioneers” conference (June 28-29, 2001, Bonn) sponsored by Software Design and Management. Many specific sources such as “OSI and TCP: A History” by Peter H. Salus were checked too. The Association for Computing Machinery (ACM) Software Systems Award was helpful, but this rewards the developers of influential software systems; the recipients are certainly worthy, but in many cases the influential software systems represent good engineering and refinement of already-existing ideas, instead of being the first implementation of a new idea themselves. As is discussed futher later, we need to distinguish between innovations and important products; a product can be important or useful without being innovative.

If you find computing history interesting, you might also enjoy the 20 Year Usenet Timeline, a Brief History of Hackerdom, and Landley’s Computer history page, though they aren’t significant sources for the material here.

After I started identifying innovations, many asked me about software patents. I have done what I can to find applicable patents, though the problems are legion. Software patents are often incomprehensible, even by software experts. Search systems cannot find all relevant software patents; unlike drugs, there is no good indexing system, either for software patents or for software ideas in general (different words can be used for the same idea). This inability to find patents causes many other problems. Software patents are often granted for prior art, even though they are not supposed to be. Indeed, someone else can hear of an idea (possibly years later), file a software patent, and the patent office is likely to grant it. The patent office may even grant a software patent on something already patented.

Yet if the real question about software patents is, "do patents provide an incentive to innovate in software", then things can be simplified. If that were true, it is reasonable to presume that (a) the innovator (or his company) would file the patent, (b) that it would have a form corresponding to the original innovation, and (c) he would file within the legal grace period (12 months from date of public knowledge). Also, patents generally were not granted on software before 1980. My thanks to Jim Bessen for these insights. These factors make patent searching far more tractable, e.g., using Google's advanced patent search. My thanks to many, including Jim Bessen, for searching for patents on these key innovations to find relevant patents. Where found, this article identifies the US patent number. If no patent has been identified, that means that people have looked but not found a plausibly-valid patent for it. The section on software patents discusses this further.

Since this paper was originally published, I’ve received several additional suggestions which rounded out this paper. My thanks to those who have provided those suggestions. It’s quite possible this paper is still missing some important innovations; please contact me if you have a correction or addition (dwheeler, at dwheeler.com, no spam please).

One source that was not helpful for this analysis were software patents. The reason? Software patents are actually harmful, not helpful, to software innovation, as confirmed by a myriad of data. Those unfamiliar with software patents may find that shocking.

There are several basic problems with software patents, compared to actual innovation:

almost all truly important innovations in software were never covered by patents, so using patents as a primary source would omit almost all of the most important software innovations; as software patentability has increased, the number of key software innovations has decreased; and software patents are often granted to cover ideas that are obvious to practitioners of the art or have prior art (even though these aren’t supposed to be patented).

There are many reasons most of the most important software innovations were never patented. Historically, software was not patentable, and it’s still not patentable in vast number of countries (including the EU). Many believe software should never be patentable, and many of them oppose software patents on ethical or moral grounds as well as on pragmatic grounds (and many of them will not apply for patents for these reasons). For more about the many who oppose software patents, you can see the ffii.org site and the League for Programming Freedom, including statements by software vendor Oracle and and a list of software luminaries opposed to software patents (including Donald Knuth). Dan Bricklin (inventor of the spreadsheet) explains why introducing patents to the software industry, about 50 years after the industry began (and after it had already been flourishing without them), is a mistake and hardship. AutoCAD’s co-author and Autodesk founder John Walker wrote “Patent Nonsense”, where he states that “Ever since Autodesk had to pay $25,000 to ‘license’ a patent which claimed the invention of XOR-draw for screen cursors (the patent was filed years after everybody in computer graphics was already using that trick), I’ve been convinced that software patents are not only a terrible idea, but one of the principal threats to the software industry... the multimedia industry is shuddering at the prospect of paying royalties on every product they make, because a small company in California has obtained an absurdly broad patent on concepts that were widely discussed and implemented experimentally more than 20 years earlier.” Forbes’ article “Patently Absurd” also notes the problems of patents, as does eWeek. One survey of professional programmers found that by a margin of 79.6% to 8.2%, computer programmers said that granting patents on computer software impedes, rather than promotes, software development (the remaining 12.2% were undecided). By 59.2% to 26.5% (2:1), most went even further, saying that software patents should be abolished outright. Professors Bessen and Maskin, two economists at the Massachusetts Institute of Technology (MIT), have demonstrated in a report that introducing patenting into the software economy only has economic usefulness if a monopoly is the most useful form of software production. This is concerning, because few believe that a monopoly is truly the most useful (or desirable) form of software production.

Paul Vick, lead architect for Visual Basic .Net at Microsoft, was required by his employer to file for a patent on an obvious pre-existing idea (the IsNot operator), which the patent office nevertheless granted -- Paul’s posting on Software patents states, “I don’t believe software patents are a good idea... software patents generally do much more harm than good. As such, I’d like to see them go away and the US patent office focus on more productive tasks... One of the most unfortunate aspect of the software patent system is that there is a distinct advantage, should you have the money to do so, to try and patent everything under the sun in the hopes that something will stick.... [overwhelming the patent system.] Microsoft has been as much a victim of this as anyone else, and yet we’re right there in there with everyone else, playing the game. It’s become a Mexican standoff, and there’s no good way out at the moment short of a broad consensus to end the game at the legislative level. as far as the specific IsNot patent goes, I will say that at a personal level, I do not feel particularly proud of my involvement in the patent process in this case.”

As patentability has increased, there’s good evidence that the number of software innovations has decreased. Bessen and Maskin also demonstrated a statistical correlation between the spread of patentability in the United States and a decline in innovation in software. In particular, between 1987 and 1994 , software patents issuance rose 195%, yet real company funded R&D fell by 21% in these (software) industries while rising by 25% in industries in general. This paper gives additional evidence that software patents are inversely related to innovation; it’s hard to not notice that as patenting become more common (e.g., 1987 and later) that the number of major innovations slowed down and are almost always not patented anyway. Although these only show correlation and not causality, other data suggest that there is a causal relation. Their more recent book, “Patent Failure: How Judges, Bureaucrats, and Lawyers Put Innovators at Risk” by James Bessen and Michael J. Meurer (Princeton University Press, March 2008) provides more information about the failures of software patents. Chapter 9 notes, “In Chapter 7, we noticed that patents on software and especially patents on business methods (which are largely software patents) stood out as being particularly problematic. These patents had high rates of litigation and high rates of claim construction review on appeal. This chapter [argues] that there is, in fact, something crucially different about software: software is an abstract technology. This is a problem because at least since the 18th century, patent law has had difficulty dealing with patents that claimed abstract ideas or principles... Such patents often have unclear boundaries and give rise to opportunistic litigation... Software also seems to be an area with large numbers of relatively obvious patents. For these reasons, it is not surprising that a substantial share of current patent litigation involves software patents... no other technology has experienced anything like the broad industry opposition to software patents that arose beginning during the 1960s. Major computer companies opposed patents on software in their input to a report by a presidential commission in 1966 and in amici briefs to the Supreme Court in Gottschalk v. Benson in 1972. Major software firms opposed software patents through the mid-1990s (for example in USPTO hearings in 1994). Perhaps more surprising, software inventors themselves have mostly been opposed to patents on software. Surveys of software developers in 1992 and 1996 reported that most were opposed to patents... Software patents... play a central role in the failure of the patent system as a whole. Any serious effort at patent reform must address these problems and failure to deal with the problems of software patents... will likely doom any reform effort.” Thus, not only do software patents fail to help encourage innovation - they actually inhibit innovation.

The book “Against Intellectual Monopoly” by Michele Boldrin and David K. Levine presents a number of evidences that software patents are harmful to the software industry and users. Actually, it goes much further, presenting evidence against patents and copyrights in general, but it’s the evidence against software patents that I find especially compelling. Patents are an economic adsurdity argues against patents in general, but has some additional words on the specific problems of software patents.

L. Gordon Crovitz’s “Patent Gridlock Suppresses Innovation” (Wall Street Journal, July 14, 2008, Page A15) states that “for most industries [including software], today’s patent system causes more harm than good... Our patent system for most innovations has become patently absurd. It’s a disincentive at a time when we expect software and other technology companies to be the growth engine of the economy. Imagine how much more productive our information-driven economy would be if the patent system lived up to the intention of the Founders, by encouraging progress instead of suppressing it.”

Bruce Perens explains why patents cause serious problems in creating and implementing standards. Since patents retard the creation and use of standards, they also retard the industry as a whole (since relevant, widely-implemented standards are a key need in the software industry).

The patented European webshop is an excellent illustration of the problem - it shows a few of the many obvious, widely-used ideas of grantedEuropean patents. In short, it demonstrates why patents are a poor match for software.

There are also many reasons why software patents are often granted that cover obvious ideas and prior art (which can give the illusion of innovation without actually having any). As noted by an FTC analysis of patents, in the U.S. about 1,000 patent applications now arrive each day, so patent examiners have from eight to 25 hours to read and understand each application, search for prior art, evaluate patentability, communicate with the applicant, work out necessary revisions, and reach and write up conclusions. (The article also notes -- somehow without irony -- that most granted patents are in fact obvious to practitioners, even though that is illegal.) Many other studies have noted that patent examiners have a poor database of prior art in software, so it’s hard for them to find prior art. But the biggest problem is that there are no incentives for anyone in the patent process to reject bogus patents. The patent applicant has every incentive to ignore prior art, the patent examiner has little time or resources to do this search, and a patent examiner who doesn’t commit enough resources to the search is rewarded (in contrast, a patent examiner who spends too much time on each patent will be punished). And it’s difficult for a patent examiner to declare something is “obvious”; after all, the people who are paying money say that their patent request isn’t obvious, and there’s little downside for an examiner to agree with the petitioner. Also, other areas of the software industry generally pay more than a patent examiner’s salary, decreasing the likelihood that a software patent examiner has the best software experience. The entire software patent examination process favors granting software patents for obvious and prior art. The patent “review” process has become so much of a rubber stamp that Steven Olson managed to obtain a patent on swinging sideways on a swing, an absurd patent that was granted the U.S. patent process.

It’s really difficult to figure out if something is really innovative. Several of the “key innovations” listed above are actually quite debatable. For example, is massively-parallel MapReduce obvious? It’s easy to argue that it is, and at the least, I am certain that someone else would have created it within a year or two, and I am very doubtful that the patent system incentivized its creation at all. Giving a monopoly on an idea that would have been created anyway, for no societal gain, is bad policy.

Frankly, I think permitting software patents in the U.S. was a tremendous mistake, and a misuse of the original patent laws. Very few of the innovations listed here were patented, and of the few that were (e.g., the mouse and RSA), there’s little evidence that granting the patents encouraged innovation. The mouse patent never made much money for its inventor, and although the developers of RSA did make money, there’s no evidence that they would not have developed RSA without the offer of a patent. All evidence seems to show that these ideas would have occurred without the patents! In short, patents impeded deployment and increased customer costs without encouraging innovation. The patent laws were originally written to specifically prevent patenting mathematical algorithms, and lower courts have basically rewritten the laws to re-permit patenting of mathematical algorithms (which is fundamentally what any software patent is). Permitting software patents has done almost nothing to encourage innovation nor award innovators, and the harm that it’s done far, far exceeds any claimed good. Most key software technology innovations were never patented, so tracking patents is certain to miss most of the most important innovations. Conversely, since patent examiners have a poor database of prior art in software and there are no incentives for anyone in the patent process to seriously search for prior art, software patents are routinely granted for previous and obvious inventions in software technology. Basically, the number of patents granted for software primarily shows how much money an organization is willing to spend to submit patent applications - it has nothing to do with innovation. The W3C has noted that its policy of ensuring that all W3C standards were royalty free has been key to universal web access; anything else would cause dangerously harmful balkanization. Vint Cerf stated that part of the reason the Internet protocols took hold so quickly and widely was that he and Dr. Kahn made no intellectual property (patent) claims to their invention. “It was an open standard that we would allow anyone to have access to without any constraints.”

“The Software Patent Experiment” by James Bessen (Research on Innovation and Boston University) and Robert M. Hunt (Federal Reserve Bank of Philadelphia) is a sobering less-technical summary of important research they did on software patents. They found that in the 1990s, the firms that were increasingly patenting software were the ones that were decreasing their research and development -- that is, patents are replacing research and development, not encouraging it. They found strong statistic evidence that patents in the software field do not provide an incentive for research and development -- the vast majority of software patents are obtained by firms outside the software industry which have little investment in the software developers required to develop software inventions. They don’t say it directly, but their research results seem to clearly show that software patents have become legalized extortion, instead of a means to encourage innovation.

The software industry’s solution has been to cross-license patents between companies, creating a sort of software patent detente. More recently, this has included cross-licensing patents with the open source community (through mechanisms like the Open Invention Network). Of course, such mechanisms tend to inhibit newcomers, so software patents’ primary impact is to prevent new ideas from becoming available to end-users, subverting the official justification for them. The only group that seems to be unambiguously aided by software patents are patent lawyers - and since they make the rules, they are happy to have them.

Of course, this fails when someone decides to sue. So-called "patent trolls" do not make products, only lawsuits, and thus have no reason to acknowledge detente. In the mobile space, Apple has decided to try to prevent the sales of all competition by filing patent lawsuits. The result has been more lawsuits, and less innovation.

Any statistic based on software patents is irrelevant when examining software innovation -- because today’s software patents have nothing to do with innovation. End Software Patents is an organization that is trying to eliminate the nonsense of software patents; I hope they succeed, since they are harming instead of helping innovation.

As I noted earlier, many important events in computing aren’t software innovations, such as the announcements of new hardware platforms. Indeed, sometimes the importance isn’t in the technology at all; when IBM announced their first IBM PC, neither the hardware nor software was innovative - the announcement was important primarily because IBM’s imprimateur made many people feel confident that it was “safe” to buy a personal computer.

An obvious example is that smartphones are not a software innovation. In the mid-2000s, smartphones rapidly became more common. By "smartphone" I mean a phone that can stay connected to the Internet, access the internet with a web browser capable of running programs (e.g., in Javascript), and install local applications. There's no doubt that widespread smartphone availability has had a profound impact on society. But while smartphones have had an important social impact, smartphones do not represent any siginificant software innovation. Smartphones typically run operating systems and middleware that are merely minor variants of software that was already running on other systems, and their software is developed in traditional ways.

Note that there are few software innovation identified in recent times. I believe that part of the reason is that over the last number of years some key software markets have been controlled by monopolies. Monopolies typically inhibit innovation; a monopoly has a strong financial incentive to keep things more or less the way they are. Also, it’s difficult to identify the “most important” innovations within the last few years. Usually what is most important is not clear until years after its development. Software technology, like many other areas, is subject to fads. Most “exciting new technologies” are simply fashions that will turn out to be impractical (or only useful in a narrow niche), or are simply rehashes of old ideas with new names. It is even possible that the emergence of software patents has impeded, instead of promoted, innovation in software, since many innovations occurred when software patents were not permitted.

Standards are extremely important in computing (just as they are in many other fields). In earlier versions of the document I noted that standards long preceded computing, and did not note them as an innovation. However, I’ve since added an entry for vendor-independent standards. The notion of having computing standards was not something that immediately came to mind in the computing industry - so the notion of having computer-related standards is now included above as an innovation. There are many important events in computing history involving standards, but very few standards are listed above as innovations... and for good reason. Standards themselves generally do not try to create significant new innovations, and rarely work well when they do. Instead, standards usually attempt to create agreements based on well-understood technology, where the innovations have already been demonstrated as being useful. Any significant innovation embodied in a standard was usually developed and tested many years before the standards’ development.

Other Technologies that are not innovative

Here are a few technologies that, while important, aren’t really innovative:

XML. XML is simply a simplified version of SGML, which has been around for decades. SOAP. SOAP is yet another remote procedure call system, employing XML (and often HTTP).

It’s okay to not be innovative

There’s nothing wrong with a technology or product not being innovative. Indeed, a technology or product should primarily be measured as whether or not it solves real world problems (without causing more problems than it solves). Linus Torvalds, creator of the Linux kernel, has stated that a pet peeve of his is that “there is a great deal of talk about ‘innovation’ and ‘vision.’ People want to hear about the one big idea that changes the world, but that’s not how the world works. It’s not about visionary ideas; it’s about lots of good ideas which do not seem world-changing at the time, but which turn out to be great after lots of sweat and work have been applied.” Instead, the Linux kernel (which has been wildly successful) is the result of lots of small ideas contributed by lots of people over a long time.

The focus of this paper is innovation, not utility. Do not confuse innovation with utility.

Clearly, humankind has been impacted by major new innovations in software technology. But the number of major new innovations is smaller than you might expect, especially given the many who declare that software technology “changes rapidly.” If you only consider major new innovations in software technology, instead of various updates to software products, fundamental software technology is not changing as rapidly as claimed by some.

I believe that this list is evidence that people are far more affected by other issues in computing than by major new software innovations. In particular, I believe that there are at least three reasons for the illusion of rapid changes in major software technology:

People have been able to apply computing technology to more and more areas due to rapidly decreasing costs. Computer hardware performance has improved exponentially, its size has dropped significantly, and its cost has decreased exponentially, making it possible to apply computing technology in more and more situations. The increasing hardware performance has also allowed developers to use techniques that decrease development time by increasing computing time; this trade reduces the development cost and time for software, again making it less costly to apply computing technology (by reducing the cost of software development). The idea of automating actions is not, by itself innovative, but automation can certainly change an environment. Increasing use begets increasing use. And when a technology is widespread or ubuiquitous, it often enables many widespread uses and social changes. In those cases, people are feeling multiple rapid social changes, caused by the widespread availability of a technology, rather than multiple rapid changes and innovations in the technology itself. When the web browser was first introduced, comparatively few people used it because there was relatively little information or services of interest to them available through it. But once some was available, other providers of information and services had users/customers, enticing them to use the WWW, causing an exponential increase in use. A service can become particularly influential if it becomes a standard (either because it’s formally specified as a “de jure” standard, or simply through widespread use as a “de facto” standard). The idea of creating standards is not new, but once something becomes a standard, the idea’s very ubiquity can mean that it will be widely used in places that it wouldn’t be used before. Software functionality can be changed over time, adding new functionality and generalizing a particular program’s capabilities. However, when functionality is changed over time, this often requires that the human interfaces change as well. As a result, people constantly have to learn how to handle changes in a given program’s interface. This gives some the illusion of constant innovative change in software technology, while instead, what is changing is a particular implementation.

Intriguingly, the richest and most powerful software company currently, Microsoft, did not create any major software innovation as identified in this list. Microsoft did not even create the first useful or widely-used implementation of any major software innovation. Others have come to the same conclusions, for example, see the Microsoft “Hall of Innovation”. This certainly casts doubt on Microsoft’s claims to be an innovative company. For more information about this, see Microsoft, the Innovator?.

In contrast, several major innovations were first implemented as open source software / Free Software (OSS/FS) projects, especially for those involving networks. Examples of innovations initially released as OSS/FS or first widely distributed as OSS/FS include DNS, web servers, the TCP/IP implementations on BSD systems to create internetworks using datagrams, the first spell checker, and the initial implementation of lockless version management. Tim Berners-Lee, inventor of the World Wide Web, stated in December 2001 that “ A very significant factor [in widening the Web’s use beyond scientific research] was that the software was all (what we now call) open source. It spread fast, and could be improved fast - and it could be installed within government and large industry without having to go through a procurement process.” This may be because the ideas of open source software are quite similar to research approaches in general, e.g., in both systems publications are available to all and can be used as the basis of further work (as long as credit is given). The paper Altruistic individuals, selfish firms? The structure of motivation in Open Source Software found in a 2002 survey of 146 Italian firms that their primary reason for supplying OSS/FS programs was that “Open Source software allows small enterprises to afford innovation”. For more information, see the information on OSS/FS innovation from my paper, “Why OSS/FS? Look at the Numbers!”

It’s important to not overstate the value of innovation. As noted in Shapin’s article What Else Is New?, just doing something radically different does not make it important. Indeed, we are surrounded by “old” technology that still serves us well. An useful innovation has to be useful, and not just be a new idea. That said, sometimes new ideas truly are useful, and when they are, they can improve our world.

In addition, it’s important to note that innovation is primarily a matter of incremental improvement and hard work. While I think it’s useful to note dates (where possible) for new innovations, it can give the illusion that innovation is primarily a matter of “Eureka!” moments that change everything. As noted in Eureka! It Really Takes Years of Hard Work (by Janet Rae-Dupree, New York Times, February 3, 2008), innovation is (primarily) “a slow process of accretion, building small insight upon interesting fact upon tried-and-true process.” Jonathan Sachs (co-developer of Lotus 1-2-3) similarly stated, “The rate of innovation is rather slow. There are only a few really new ideas every decade.” See Scott Berkun’s 2007 book “The Myths of Innovation” for more.

Software technology changes, but that is not software’s primary impact on us. Software primarily impacts us because of its ubiquity and changeability, as the computers that software controls become ubiquitous and the software is adapted to changing needs.

No list of “software innovations” can be complete. At the least, there is always the hope that there will be new innovations, ones that we have not even heard of yet. But innovations must be given time to see if they are truly important, or simply a fad that will quickly fade away. Another problem is that it is sometimes difficult to track backwards to find out when an idea was created, or by who. There is also the challenge of determining if it was really innovative, and what its impact was; in some cases I’m not sure if they should be in the list or not.

Some ideas have been identified that may be added to future versions of this document. Here are ones that aren’t currently on the list, but I may add someday:

Algorithms - Euclid (GCD), and before. Backus-Naur Form (BNF), a format for defining language syntax. Abstract Data Types (ADTs) - this preceded object-orientation, but a “first” use seems to be very hard to find. Big O / Complexity theory Hashes Transactions (esp. database transactions) - it can be a little difficult to determine the origins of the idea of transactions. David Lomet (who did key work in this area) has helpfully pointed out to me three papers, along with useful recollections of his: Obermarck, R. (1980) “IMS Program Isolation Feature”. IBM San Jose Research Report RJ 72879. [This was written about 10 years after the product containing the feature was released. IMS never quite abstracted the notion completely, but it the properties are there if one looks carefully.]

Eswaren, K., Gray, J., Lorie, R., Traiger, I. “The Notions of Consistency and Predicate Locks in a Database System.” Comm. ACM 19 (11). 1976 [This is the first paper that clearly identifies transactions in the context of databases. Several flavors are involved. Unfortunately, the title isn’t very transparent on this point.]

Lomet, D. Process structuring, synchronization, and recovery using atomic actions. ACM Conf. on Language Design for Reliable Software, Raleigh, NC SIGPLAN Notices 12,3 (Mar 1977). [Yes, I have some claim on this. I independently discovered the notion of “atomic procedure” while working with Brian Randell at the U. of Newcastle on system reliability.] Recursion (though this was a mathematical concept predating computers, and might not really be a “software” innovation at all) Database management systems (it is very difficult to trace back to the “first” ones) Operating systems (again, it’s very difficult to trace back to “first” ones) Aspect-oriented programming The “Page Rank” algorithm used by Google Directories (X.500 and before) - these are read-mostly databases, implemented later by LDAP (and still later by Active Directory) Bazaar-style programming/development (e.g., Linux; noted by Raymond) Open-source software / Free Software (see above) Fourth-generation programming languages (4GLs) Wiki+P2P (they change Knowledge distribution and coordination!). Data compression. It’s difficult for me to determine if this was “obvious” or not; I suspect it was obvious, which is why it’s not currently in the list above. My thanks to Aaron Brick for this interesting idea, as well as his pointing out the Shannon-Fano (1949ish) lossless encoding approach, as well as the lossy compression landmarks in the 1928 analog vocoder and the 1981 block truncation coding. Sketchpad Flowcharts. Flowcharts are actually older than the computer, and were used for process improvement, and is related to Scientific management. A key person in this field was Frank Bunker Gilbreth, Sr. (described in the delightful book Cheaper by the Dozen). However, flowcharts are essentially unused today (unless you count XKCD cartoons), and I think the other material already cited is more foundational, which is why it’s not currently on the list. Chomsky’s context-free grammars. I did include BNF (above). Technically these aren’t about computing, but are more general concepts that can be applied to computing as well. Leibniz’s work on Symbolic thought and Computation. I do include Boole and Babbage, and Leibniz is a towering figure in math, and his idea that human disagreements could be resolved someday by exclaiming “Calculemus” (“let us calculate”) has been inspirational. His work on binary numbers, and on developing machines to do arithmetic, make him a plausible addition. REST. In some sense, this is a pattern that pre-existed for years, and has more recently been identified as a pattern for use. In some ways, this is already covered by the Design Patterns item. Bulletin board systems (BBSs). I have Usenet, but Usenet created an interesting new approach for distributing data across a larger network. Bulletin board systems started off by more-or-less implementing an electronic equivalent of paper-based bulletin board systems, which is why I haven’t included BBSs. Software Plugin (suggested by Ciaran Carthy)

The Association for Computing Machinery (ACM) Software Systems Award is another good place to look for a list of software innovations. However, it is a fantastic list of important software systems and the worthy people who created them, many of these systems are not themselves fundamentally innovative. For example, James Gosling rightly received an award for Java in 2002; Java is an important programming language, but it is basically a well-engineered design that combined already-existing concepts, and was not fundamentally innovative in the way intended by this list. This is not to slight the important work by Gosling and others; it’s just that good engineering results are not the focus of this list.

My thanks to Robert Steinke for noting CSP and Lamport Clocks as key software innovations.

You can get a copy of this document at http://www.dwheeler.com/innovation. Feel free to examine my home page at http://www.dwheeler.com.