A couple weeks ago we gave you a broad history of some of the important milestones in the development of open source systems. We discussed the basic philosophy of open source, and how that philosophy is much older than software. Automobile manufacturers share industry data and patents. Smart phone manufacturers often share patents, too. This week, we will explore a little more history, as well as trace the patterns present in the open source philosophy that bear a surprising resemblance to the practice of law.
Open Source Success Stories
For starters, open source systems are not a chaotic free-for-all. The biggest success stories, in fact, possess certain elements recognizable to anyone familiar with service-oriented businesses. Let’s take a look at a few.
Unix is not the oldest operating system, but it is arguably the most important. Decades ago, the original Unix patent owners distributed Unix to academic and research institutions. While there were several reasons why this decision was made, this approach ultimately led to widespread use of Unix beginning in the 1970s. Researchers tinkered and worked on newer and better versions of Unix. In time, the widespread use of Unix in and of itself made it a desirable tool for enterprise businesses.
Unix didn’t give away the farm, though. Academic institutions initially had access to the Unix source code for the price of shipping. Anyone else who wanted it had to purchase a costly license. As we’ve previously discussed, these restrictions on the Unix code led programmers to develop their own Unix-like systems. One of the most popular of these systems is Linux.
Linux’s open source code challenges the business model of purchasing closed source software. Unix still exists, and has many children. But Linux’s popularity has made it the go-to open source system. There are pros and cons to both styles – closed source, and open source – but the major difference is this: Unix systems may cost more, but they come with enterprise support. Linux is a free and open source OS, which means an organization using Linux systems still needs to find support personnel to keep operations running smoothly.
Red Hat Enterprise Linux
A lot of organizations would rather out-source IT work, especially large corporations with plenty already on their plate. This kind of out-sourcing is often a more cost-effective and nimble IT strategy. Red Hat Enterprise Linux is one such service provider. Red Hat combines the best of Unix and Linux. On the one hand, Red Hat utilizes trademarks to prevent outright copying of their Linux system. This lends their license significant weight. On the other hand, Red Hat’s Linux code remains open source.
The advent of open source systems has shown that organizations don’t want to pay for code. What a successful business really wants, is support personnel who save it time and money. A team of developers working on an open source system can save a lot of time fixing problems that another developer half a world away may have already solved. That is a big deal, considering the data breaches and other major software flaws in the news over the past year or two. Flaws produce risk, and no business – especially a legal business – wants to expose itself to risk. An enterprise OS like Red Hat demonstrates a pragmatic balance of economic considerations on the one hand, and open source’s spirit of collaboration and innovation on the other. Code is free for anyone to see and implement, but expert support is essential to making sure that code works, and works well, for anyone who uses it.
Git is an open source revision control system used by many Linux developers. Built in 2005, Git was created in response to the sudden revocation of the software license for a revision control system many Linux developers had relied on. Suddenly without a tool to use, the open source community created one from scratch. Their innovative idea was to have a revision control system without a central server. This would allow any developer working with code on Git to work independently.
But why wouldn’t you want a licensed, closed-source form of revision control? Wouldn’t that be more secure? Sure enough, a security flaw was found in Git at one point. This flaw exploited a ubiquitous file-naming convention on Windows and Mac systems. It could have done a lot of damage. But the vast community of open source developers quickly discovered and fixed the flaw. A similar flaw in a closed source licensed product would likely not have been discovered, discussed, and fixed in such a brief span of time because only a tiny number of people would have even had access to the code. Notable also is that this security flaw never impacted Linux’s open source systems. And this is far from the only case where well-traveled open source developers have found and fixed security flaws with relatively little collateral damage.
GitHub, a popular site based on the same principles as the original Git, is used by millions of companies and their development teams. We at LexPredict use GitHub for our code as well. GitHub allows multiple developers to work on code from any location. It keeps track of code branches (multiple versions existing at the same time), code updates, and merging of new code with older versions. It’s fast, low-stakes, and is better at merging code from multiple contributors than past systems were. With GitHub, changes and improvements to software are easy to see, easy to patch, and if errors occur, those errors are easy to undo or fix. A revision control system is a major factor in an open source system remaining both functional and secure.
Coders can’t work without a revision control system. But coders aren’t the only people who use such systems. Revision control keeps track of additions, changes, and removals from all sorts of documents in a myriad of collaborative working environments. Google Docs is a simple example of this. An even simpler example is a spiral notebook with strikethroughs and marginalia. A lawyer’s decision-making process even looks similar to a revision control operation, when you look at it in a step-by-step diagram.
Sharing Knowledge; Asking Experts
Software developers bring valuable expertise to every company operating in modern times. Developers have versatile skill sets, and because of open source systems their work is also relatively transparent. In that way, software developers are comparable to lawyers and other legal professionals. Think about the law. Every citizen can access the law, can’t they? (Perhaps with some difficulty.) Right now, you could open up a new browser window next to this one, and start reading any section of the U.S. Code. Or maybe patent law is your thing.
Does the legal profession suffer because all citizens have access to the law? No. Every day, millions of people request the services of legal experts. Not only that, but it’s considered dangerous to represent oneself in court without legal aid. You need a legal professional to get you through virtually any contact with the judicial system. A person may know the general contours of the law – we all know robbery is illegal, and we all know what Miranda rights are – but that doesn’t mean the average person can go toe-to-toe with a prosecutor in front of a judge.
The information lawyers use to litigate matters is available to everyone, but we ask for help from lawyers because they are experts on this information. They study it for endless hours across years and decades, and they learn how to practically apply that knowledge in novel, effective ways. A team of open source software developers operates from a similar point of view. The substance may be different, but the style is the same.
LexPredict is far from the only company integrating legal expertise with software expertise. Developers design a software tool, and then professionals use that tool and provide feedback to improve its operation. Then developers can work on fixing those problems, and return the improved software to users. Rinse and repeat. An open source system makes this cycle operate much faster, and much smoother, steadily and constantly improving and refining processes over time. We’ve implemented such a workflow with our own ContraxSuite platform, and are already seeing amazing results.
What could your organization do with a powerful team of legal and open source software experts?