Try reloading this page, or reviewing your browser settings
This video segment explains how open source software is routinely developed ‘in the open’, allowing users to see how their program works and how decisions are taken. However, as this segment also explains, transparency is not much use unless you can understand and leverage it.
- The Four Freedoms
- code visibility
- risk mitigation
About this video
- Karl Beecher
- First online
- 25 December 2018
- Online ISBN
- Copyright information
- © Karl Beecher 2019
[Audio Begins] [0:00:00]
Karl Beecher: Of all the distinctions between proprietary and open source software, transparency is among the clearest cut of them all. But even here, there’s more to it than a simple binary divide of transparent and not transparent. Within open source software itself, there’s various levels of transparency. Nevertheless, the right made explicit by free software foundation’s four freedoms and the open source definition guarantee a minimum level of transparency that practically no proprietary software can. The source code to your open source program must always be made available alongside the program itself. So immediately, that brings certain benefits.
For one thing, reading the code means you can see exactly what your program is doing, whether it’s just for your curiosity’s sake or whether you want to do a proper audio of the code, looking for bugs, security breaches, and other undesirables. When fixes are made, or new features are added to the program, you can see exactly what changes these updates bring by comparing the new version of the code with the previous version.
Also, this availability of the code acts as a kind of risk mitigation and the guarantee is that you have the option with open source software to try before you buy, so to speak. By testing the software yourself, you can see first-hand whether the software meets your requirements and solves your problems. Commercial proprietary vendors won’t necessarily allow this, and even if they do, you might only gain access to an incomplete or time limited version of the program.
It might be hard to see any drawbacks to increased transparency, but there are some things worth knowing before considering it as an absolute win. Obviously, this ability to see the code is only beneficial if you actually understand it. In fact, among open source programs, source code is something of a lingua-franca, and prized of much else in communication. Attitude encapsulated in a code and Linux inventor Linus Torvalds who once remarked, “Talk is cheap. Show me the code.” Now, if you don’t speak this lingua-franca, vendors of commercial proprietary software at least have a sales team on hand, so you don’t have to. Open source products don’t. Instead, the public face of an open source product might be merged with the same online infrastructure the authors used and managed development, either on its own website or via a repository management service like GitHub or BitBucket. This is by no means guaranteed. Some projects do their development offline or in private. But a product that does manage development publicly provides access to several things like a task tracker, listing reported books, features under construction, open tasks and other issues. Even after a task is closed, it remains visible for archive purposes.
Wikis, in addition to providing things like user manuals and tutorials might provide published reports, proceedings from meetings, road maps or other organizational material. Since open source developers often have to meet online and organize themselves virtually. Speaking of which, the programmers on a project often chat with each other via Instant Messenger. And it’s common to allow the public access too, so users can rub shoulders with developers. An inclusive development method promotes trust and makes it easier to contribute back to an open source project. But once again, you need to keep in mind that the discussion can operate at a very technical level. The people working on an open source project are not sales people. There’s no guarantee that they’ll be cooperative or congenial.
Also, you should be on guard against documentation that’s either out of date or missing altogether. Documentation might sometimes be lacking in proprietary software, but open source documentation, often held in wikis, can be worse in this regard. That stems from the fact that open source software developers are often working voluntarily and can choose what to work on. Writing code is the sexy part. Writing documentation is usually seen as dull.
In fact, if you’re wondering what source of information reflects most accurate the state of the software, I’d suggest the following guide. The code, being the actual program itself, is automatically the most accurate reflection of the state of the program as long as you’re looking at the correct version. Somewhere in the middle, commentary you find either in task trackers or among developers in online chatrooms can be considered reasonably trustworthy, but not automatically so. Whereas, you should be on guard when browsing a project’s documentation. It might have been long-neglected or written quickly as an afterthought. If you’re suspicious, check the date on the last updated field or question the developers directly.
In summary, transparency is perhaps the clearest win for open source software, but transparency is not much use unless you can actually understand and leverage what you learn.
In the next segment, we’ll look at quality.
[0:05:12] [Audio Ends]