dkeats.com

For me, as an individual user of FOSS desktop systems, the answer is definitely "yes" and most emphatically so. I use an operating system that is without cost to me, I use office software (word processor, database, vector drawing, presentation, spreadsheet) that is definitely without cost. I use an awesome graphics application called 'the GIMP' that is without cost. I watch videos and listen to music using applications that are without cost to me. I browse the web on software that is without cost to me. I create animations and videos using a variety of software tools that are without cost to me. I manage my extensive photo collection using software that is without cost to me.  I do software development as a hobby, and all the tools I use for development are without cost to me. My daughter uses the same system, and plays games that are without cost to her, and also does her school work with software that has no cost. Indeed, there is almost nothing that I can think of that I need to do for fun or work that would require me to pay a software license fee. So, yes, for me as an individual, FOSS is certainly without cost. Indeed, I once make a mapping of the software I use against proprietary packages, and I have in excess of R300 000 worth of software (based on full commercial prices) on my computer, for free.

Layers in a FOSS
ecosystem.

If we look at the diagram left, we can see a stack of different ways of using or working with FOSS. While actual costs are case specific, there would be a reasonable expectation of increasing costs as one moves higher in these layers.

Thus, the reason the cost to my daughter and I is zero is that we are able to use existing software, as is, in the form in which it is supplied. This is the most trivial way in which software is deployed, although it is an important one. Most real problems in large organizations cannot be solved using simple deployment of software as is, with no customization. This applies to both FOSS and proprietary software.

In a typical, large software project, licenses are an important and recurring cost, but do not generally consititute more than 25% of a typical project implementation, often less. Thus, the cost of implementation of large systems will be similar for both proprietary and FOSS systems, unless one area requires more customized code to be written than the other. This cannot be addressed in the abstract, however, the desire of the ignorant notwithstanding.

A very important cost impact of proprietary licenses lies in vendor lock-in and consequent exit costs. Exit cost for proprietary software can be so significant that organizations may be reluctant to exit even when there are compelling reasons to do so. The cost of Wits exiting the Oracle Student System, a typical proprietary, tightly coupled system are likely to be double digits, without even including the costs of implementing the alternative solution. Let me say that again, because it is so often overlooked: the exit costs are huge, and the time pressure adds additional costs and constrains our choices severely.

There will be times when a FOSS solution to a given problem will be more expensive than a proprietary solution when taken from the perspective of a particular project. However, measured in terms of contribution to building a broader ecosystem, such extra costs may be justified; or they may not be. Decisions in this case will require a full examination of the costs and benefits, both long and short term, and an application of wise minds - just as you have to do with any software project whether based on FOSS or proprietary software.

When an organization is undergoing change from predominantly proprietary to substantially FOSS (for example), there will be a typical change or pain curve. It may cost more in the short term to implement FOSS than to go with the 'standard' proprietary solutions. Sometimes - due to lack of understanding of the nature of pain curves - organizations change back to the old way before they have emerged from the pain curve, and never realised the long term value of building a FOSS ecosystem.

When you measure the total cost over the life of a system, in general FOSS should come out cheaper, but there is no general guarantee that this will be true in the abstract. Most costs in a software project are part of implementation, and it is possible to have very expensive implementations of either a FOSS or a proprietary technology. The cost impact will be determined by the degree to which you have created or have access to an ecosystem of support. This ecosystem will consist of:

• internal skills
• companies providing support
• local and global communities.

Over time, with adequate support, FOSS will reduce costs for most areas. However, there will be some for which it will not. Therefore, it is vital to evaluate each case on merit and to do so skillfully and with knowledge and understanding of all the nuances. In this respect, FOSS is no different from any other technology acquisition. It is certainly not costless. And how much it reduces costs will be highly dependent on what you do with it. You might, for example, discover that you can innovate more with FOSS and achive higher value, and therefore your costs may increase along with value.

Indeed, the notion of cost in the abstract is not really very useful. There are a number of business models for FOSS in an organization, and they are all different, with different cost impacts, and the costs vary with the nature of the project, the availability of in-house skills, the degree to which the principles are understood and embraced, and the availability of external resources that can be called on when needed.

The same range of business models is true for proprietary software, so the only way to compare costs is to have exactly identical projects under exactly identical conditions. In such a situation, FOSS should be somewhat to significantly less costly because it lacks the license fee. However, such a situation is almost impossible to imagine creating in reality, so discussions of costs in the abstract are really a distraction. Until you have an actual project, and its implementation ecosystem, cost is not something that you can meaningfully consider.

I have always maintained that any savings from implementing FOSS are collateral benefit, the metaphorical cherry on the cake. Likewise, the Joint Information Systems Committee (JISC) of the UK concluded that the real value of FOSS arise out of the options and flexibility that it brings. They conclude:

In fact, the real value of OSS is that it makes it possible for you to exercise control over how you run your institution's IT department by allowing you to choose a model from on any point on the spectrum that runs from fully self-supporting to fully outsourced. In turn, this allows institutions to choose the extent to which they want, and are able to, take advantage of the strategic organisational  gains that accrue from the use of open data standards and open source software.

http://www.oss-watch.ac.uk/resources/procurement-infopack.xml#ixzz0r0KMuovv
Under Creative Commons License: Attribution Share Alike

My main point here is that whether FOSS is without cost or not depends very much on particular cases. Cost is one side of the cost-benefit equation. Value arises when benefits are greater than costs. Whether this is true for any given software project is not a function of FOSS versus proprietary, but how well you execute the project, and how long you can sustain the benefits. The question of cost is meaningless in the abstract, though very important nevertheless.

Fundamental to good FOSS projects and academic work is the concept of peer review, others with similar interests and backgrounds taking a look at your work and helping to improve it.  Both FOSS and academic work are quality-assured by peer review, sometimes formally and sometimes informally.

Both academics and FOSS practioners share knowledge through collaboration in communities of practice. In these communities, the participants are allocated merit based on their contribution of outputs and their work in the community. A researcher who writes lots of papers in good journals, or a developer who writes lots of really good source code will both be highly respected. They will be respected even more if they take part in the formal and informal activities of their communities.

FOSS developers share software source code through repositories and ideas through mailing lists, while academics share actual lab protocols and other knowdedge through exchange visits, sabbaticals and increasingly to online communities that are not unlike those of FOSS developers.

FOSS developres collaborate through joint contributions to source code, while academics collaborate through joint research and publication. While the details are different, the principles are quite similar in both. I know this because I have been an active and highly collaborative researcher who has published over 80 publications, and I have been an active developer who has contributed source code to FOSS projects. I see no obvious difference between the two kinds of collaboration, other than the objects around which the collaboration happens.

Both academic work and FOSS development thrive on open communication among peers. To me, who works in both, there is little difference between sending an email to Bill Woelkerling in Australia and asking if he thinks my coralline algal specimen is Hydrolithon nased on the coceptacle photograph, and sending an email to a developer list asking if anyone can think of a way to use jQuery to manipulate embedded Flickr images after the page has loaded. The principle of open sharing is common to both.

Coralline algal conceptacle of Hydrolithon	Snippet of code to process a Flickr image after the page loads

Both academics and FOSS developers building on the work of others made publicly available. For developers, this may include the actual source code, whereas with academics such editing would be called plagiarism, although in the world of Free and Open Educational Resources, editing content can also be done for academic purposes.

Both FOSS practioners and academics engage in the mentoring of novices. For academics, this includes the supervision of graduate students and assisting junior colleagues. For developers, a wider variety of mentoring options are available.

Finally, both developers and academics claim freedom, for developers it is software freedom, while for academics it is academic freedom. Software freedom involves the freedom of software users (including other developers) to access the software and do things with it, excercising their freedom of choice within certain constraints. Academic freedom has many definitions, one of them being the freedom of inquiry. Also linked to academic freedom is the idea of being free to teach or communicate ideas or facts without being targeted for repression, job loss, or imprisonment. Software freedom advocates are often academics, and use academic freedom to speak about software. The chief difference is that software freedom can be protected by licenses, while academic freedom and its bounds are contested areas.

In another post, I will look at the implications of software freedom in more detail using a graphic example of the difference between free and proprietary software.

I was recently queried about FOSS and innovation.  The question was:

However, before we get to why the answer is 'no', let us look at these questions that, on the surface, appear to be related even though they are independent. This type of question is one of a class of fallacies known as 'fallacies of distraction' and it is an instance of the 'complex question fallacy'. This type of question is seldom asked out of ignorance, it is almost always use by someone with malicious intent. There are two parts to the question, with the implicit idea being that if the answer to the second question is 'no' then the conclusion should be that FOSS does not foster innovation. FOSS activists should be aware of this type of fallacy, as it is a common ploy that is often used along with the red herring and the straw man fallacies when the person using it wishes to discredit FOSS before a naive audience.

Innovation is subject to suvivorship bias (you don't see the graveyard of failed innovations, only the successful ones that survive and still exist), and 'luck' plays a strong role. Furthermore, innovation is likely to be scale dependent, with an inverse probability of success as one goes up in scale. In addition, innovation is not static, and it is subject to the fact that the past is not a good predictor of the future (something that is axiomatic since something predictable is unlikely to be innovation - See 'The Black Swan' by Nassim Nicholas Taleb). For these reasons, but especially the suvivorship bias, it is almost impossible to make meaningful studies of innovation or draw meaningful conclusions.

To my knowledge nobody has ever claimed anything about FOSS being 'most innovative'. Indeed, innovative is perhaps not so much a characteristic of software, but rather of people and perhaps to some extent organisations. There are, however, certain barriers to innovation that FOSS reduces or eliminates, and this allows people to innovate. There are other barriers that affect innovation, such as access to capital for example, that are not impacted directly by FOSS. Most of these barriers are self-evident and obvious, rather like the statement that an open door is easier to pass through than a closed door. Some of the barriers inherent in proprietary software that FOSS lowers or eliminates include:

Availability of starting points Access to knowledge Software Permissions Software and other initial and ongoing costs

One of the great things about working in a FOSS ecosystem is that one seldom has to start from scratch. there is a wide variety of software available in different layers from the operating system, programming languages and tools, web server, database, components and full applications. These can be used without any requirement to do anything in particular, including ask for permissions because those permissions are explicitly given in the license. For example, when we started Chisimba as part of the African Virtual Open Initiatives and Resources (AVOIR) project, we built it on the GNU/Linux operating systen, the Apache web server, the PHP programming language, as well as a large number of other building blocks that went into it.

Access to knowledge is a key component of how FOSS lowers the barriers to innovation. When you have an idea, limited coding experience, and few resources, how do you learn to code it? Excellent software is available to study, and if in studying it you use it for something, that is OK, because the freedoms of Free Sofware mean you are free to study, adapt, modify and distribute. Free Software as a learning resource not just because its source is available, but because often the source has been designed or developed by some of the best programmers in the world. Aside from the source code, the community associated with most FOSS projects is itself a learning resource, especially for those willing to jump on the mailing list and ask informed questions.

Software and other initial and ongoing costs are reduced by using FOSS. There are a number of cost areas that are impacted by FOSS including:

• Start-up costs;
• Scaling out costs;
• Lock-in costs;
• Maleability costs;
• Abandonment costs;
• Uncertainty of costs.

With FOSS, you can just grab the building blocks and development environment you need, and get started. Whether you have one developer or many, the cost of these building blocks is the same: nil. When you want to scale out, you do not have to worry about purchasing additional licenses, you just do it. There are no lock-in costs, and where there are alternative technologies to use, it is usually pretty simple to change. There are no proprietary lock-in mechanisms in FOSS. One of the costs that is often overlooked is what I call maleability costs. When you are starting something, you often want to try out different application stacks and ways of doing something. ... Then there is the uncertainty of what you will need if your application needs to scale, and predicting future costs for complicated, proprietary licenses is almost impossible.

	Many of the most innovative and valuable companies today got started by building on this stack of existing FOSS applications, including Google, Facebook, Twitter, and others. Google was founded by Larry Page and Sergey Brin while they were students at Stanford University. They maxed out their credit cards to buy hardware, and would certainly not have been able to have gotten the company off the ground if they needed to worry about software license fees and the general uncertainty of proprietary license mindfields. Google became a private company on September 4, 1998, and Larry & Sergey made #5 on Forbes list in 1997 with a net worth of $18.5 billion each.
	Another Ingernet success story is Facebook launched by Mark Zuckerberg from his Harvard University dorm room on February 4, 2004. Facebook was built entirely on a FOSS application stack, mainly because the lack of barriers allowed Zuckerberg and his friends to just experiment. After he built a global company on a FOSS platform, Time magazine named Zuckerberg as one of The World's Most Influential People of 2008, with Facebook being ascribed a Market value of $15 billion in 2007. Faceook continues to contribute to FOSS, and has recently also published open hardware specifications for its data centre hardware.
	Closer to home in South Africa, when Mark Shuttleworth started Thawte in the 1990s, originally run from his parents' garage in Durbanville. He built the applications on a stack of existing FOSS applications, with the secure server being an adaptation of the Apache web server server. Before being sold, Thawte captured 50% of the world's digital certificate market, with VeriSign having the other half. In 1999 VeriSign acquired Thawte in a stock purchase from Shuttleworth for US$575 million.

Lowing the barriers to innovation is the basis for Dr Sibusisu Sibisi's discussion on FOSS (as FLOSS) and national innovation systems in the NACI document. It is well worth a read. On page 7, the point is made that by expanding the scope for local innovation, an open source development environment allows local enterprises both to germinate, and to move up the international ICT knowledge value chain. This is only possible because the barriers are lower.

Vint Cerf, one of the co-creators of TCP/IP that powers the Internet, gave a recorded video at the Digital Freedom Expo in Cape Town a few years ago, and he pointed out how the importance of keeping TCP/IP free had led to the innovations that we now collectively know as the Internet. "Keeping important things Free and Open has been vital to the development of the Internet, and is likely to be an valuable contributor to development in Africa because when core things are Free and Open there are no barriers to innovation." We can look at this effect in the chain of things that led to the creation of Google, and its expansion as a global company.

The Austrian-American economist Joseph Schumpeter is responsible for many of the ways we think about innovation. Schumpeter postulated innovation as a critical dimension of economic change, and argued that innovation was substantially if not exclusively the purvey of the firm. He argued that temporary monopolies were necessary to provide the incentive necessary for firms to develop new products and processes. More recently, Eric von Hippel -- is a professor at the MIT Sloan School of Management specializing in the nature and economics of distributed and open innovation -- has provided an alternative view of innovation. von Hippel developed the concept of user innovation – that end-users, rather than manufacturers, are responsible for a large amount of new innovation. In von Hippel's view, individuals, firms (where software is not their main product) and organisations can all be 'user innovators'. By virtue of the lower barriers, in software space, FOSS is a major contributer to user innovation and this is the subject of a body of empirical research by von Hippel and his students. Schumpeterian innovation.

One of the consequences is that nearly all of the innovative IT-based companies of the last 10 years have been built on FOSS. The small few that have not were created by companies which already had a large investment in proprietary technology (so could eliminate their own barriers), or were funded by them. A relatively few do not fit into these categories. However, these results are also obviously subject to survivorship bias, so other than observation, one really cannot draw 'because' conclusions from them.

This was originally posted for Software Freedom Day last year!

Click image for larger version.

Given the renewing interest in reviving the South African FOSS policy, and the likely resistance to doing so, it is worth bearing these differences in mind. This is particularly true given our desire to create more innovation and more opportunities for the SMME sector in our country.

In a project that I did recently for a client, we got a group of researchers together. We asked the question 'Why use FOSS in research projects'. The group came up with the following answers:

• reducing the barriers to innovation
• reducing costs
• improving speed and agility of delivery
• increased quality
• improving security
• avoiding vendor lock-in or lock-in to vendor tools
• greater sustainability
• ability to learn from the source code and acquire knowledge
• more freedom arising from licences
• access to community of developers and users for support
• better alignment to the research culture
• create collaboration among researchers in the same area
• better for provision of social benefits
• use of FOSS source code internally, with no distribution, imposes no requirement to release modifications
• access to FOSS business models

I just read a facebook post by David Coltart, who is Minister of Education and Sport for Zimbabwe. I have enormous respect of David, for his MDC party, and for the awesome work that he has done for Human Rights in his country. Also, having taught Computer Science and Biology in Zimbabwe in the 1980s at one of the very few schools that had computers, and - more recently -  seen the decimation of education in Zimbabwe under the Mugabe dictatorship, I know that rebuilding the once-great education system is no easy task.  However, one of the statements made my Minister Coltart scares the living daylights out of me as someone who loves Zimbabwe, and understands the awesome potential of that country once the shackles of Mugabism are finally gone.

Coltart said

I will also be participating in the Ministerial Plenary session on Wednesday the 30th and from there will go on to the Apple Education Leadership Summit. I have been working very closely with Apple in the last few years and as I write this we are in the process of procuring a huge consignment of Apple computers for the rehabilitation of the Education Training Centre and the Curriculum Development Unit in Mount Pleasant. 

Davd Coltart, Minister of Education and Sport, Zimbabwe

Nooooooooooooooooooooooooooooooooooooooooo!

Please, not again. Don't give away the intellectual freedom of young people to a Foreign power. Because that is what Apple is, a Foreign Power. And their technology colonizes the mind. Are there no lessons in the past at all? The mind in the knowledge economy is at least as important as land in the agro-mining economy and it is where the new colonization is happening.

While the efforts to bring technology back into education in Zimbabwe are laudable, the things that the Minister is doing with Apple could be done with a lot more respect for the political implications of technology if he followed a Free and Open Source Software approach. Technology is the new colonialism, and Apple sells mental prisons built to feel sweet so that they infect the mind as quickly as possible. But a prison is a prison no matter how brightly the walls are painted.

Also, companies that sell such mental prisons based on secret software are much like drug dealers who create low cost opportunities to get you hooked early in the game. Microsoft also knows this very well, having infected millions of minds in schools around the world. Such technology pushers then recover their investment in your addiction later. Furthermore, Zimbabwe has so many smart and talented kids, you should be encouraging a maker culture, something that a Free and Open Source Software makes much more feasible than Apple's walled garden in a brightly painted mental prison.

It saddens me to see smart and educated people behaving as if there was no alternative. There are alternatives. Ones that can build INDEPENDENCE in Zimbabwe, instead of giving into the DEPENDENCE that companies such as Microsoft and foreign powers such as Apple would like to see. That alternative is Free and Open Source Software, as well as emerging Free and Open Source Hardware and other things that can help replace the DEPENDENCE and scarcity mentality with an INDEPENDENCE and abundance mentality.

Wake up David Coltart, before you give away Zimbabwe all over again.