Do "The Right Thing ™"


Open Source Stands the Test of Time

Twenty years ago this past February, the Apache HTTPd server project formed. I’m in Austin, TX this week at the ApacheCon North America 2015 conference to join a few of my colleagues in celebrating our accomplishment and to reflect on the software, the process and history itself. The past twenty years has had its share of ups and downs but after taking some time this past few weeks to reflect on everything that has happened over those past twenty years, it is a bit surreal to consider the impact of technology on our lives and generally, what the entire software landscape has become today. Especially as it relates to the Internet and to our general connectedness.

Just to set the stage for the technology environment twenty years ago, here are a few little known facts about the Internet software marketplace in 1995.

  • Just the year before, in 1994, the acceptable use policy had changed to allow businesses to create a website and establish a commercial presence on the Internet. Before that change, any access to information over the Internet was through universities and research organizations, and everything was delivered in text only terminal interfaces. No graphics, no advertising, no Facebook.

  • Microsoft was still pursuing their own proprietary networking protocol and could not connect to the Internets without use of third party networking protocol stacks to enable connection to a TCP/IP network.

  • There was no commercial HTTP protocol web server to serve web pages to the one or two web browsers that had been created at this time. No Internet Explorer, no Firefox, no Safari, no Google anything.

Over the past twenty years, I’ve answered the following question many times; “Why did you guys do this for free? Why didn’t you create a startup during the Internet boom to take advantage of the opportunity?”

At least for me, (and I am pretty sure the same holds for my Apache web server colleagues), we had all been participating in the volunteer effort of creating critical pieces of computer software technology through this same process that later became known as Open Source, so the decision to find like minded individuals and start the process of building a better HTTP web server was standard operating procedure in that point of our young careers. I know I didn’t really consider any other path for obtaining this core Internet technology. I am confident that my peers didn’t either.

There were however, a few other parallel attempts to create commercial HTTP web server offerings. Today, after twenty years, none of those commercial competitors challenge the fact that, out of nearly 900 million web servers found on the Internet, approximately 40% of web servers are still running the Apache HTTP server (in 2005, 70% of Internet web servers were running Apache). And the only real survivor in the commercial competitors that challenged the Apache HTTP server is the Microsoft server IIS which is provided for free. I’m not sure how that compares to other software technologies in use today, but I have an overwhelming sense of pride in having been a part of creating this legacy. But there was a significantly more important reason NOT to commercialize the Apache web server and to instead offer it under a software license that allowed any company to use the software in their own software products, free of charge or other encumbering license terms. Simply stated, it was important for the future of the internet to make sure that it was easy for companies to use a standards compliant HTTP protocol stack in their products in order to assure that service communications on the internet were reliable and compatible.

Open Source means Open Standards

One of the little known battles that were fought as part of the creation of the Apache HTTP server was that of HTTP protocol standards compliance. The HTTP protocol is the language used to communicate between a web browser and a web server, or a mobile application and a web server. If for some reason, a web browser or web server software developer decides to deviate from this standard communication language, Bad Things™ happen that result in your web browser not being able to connect to a specific website or your mobile application not working. In the early days of Internet software development, there was plenty of positioning by commercial software companies to be the one Web browser or Internet service provider that would become the leading company.

This exact scenario played out in the weeks leading up to the Christmas Holiday in 1997. Just to jog a few memories.. one of the leading Internet Service providers back in the late 1990s was America Online (AOL). Many Internet users used a modem to connect to the AOL service and then used the AOL web browser to connect to websites and “surf the web”. If you connected to the Internet through AOL, you connected through an HTTP proxy that would speak the HTTP protocol to request web pages from the growing number of web servers on the Internet. In the weeks leading up to the Christmas holiday that year, for some reason, AOL decided to deploy a software change to their HTTP proxies that deviated from the standard HTTP protocol as it was defined by the technical RFCs. Now it is entirely possible that this change was innocent and simply a misinterpretation of the standard, but the net result was that AOL users would not be able to access Internet vendors that were outside of AOL’s control and instead would be limited to accessing the vendors and services that were provided within the confines of AOL. AOL users and vendors outside of the AOL domain cried foul as we started facing our first test of the established HTTP standards.

Several members of the Apache HTTPd server project were hosting some of the largest commercial properties and brands on the Internet, myself included, and we immediately began feeling the heat of finding a solution and getting the holiday season back on track. After identifying the problem and getting connected to the right people at AOL, AOL was educated about the impact of their deviation and within days, had reverted the change back to the accepted standard.

This exact scenario is why I have participated in the Open Source development process and community beginning back in the late 1980s. It is the effect of widely deployed and easily acquired software technology that makes it easier for all software development companies to participate in this highly connected world, without having to think much about the communication protocols that make it happen. Had the Apache HTTPd server project not existed, it might very well mean that you must have different web browser software installed to go to different websites. While I am confident that the Open Source community would never let that scenario play out, just know that without non-profit software development organizations like the Apache Software Foundation, many of the Internet of Things we take for granted today would not exist.

Repeating the Same Mistakes

Today, a perfect example of where this same standards battle is playing out again, is in the Healthcare industry, where the giants of the Electronic Medical Record software companies are drawing battle lines to decide what the data exchange standards will be. As it currently stands, there are at least two different standards efforts that, at best, will result in even greater expenses paid by healthcare providers and ultimately, healthcare consumers. Rather than take the obvious approach to create one open standard to make it simple for all healthcare software developers to exchange data, the two camps see financial motivations to create their own standards and lock in their customers their own preferred software suite.

This competitive tactic has been tried repeatedly in the software industry over the past few decades and nearly every time, the company building a proprietary solution becomes the loser. These companies need to look to provide innovative solutions that use the same standards to communicate between other software and services. Holding your customers hostage is no way to build an industry leading product.

It’s time that these companies take a page from the success of the Open Source software development communities and embrace the idea of truly Open Standards.

Back to blog