7th December 2005, EUROCONTROL-EEC, Bretigny-Sur-Orge, France
Migration to OSS
by Joseph Feller, University College Cork
Overview
Communities collaborating to build software is as old as software itself. It was the dominant paradigm in the early days of computing. Richard Stallman formalized the concept in the mid '80s as "Free Software". Stallman enumerated four freedoms for software:
- The freedom to run the software
- The freedom to study how it works, and adapt it to your needs
- The freedom to redistribute copies
- The freedom to improve the program, and distribute your improvements.
Stallman's approach is unabashedly ideological: his premise is that not only can software be free, but it should be free. Despite the linguistic ambiguities of the English word "free" which can imply both freedom as well as "no cost", Stallman choose to call his view on software "Free Software".
The business community, especially in the United States, was understandably nervous about these software freedoms and the term "Free Software". In the late '90s, the term "Open Source" software was coined on order to make the free software concept more palatable to business. This change in labeling seems to be quite successful, since we can observe widespread adoption of Open Source products and processes by industry.
Nonetheless, Richard Stallman's Free Software is actually the most useful definition for us, since the freedoms he has defined map quite nicely to EUROCONTROL's goals of harmonization, improvement of quality, public service, and creation of value.
There are numerous examples of successful Open Source products. Current OSS software available is quite mature, and is offered over a broad range of categories. Initial successes were mostly in server space, and some server software, like Apache or JBoss, are considered as "category killers" i.e. there are no significant competitors in their space, in terms of quality and popularity.
Interestingly, recent development has allowed OSS to make inroads onto the desktop. One often-heard criticism of the Open Source model is that it comes from developers, and is aimed at developers, and cannot be applied to end user needs in terms of usability or documentation for novice users. Now, however, there is a wide range of end-user oriented software available, capable of meeting most of the desktop-oriented needs of enterprises in place of proprietary software. Examples include the Firefox browser, the OpenOffice.Org office software suite, emails clients like Thunderbird, and the like.
Logically enough, the end user space where OSS really shines is developer tools. This is particularly useful for EUROCONTROL, because all the development software and the toolbox for building better software is there.
Open Source is defined by its terms of distribution, and that has several interesting implications. The actual development of software shifts from being a closed, proprietary effort that is released to a user group (which E. S. Raymond describes as "Cathedral-style" development) to an open community collaborating on the software. The other shift is that the source code, usually considered as the primary asset of a software firm, is now made into a commodity, and the software firm must define value using other things.
Firms can use this software to build better software in two ways. The first is that you can learn much, at both high and low levels, from the OSS out there. Stallman's "freedom to study" is essential to be able to learn from others' work.
Perhaps even more importantly, if the code wasn't there, the code asset of Open Source is still the community. This implies that by adopting Open Source, companies can access this community, and use it to further develop, document, debug and maintain their software.
One of the objections raised by critics of Open Source for EUROCONTROL is that as a very small group, would they gain value from this Open Source community? The answer is likely to be yes. In E. S. Raymond's words "given enough eyeballs, all bugs are shallow". Actually, in 2003 he amended that to say, "Given the right eyeballs, the most important bugs are shallow." What is important about the ATM community is not its size, but rather its expertise. You'd have the right eyeballs on the job. That may be enough in itself, to realize some of these advantages.
By shifting the software code from being a core protected asset to being a commodity, the software consumer is empowered. Vendor lock-in opportunities are mitigated. It significantly balances the power between the software producer and the software consumer.
Open Source changes the nature of software business models. To be an Open Source business, or to even be a hybrid proprietary/Open Source business, requires a fundamental shift from treating software as primarily a manufacturing/marketing activity to treating it as a service and knowledge-based activity, where the value of the software is in its use, not in its production.
Practically speaking, how does one adopt OSS? Some good practical insights can be found in the book Open Source for the Enterprise by Woods and Guliani (O'Reilly 2005). The core argument of the book is that using OSS means taking on the burden of overcoming the lack of productization.
The key value offer of the proprietary software industry is the package, bundling legal, support, and documentation services with software.
F. Gasperoni: There is nothing inherently proprietary about bundling support, documentation, and software into a package, and some open source offerings are full products as well. >Franco>
OSS "in the wild", particularly for specialized research and experimental software such as in the context of EUROCONTROL, has a steep learning curve associated with overcoming this lack of productization.
A few things need to be considered in determining if a particular piece of software is right for a particular problem at EUROCONTROL, and if the open source process is right for developing and supporting a particular software development project.
First off, you must understand the problem. Again to refer to E. S. Raymond, a key driver for open source development is "scratching their own itch": developers work better on projects to meet their own needs, and they share this development with others with similar needs. EUROCONTROL needs to be able to understand its own itches, it own needs. As J. L. Hardy said, "EUROCONTROL doesn't produce much software, but lots of requirements." This is good, because you need clear enough requirements to be able to leverage the community.
Another important thing to ascertain is the relative importance of the system. This importance can range from experimental, research efforts to mission critical systems. Another facet is understanding your tolerance to risk, and how can success be measured? Is it successful if the software is useful, or is a success only if you rally an international community around it?
Understanding yourself as an organization, especially your skill levels. A series of skills are involved in adopting and producing OSS, and the usual IT department know-how is not necessarily enough: one skill requirement is the ability to skilfully engage with the community. This is a corollary of the lack of productization: when your support and development comes from the community instead of a commercial entity, it is vital to be able to engage the strength of that community for your purposes.
The final challenge is to understand the product. Finding good open source is not too hard, but finding the right software and right community for your needs may prove quite difficult. This can be a hidden cost for OSS: the cost of evaluating the available projects. Although there is no licensing fee, it might cost you almost as much to come to the confident answer that that product is right for you.
Evaluating the maturity of the software is not simple. Many aspects must be considered: product age, quality, momentum and popularity; usage costs to set up and support end users; ease of integration, modularity, standards, developer support. In any case, the most vital aspect remains the community. If you are going to build OSS, you have taken on the burden of building that community. If you are going to adopt OSS, you've taken on the responsibility of participating in that community. You have to answer questions about that community: who are their leaders? What are their goals? Is the culture of the community open? Is it growing and dynamic? How much commitment is there?
When you're building OSS, the roles are reversed: you need the skill set that you were looking for in the community. Your software may not necessarily be release-ready, but it should have an architecture that will allow it to grow with outside contributors. The culture of your community should support participation.
Is open source right for EUROCONTROL? Maybe. You can use these criteria to see:
- Can you match the right product or process to the right problem? More packaged open source solutions like office software could be a good area to get started. You could gain experience in participating in the community.
- If the cost of ownership is tightly related to licensing costs and vendor lock-in, then there can be a cost savings with OSS.
- If you can increase the value of the software by enjoying the freedom to modify the software, open source is an advantage.
- If you can build value by creating and participating in community, open source has much to offer, even if the software is equivalent to the proprietary counterpart.
- If you have an institutional need to share your software with the stakeholders who pay for it, then open source could be very appropriate.
Discussion
from 27'20" to 31'27'' (4'07'' min)
R. Schreiner: Open software is a great way of reducing risks because it gives the user more freedom, for example to fix problems by himself, but also a lot of responsibility. On the other hand, it can lead to a quite ineffective use of software. For example, some companies tend to try to do everything by themselves without enough expertise to do so. So If you use it wisely, it's great, but otherwise, it can make you lose a lot of time. >Rudolf>
J. Feller: The quality and the management of risk improve with open source when there is the adequate know-how internally. You have to have the three pieces of the puzzle: the software itself, the licensing terms that gives you the freedom to improve it and engage with it, and the know-how. And if you don't know how, you can get involved with the community, because even if you can not fix the problem, you may be fully able to clearly articulate what you need fixed and chances are you are not the only one. >Jo>
R. Schreiner: The problem with commercial software is that you must rely exclusively on the vendor for support and maintenance of the software, especially when the market is very small. If the vendor decides to discontinue the product, that's it! With an open source solution, if you're not satisfied with support, you can switch to another source of support. If you find a bug, that's important to you, you fix it yourself. You set your maintenance priorities, not the vendor. >Rudolf>
P. Johnson: What about EUROCONTROL releasing software and continuing to work with the community, instead of finishing the project and going on to something else? >Paul>
S. Swierstra: This is an excellent idea... >Sip>
Salient points
- Richard Stallman defined four freedoms for software: freedom to run, study, redistribute, and improve software.
- Open source is a term coined to reassure business, which may be worried by the definition in terms of freedom
- OSS has made wide inroads in server infrastructure, and more recently in desktop software as well
- OSS moves software from being a core protected asset to being a commodity, empowering the software consumer
- "Given the right eyeballs, the most important bugs are shallow."
- The key value offer of the proprietary software industry is the package, bundling legal, support, and documentation services with software. However, some open source offerings are full products as well.
- There can be a hidden cost for OSS: the cost of evaluating the available projects.
- If you are going to build OSS, you have taken on the burden of building that community. If you are going to adopt OSS, you've taken on the responsibility of participating in that community.
- If you have an institutional need to share your software with the stakeholders who pay for it, then open source could be very appropriate.
"The concept behind
open source is simple:
it's communities sharing code
to make software better.
It's as simple as that.
Access to the source code
is a precondition."
|
 |
 |
 |
| book | slides | MP3 | OGG |
