Day 1 Reading Summary

For the first day of reading material we were to read two articles about the history of the FOSS movement from the standpoint of the GNU project, as well as the broader open source movement. For those reading, FOSS is short for, Free and Open Source Software.

The first reading, which was the first 32 pages of the book Free Software Free Society: Selected Essays of Richard M. Stallman (now referred to as FSFS), which covers the history of FOSS from the standpoint of the founder of the GNU project.

In reading the book we see that the origins of free software can be traced back to the MIT AI lab in 1972. At that time, it was considered the expectation, not the exception for the sharing of software including source between individuals, academic institutions and the the private sector. Quite simply source code could be read, changed or cannibalized for future work. This is a key principle to the current FOSS movement.

One could make the argument that the 1970s were the early days of computing. There are two things that we know about the early days of any field:

1. there are always few people at the beginning of a vacant field
2. there is little known about the vacant field

Therefore it should come as no surprise that a community will inevitably form for the field to eventually become successful, and that the community will share discoveries and work to further mature the field in a free manner. As the field becomes mature, and as there are substantial commercial opportunities, the culture of the community changes to increasingly a proprietary one, where businesses seek to maximize their investment spent in the field. This is precisely what happened in the computing field, as the FSFS book notes.

The book then goes on to explain three assumptions that the proprietary software markets takes for granted when they make claims against free software:

• they have the right to own the software, regardless of how powerful it is or whether it harms others
• all that matters is functionality in software, and that we shouldn't really care about rights
• no usable or useful software comes from non-propritarey or free software

Rather than argue the first two assumptions that the book claims the proprietary software market takes for granted, I would like to argue the third point since this is a seminar on open source usability.

I would disagree with the notion that there is no usable or useful software that comes from the free software community. A good example of useful and usable software is the Mozilla project, and in particular the Firefox web browser. In the matter of a couple of years they have become the most popular desktop web browser (46.4% according to http://www.w3schools.com/browsers/browsers_stats.asp at the time of writing). We know that a good measure of whether software is both usable and useful can be determined by how popular a piece of software is. If people find a software package to be useful (i.e. serving their needs), chances are they will keep using it. Therefore, Firefox passes the test, and disproves this third assumption.

However, an argument could be made that there is a strong incentive for proprietary software companies to increase their user base and hence their market share to boost their bottom line profits, as they would be selling more licenses. If you want to boost your market share, one very effective way to do so, is again to make it so that the capability provided by the software is considered useful by the end users, and furthermore that the software is considered usable by the end users. Furthermore, Firefox seems to be an exception to the rule about open source usability and usefulness and not the exception. One can think of various open source projects (for instance The GIMP), where either the usefulness or the usability (a superset of usefulness) come into question. Part of the problem is that there is not as great an incentive to have a large user based as there is in the proprietary software world.

A major complaint, in fact about many FOSS projects is the missing or lack of documentation for the projects (both technical for improving and extending the software, as well as end user documentation). One of the first things that a patient users will fall back to is the documentation to see if it offers guidance on the issue that they are experiencing. When a software product (free or otherwise) lacks adequate documentation and support, users will be less likely to continue using the software product when they get stuck learning the software product. Furthermore it is easy for someone to toss away an free open source solution (especially if it costs them nothing), than it is for them to throw away proprietary software that they have paid for since they have made an investment in the software. This lack of documentation and support not only makes users think that a FOSS project is unusable and thus effectively useless, it also poses the danger of making the user think that all FOSS projects are of the same quality in terms of documentation and usability. This generalization has the danger of making many stay away from FOSS solutions and stick to the proprietary solutions that their colleagues use and trust, which in turn can slow the progress of the FOSS movement.

Switching gears for a moment, the FSFS book clearly defines the principles of free software:

• freedom to run a program for any purpose
• freedom to modify the program to suit your needs (i.e. access to source code)
• freedom to redistribute software (free or for a free)
• freedom to distribute modified versions of programs so that others may benefit

If we use these definitions to define the free software movement then we can see that there are many software models that support this philosophy. One of the first examples of this was when Richard Stallman would charge money to mail out copies of EMACS and other software to those who did not have access to the internet. In that way he could stick to the principles of FOSS while at the same time make some money to help keep his operation running. Other companies (such as IBM) have embraced and used the free software philosophy for their software business models, albeit in different ways. As Richard Stallman mentions, he and his foundation is against business but rather the proprietary, "closed shop" software model.

What I find most satisfying so far about the free software movement is the possibility of leveraging the energies of many developers worldwide to create world class software, for low to minimum cost, while being able to create a financially viable venture from it.

One challenge that I initially had in embracing open source software was the complexity of their licensing models, and certainly the efforts of proprietary software companies to create FUD (fear uncertainty and doubt) about this issue via elaborate marketing efforts. However, the book does a good job at explaining these otherwise cryptic license models and the reasoning behind them.

There are two primary licensing models that GNU supports for a package to become part of GNU: GPL and LGPL.

The GPL (GNU General Public License) is the most restrictive of the two licensing models. It requires that any changes or derivative work, or where the proprietary software is combined with the GPL software, must also become free software (see above for definition of free software). This is done so that no one can take the work done on free software, improve it (either trivially or otherwise), and make the derivative work unfree software (as is the case with other "free" licensing models, as well as public domain software).

The second license the LGPL (GNU Lesser General Public License, formerly the GNU Lesser General Public License), is essentially the GPL license except that it allows for proprietary software to link to a LGPL library. If you are a proprietary software developer this is great because as you can incorporate the progress made in the free software world into your software product, and not have to contribute back to the community as well as indirectly "close up" an otherwise free project. On the other hand the license was designed so as to attract proprietary developers to the free software world. Otherwise the availability of important software in the free software space would have been severely limited, which would have limited the success of the FOSS movement. Obviously how to balance the interests and principles of the free software world as well as the reality of the need of certain proprietary software packages has been a moral dilemma throughout the history of the GNU project.

A key principles that the open source community can learn from Richard Stallman (which he mentions in the book), is the application of standards and best practices when possible which is practiced whenever possible in GNU packages. This is especially true for usability, where this tool can be used to achieve a consistent user experience, through the user of HIGs (Human Interface Guidelines), as have been applied in the Microsoft and Apple worlds. Furthermore the application of standardized design principles can act as a gestalt for effective interface design. As we survey the FOSS community we notice that few take Richard Stallman's advise to heed, we see inconsistent user experience across software packages, as well as unfamiliar and unusual interaction paradigms that confuse and frustrate first time users (even computer nerds) of the software package.

Finally, in this reading of FSFS, the author goes elaborates on what he feels are threats to the free software society. Rather than discuss each issue on its direct technical merit alone, I will discuss these issues in the context of usability.

The first threat the author uncovers is secret hardware, which is the practice of many hardware companies to not disclose the specifications of their hardware. In turn this makes it difficult for hardware to be supported on a free platform, especially if the manufacturer is unwilling to write free drivers for the platform. As a result, many free operating systems lack support for various hardware (sometimes critical components such as network cards). When users install free operating systems on hardware that lacks support for such secret hardware, the user experience limited capabilities from the operating system. As an example should a network card installed on the users computer not be supported by the operating system, they will likely not be able to access the internet. Due to this difficulty, the user would be unable to effectively access the internet, which severely impacts the usefulness of the operating system in the mind of the user (thus impacting usability). In fact users have left free operating systems due to this usability issue alone, as the time it would take to "hack" around this problem is significant (i.e. writing a driver), or may require knowledge that the user may not have (i.e. looking through google on another computer and typing cryptic commands and editing cryptic and vital system files).

A related but slightly different threat to the FOSS software community mentioned was non-free libraries. A library is software that is used by developers and distributed with software packages that implement certain functionality (for instance toolkits for Graphical User Interfaces). Essentially these non-free libraries are promoted to the FOSS community as effective libraries that handle tasks that developers need to get done (such as drawing a window on a screen). However, the libraries are licensed in a non-free manner (such as limiting the redistribution of the library and not sharing the source). As a result a lot of free operating systems as well as free software in general prohibit the inclusion of packages that make references to these closed packages to maintain the free software philosophy. However, the unfortunate price that free software developers have to pay is that they must now code tasks that a proprietary library would otherwise take care of (often times in a elegant way). As a result features and capabilities that make free software more usable (and useful as a result) are delayed or not implemented to due the limited amount of free libraries that are out there.

Software patents pose yet another challenge to the free software society as they could outright prevent the FOSS community from implementing technologies in a software patent. The only way the FOSS community can implement such innovative ideas, is either through challenging the software patent and having it invalidated, or to create an alternatively implementation of the idea which doesn't violate the patent. If both techniques fail, then the free software community simply cannot implement the functionality covered by the software patent. As a result features and functionality that are considered useful to everyday users (such as the ability to encode MP3s), may not be able to be implemented in the free software, which again impacts the usefulness of the software and hence the usability. Furthermore, patent laws can further hinder innovation by making it difficult to produce derivative work based on work covered by patents, meaning that you cannot even go so far as to create a new innovation that is based on the patent. As a result the progress made in an area of free software can be stunted by decades (or as long as a patent covers)! This poses a significant hinderance to making free software become mainstream.

Next, I shall discuss the readings from the book

Open Sources: Voices from the Open Source Revolution (abbreviated OSV for brevity)

The introduction's view of Richard Stallman's vision for free software is mostly consistent to the view held in FSFS (written by Richard Stallman). One glaring difference, was commentary offered by the author who argues that the GNU project was started simply so that no one would ever pay for software. However, in reading FSFS, Richard Stallman contradicts this view, stating that not only is making money from free software for money is not only acceptable, but was something that he did in the very early days with the distribution of EMACS.

The OSV book discusses one major issue that faced the open source community in its early days (especially during the 1990's) which was the perception that the free software and by extension the open source community was inherently anti-business (partly due to philosophy as well as

practice as can be infered from reading FSFS and OSV). However, in 1997, members of the free software society met to come up with a marketing plan and framework called the, "Open Source Definition," to change this perception. Not only did this plan address the perception that faced the community (that it was anti-business), but also settled long standing issues in the community such as the fighting between GNU and the KDE desktop managers on licensing matters.

If we view the open source movement from a usability standpoint it is important to understand that a key requirement of usable software is that the software is being used by the community. In principle this means building a large enough user base to make such a claim. However, the perception that the open source movement was inherently anti-business scared many potential users who viewed the movement as a threat. Therefore, it was important that they resolved this issue, otherwise usability would have suffered.

Open source software being a commodity market where brand management, and perceptions of the experience count, as opposed to the affordances provided by proprietary solutions (that is that the IP is owned and controlled by a company), exposes a new insight into open source usability. One of the main tenents of usability and design is that of user experience.

In traditional software (i.e. proprietary software), while usability was an important consideration in the software development lifecycle, it was not the only and certainly not the most important factor in developing a solution. Often times it was the functionality that was built in (and the surrounding IP produced), where companies would focus most of their attention and effort in. However, the free software movement changes that focus for companies, as now experience does count, as function is largely taken care of by the open source community. Therefore one should expect and demand that companies delivering open source solutions provide their customers with exceptional user experience through good design and usability, as this freedom is now afforded to them more so than with propreitary software.

However, one could make the argument that open source companies are expected to give back to the open source community they take from, so that they are not considered freeloaders and hence to preserve their reputation in the community (as the OSV book makes). While I agree with the argument made by the OSV book, it should be noted that in general less time will be spent on functional/feature development in open source by an open source company as compared to proprietary software businesses, as the greater open source community has contributed a great deal to function and feature improvements so that open source companies can work with mature technologies to base their solutions on.

The topic of open source businesses brings us to the next logical topic which is how to make money off of the open source movement. As was already noted, Richard Stallman in the early days made money distributing GNU tools on disk to other users, and in that we he supported his development efforts. Many companies such as IBM and Sun integrate their hardware and software with open source solutions as well as to sell support, training and other services directly relating to open source technologies. These companies have proven that one can make a significant amount of money through the model of integration and services related to such free software. Two other examples provided by the book which were interesting was that of consultancy services (i.e. custom work for open source solutions), as well as a tiered licensing approach, where you have a free edition that costs nothing, and a Professional edition that costs money but provides functionality that is a year ahead of the free edition. What I like about the latter model is that it forces software companies to innovate, as they always need to make improvements on what they have to continue to be able to sell these higher tiered products.

There are many benefits of free software and the greater open source software that were noted by OSV. They include a degree of transparency that allows for bugs to be caught earlier, and for fixes to be applied more rapidly, reducing the habit of constantly reinventing the wheel everytime you need capability that is already being provided in a well designed library, worthy projects never go stale (i.e. do not get updated) meaning that code can outlast developers and even companies and the affordance of rich interactions between complementary products. I will briefly discuss each of these points as it pertains to usability.

First and foremost the concept that the inherent transparency allows for bugs to be caught earlier and for fixed to be applied more rapidly is one that is extremely useful from the standpoint of usability. Currently, proprietary software prevents us from making changes to their packages to make the software better designed from a usability standpoint (due to lack of source code). As the FSFS book notes with proprietary software, users are forced to beg software companies to improve their design and usability. Furthermore the community of users and testers means that a richer degree of usability information that can be collected, and the transparency of the solution also allows designers to get a better understanding of the software architecture, the better to make more informed decisions when it comes to design.

Preventing the constant "reinventing of the wheel," in the software world is an issue that has been studied for decades by the software engineering field. Commentators such as Larry Constantine, have written entire articles and books on the subject due to the lack of library and code resuse, even with object oriented technologies that long promised to solve this issue. The open source community provides now has a repository of useful library, code and implementation details to allow developers to develop software solutions more effectively. Furthermore, the widescale availability of libraries that support various types of user interaction (for instance interacting with a touch screen device, or using a keyboard and mouse), means that software can now leverage the best practices from usability in the form of libraries, which again will act as a gestalt for the good design of interaction. This in turn has the promise of rapidly improving the usability of software solutions through the widescale availability of such implementations.

The concept that worthy open source project never get out of date, due to a loyal community of developers who continually improve the software has several major implications for usability. The a main tenent proprietary software model the concept of planned obsolence. This is the concept that a given release will not be updated after a certain period of time and that the user is expected to upgrade to a newer version of buy a separate product. The inherent usability issue of this is that the eventual lack of updates means that software will become less useful and used over time, as new platforms become incompatible with the older unsupported software. In addition, new features in the software and new paradigms will not supported in these older unsupported releases, meaning that their usefulness diminishes rapidly (due to the functionality gap rapidly increasing over time), as well as new paradigms make the old ways of working less viable. Furthermore, proprietary software prevents or severely limits the ability for customers to further expand their solution to make it become viable (by adding missing features, or capabilities), due to the lack of source code.

The possibility of integration and interactions occuring between software packages can also add to the overall usability of a software ecosystem. For instance, you could have a free accounting package that interacts with a free order management system, so that users do not have to manually keep these two systems synchronized. By making specifications, APIs and source code open to the public this affordance is much stronger than with the proprietary interaction model, where the source code is closed, and interactions can only take place through a well defined (and perhaps limited API), which requires customers to sign agreements that severely limit their rights (such as Non-disclosure agreements NDAs).

The ability to coordinate and develop software applications on a large scale is yet another appealing aspect of the greater open source community. In the proprietary software world it is quite difficult to build software of scale due to the politics, bureaucracy, and policies of many organizations that cause software development and innovation to occur at a glacial speed. As Larry Constantine proves in his book, The Peopleware Papers, as well as Frederick Brooks discusses in his book, The Mythical Man Month, it is not the lone software cowboy who develops a successful software system of size and scale, but rather the efforts of a well managed team.

While the OSV book mentions that there are always project management issues relating to co-ordinating a development team that is diverse (technically and geopgrahically), and who have different visions for the software system, with careful management the benefits of a large dedicated software team can make a sizable impact on the quality and quantity of software being developed. The open source community is able to tackle software projects of size and scale that large corporations struggle to manage with the many resources they have available to them. The implication for usability, is that typically user centered design requires a significant amount of work. Processes such as Contextual Design require the efforts of a team of interviewers, modelers and people with other diverse sets of talents to effective create the right design for a software system. Since the open source community (including users) have this talent set, there is the unique possibility of leveraging the community's skills to solve these otherwise insurmountable usability tasks.

The argument that software should be "ported," to other platforms is one which I cannot fully accept, but which the OSV book makes. The concept of porting a software application, is essentially to convert the source code of an application that works in one operating system (platform), to work in another platform. The primary usability concern I have in this style of software development is that applications more often than not are blinded ported to other platforms without first understanding the interaction paradigms and guidelines of that particular platform. As a result of this, we see applications that are designed for point and click interaction being used on a touch screen device. Applications should only be ported to new platforms if they can support a design of experience and interaction that is compatible with that of the platform. This is one area where the free and open source community can learn from usability specialists.

Finally there were two predicitions that were made in the OSV introduction. The first one being that the stock market bubble created by the internet boom would bust and the second prediction that open source companies will command a larger prescence and market share of the stock market. As we all know former prediction turns out to be correct, as the stock market bubble bursted in 2000 (a couple of years after the writing of the book). However, the second predicition - that open source software companies will command a larger prescence of the technology investment market turns out to be a predicition that has come to pass. Looking at several prominent open source companies (such as GeekNet Inc. ticker symbol: LNUX), we can see that they are trading well below their IPO values. Meanwhile proprietary companies such as Apple are trading several orders of magnitude higher than their trading price at the time of publication of OSV.