Blog

Problems in Open Source

Last week we discussed some successful open source systems. We also defined some general, but important similarities between open source work product and that of legal professionals. Anyone in the legal tech space – whether they’re a recent law grad, a paralegal, a long-time partner, an IT professional, or an outsourced coder – can learn a lot from the other unique voices in the wider field.

There are some weaknesses in the open source approach, though. Transparency can lead to vulnerability. Projects with small development teams can be difficult to scale safely and effectively. If code doesn’t work right, who do you call? How do you know they can fix your problem? These areas of concern have serious implications for the longevity of open source. This is why the community is hard at work creating new code, tools, and strategies to overcome vulnerabilities.

Security Vulnerabilities

Even if you know next to nothing about software, you probably know that code sometimes has vulnerabilities that malicious hackers can exploit. The ransomware attacks of 2017 have let up in severity and frequency, but they remain a danger in 2018. Meanwhile, other forms of malware are as pervasive as they have been for years.

The solution to the dangerous potential of hackers usually involves some combination of secured protocols, awareness of hacking and social engineering traps (e.g. email phishing), and licensed closed source code. On these fronts, large software companies like Microsoft often make the news. They release patches and version upgrades on a regular basis. This is a viable strategy, but sometimes these patches and updates come weeks or months after a significant problem has been exposed. Thankfully, these timelines are getting better and better.

In fact, you might be inclined to say that enterprise closed-source systems such as Microsoft Windows are the best way to go. For your operating system needs, this could work out just fine. For anything smaller than a whole operating system, the advantages of open source over closed source are a bit harder to suss out, as in this case from Microsoft interfacing with Google’s Project Zero. At the end of the day, making sure software from multiple sources is compatible can be a difficult, time-intensive process. No matter what your situation, the crucial game-changer will often be the people and processes deployed to attack these problems.

And you might ask next: What about GitHub? No conversation about security vulnerabilities in open source would be complete without mentioning GitHub and other online code repositories. Isn’t it a double-edged sword? A malicious coder could gain access to a GitHub repository. That person could then publish code to that repository which then gets delivered to a third party. Serious problems ensue.

But open source is not the Wild West, and GitHub is a well-policed community. Any user can monitor the status of a piece of code. Just as easily, though, code can be made private so that only trusted parties have full access and the ability to publish code. With this type of monitoring, as long as you have coders on your side, the functional differences between closed source and open source fall away on this front. As we mentioned last week: If software and QA teams are doing their jobs, flaws in code create minimal risk. It always depends on how many sets of eyes are scanning for flaws – and how good those eyes are.

So How Do I Get Good Support?

Paying for in-house IT isn’t all that cost effective. If it were, open source software might not have such market potential in the first place. The good news is that there are companies all across the legal services landscape that specialize in developing and implementing software. (You’re on one such company’s website right now.) Open source software is better for these kinds of operations, largely because a team of developers can learn and adapt known code much quicker, and much more effectively, to an organization’s needs. The business model operates either under a software-as-a-service (SaaS) model, a licensing model, or some mixture of the two. Sinking money into closed source software may be cheaper in the short term. In the long term, though, it isn’t nearly as effective as investing in knowledgeable people who know the best ways to wield that software. If one of your servers crashes in the middle of the night, you don’t want to worry that you cut too many corners.

As we mentioned above, one thing to look out for at this stage is whether your organization’s needs have the proper software support resources. The best open source systems in the world may still fail if you don’t have enough people manning the battle stations. But the flip side is that if you’re unsatisfied with your support resources, you don’t have to worry about a closed source provider’s monopoly on expertise stifling your choices.

Remember:

  • Maintaining good security requires constant upkeep
  • Proper support means proper resources for your operation
  • Support should scale with usage growth

Standards

So let’s say you have some developers. They know your security needs, the needs of your day-to-day operations, and they possess the requisite expertise. How do you know everything will run smoothly? What guarantees are there in the open source world? You’re just using a few ownerless pieces of software, right?

The open source community has worked for a number of years to create a single unifying set of standard practices. Several of the largest standards bodies and internet research organizations are working toward backing the Open Standard. The Open Standard consists of five core principles:

  1. Cooperation: Each standards body respects other bodies’ autonomy, processes, and intellectual property
  2. Principles: Adherence to due process, broad consensus, transparency, balance between competing interests, and openness
  3. Collective Empowerment: All standards bodies contribute to a synergistic global community valuing interoperability, competition, and innovation
  4. Availability: Everyone has access to standards specifications
  5. Voluntary Adoption

Different organizations follow different definitions, and a lot of disagreement remains among various international standards bodies. Many also worry about the anonymous, abstruse “black box” nature of code and its potential effects on law and freedom. Nevertheless, the five principles of the Open Standard codify much of the open source philosophy. Any company that follows this set of principles, or one that adheres closely to this set, has committed to a high standard of software development and implementation.

Conclusion

Many of the problems in open source are attributable to humans: the errors we make, and the motivations of certain bad actors. The solution, no matter what product you use, is to remain diligent. Software developers and systems administrators will have an outsize impact on the response to, and solutions for, flaws and exploits that can cause dysfunction and damage. Having a dedicated group of professionals to guard code and take charge of its improvement is thus of paramount importance. Enterprise support is a key factor in this, and a major reason why software companies succeed or fail.

We’ve learned so far that the philosophy behind open source is not new. Software is new, though, and open source software even newer. In discussing either game-changing technologies or ambitious philosophies, there must always be room in the discussion to mention growing pains. The internet may no longer be the Wild West, but we have only begun to see the potential of open source. Innovation is rampant, security is improving, and standards are rapidly developing on a daily basis. Continued evolution, and more lasting improvements, are sure to follow.

Comments are closed, but trackbacks and pingbacks are open.