The meeting was attended by about 65 people.
Carl Bunje, Chair of the Customer Council, welcomed all present and introduced the
theme of this meeting as complementing the Open Source theme of the conference plenary,
the subject being Customer issues in engaging with Open Source.
Carl explained (see presentation slides) the agenda for this
meeting:
- scene-setting
- panelist remarks
- panel questions & answers discussion
- potential for Open Group involvement
Then in a succession of slides he stimulated audience thinking by inviting them to
consider their answers to the following questions:
- Are you engaged? - do you use open source and how fare are you engaged with it?
- Potential benefits of using Open Source - are you realizing them?
- Perceived risks in using Open Source - are you mitigating these?
- Consideration of qualitative attributes - ability to customize,
availability/reliability, interoperability, scalability, design flexibility, lifetime,
performance, quality of service and support, security, ease of management, risk of
fragmentation, availability of applications
- Some criteria for evaluating open source engagements: lifecycle costs, benefits &
intangibles. Also, do indirect costs, operational/performance benefits, and intangibles
play a greater role in Open Source than COTS software?
- Project management issues, including requirements management, source & version
control, integration & testing, schedule management, and licensing & legal issues.
Panelist Presentations
3 panelists with differing experience of Open Source introduced their experiences with
it.
Ken Linker (DISA)
Ken explained he is the US DoD Common Operating Environment (COE) community process
coordinator. COE is a pilot project that is tightly focused on web-enabling the Common
Operating Picture (COP). This project represents a radical shift in how the DoD has built
joint software in the past, and one of its main goals is to see how well community
development works in a controlled environment. Their approach is centered on "expert
groups", which they have modeled on the Java community process. Having now
established a representative expert group from the services and agencies, they have now
demonstrated initial capabilities, in an application called WebCOP. Their goal is to
establish an open source process for development & maintenance of DoD joint software.
Licenses would be formal agreements between participants. Issues they have identified to
date include IPR, and the desire to maintain a consistent COE baseline over time (for
integration, tests, fixes and resources). Ken said it is too early to declare successes,
and it is requiring changes in the way they think about developing software both within
the community and with developers, and also in contract language and governance issues.
Dean Richardson (Boeing)
Dean noted that Boeing makes some interesting uses of open source. Linux is now widely
used, particularly in their wireless operations, and in their testing operations. Boeing
is also developing an LDAP proxy server as open source, this deriving from the recently
completed Secure Messaging Challenge. They also use Open LDAP, in which Linux was a test
bed.
Steve Jenkins (JPL)
Steve explained that the NASA Jet Propulsion Laboratory (JPL) operates on a federally
funded contract with Caltech, for scientific development projects that support unmanned
space flights. In their computing environment here is widespread use of Apache, Linux,
PERL, JTC, etc. Much of their work involves one-shot tools for individual scientific
analysis. Now that they can run "Office" on a Linux machine this has opened up
wider use of the Linux operating system. PERL was developed by Larry Wall in JPL before
Open Source became significant, and PERL is now a major tool in JPL. One barrier to making
a lot of their code scripts available as open source is their lawyers, who are concerned
that every 20-line script is both an asset and a liability, so to be safe they constrain
making it available as open source. Communicating with spacecraft is a major system
requirement that JPL has to deliver, and shadow telemetry requirements for
"quick-look" health checks on spacecraft are well suited to being developed on
open source tools. A recent satellite named GRACE measures the fluctuating gravitational
field of the Earth for global positioning systems, and much computational power is
required to analyze the resulting data, for which they are moving towards using Beowulf.
Another instance of their increasing use of open source is their use of new compilation
tools to solve application portability problems - the open source CVS tool for example
takes away a heap of problems that used to preclude compiling old applications on to new
open source systems. If you look on Sourceforge you and easily see that the infant
mortality rate for projects registered there is very high; however Steve considered this
is not a problem, because enough of the worthwhile projects on Sourceforge do thrive and
this should be seen as a natural part of the equivalent biological process of survival of
the fittest - that is in software terms the most capable.
Q & A Discussion
The 3 panel speakers were joined by 4 speakers from the Monday plenary - Jon
"Maddog" Hall, Mary Ann Fisher, Andrew Josey, Dirk-Willem van Gulik - to respond
to questions from the audience.
Question from Dock Allen: Typically we do some kind of audit when buying a product - how
do you expect to do this in an open source situation.
Dirk-Willem: open source is rarely what you actually deliver to a customer; much
integration and testing goes into the deliverables to a customer, so there is almost
always adequate supplier backup that the open source product is well supported.
Maddog: in a project he knows of in Brazil, an integration company took the responsibility
for putting together the open source solution for an academic institution and then put it
on Sourceforge. The resulting costs to the academic institution were far lower than a
commercial off-the-shelf (COTS) solution, who got a solution that did what they wanted
rather than a COTS solution that would have required tailoring to do, and moreover that
open source contribution to Sourceforge was then widely
adopted for minimal cost by other academic institutions.
Question from Terry Blevins: What is the panel's opinion on standards in open source?
Maddog: When Linus Torvalds started Linux he did it iteratively by checking what worked
and finding what was missing. This eventually resulted in the identification of a new
POSIX standard that removed much redundant items from the standard that existed for UNIX
at that time. This greatly simplified the UNIX standard, so the resulting Linux standard
is a vast improvement on the old UNIX standard. Further, the current LSB certification
process from The Open Group is helping to underwrite the resulting Linux products. Maddog
added that for Linux, the written standard, the LSB test suite, and sample implementation,
were all important constituents.
Andrew: Agreed with Maddog, and added that when The Open Group set out to unify the POSIX
and Linux standards, we removed as many barriers as possible to easy inclusion of the open
source community, including ensuring no-fee participation. The result was that the
participation was fully representative of the community and the industry.
Question from Dock Allen: Would the panel comment on how the open source communities
approach the design process so as to ensure their design is coherent?
Maddog: If the design uses an existing architecture, then this issue is a matter of
re-implementation and not design. If it is new it usually derives from a small interest
group of concerned individuals who have already put a lot of thought into it, so you find
that such open source processes evolve over time through successive version levels, to the
point where the design is taken up by a wider community of open source developers who in
turn find and fix inconsistencies, the result being a sound design and well-tested code.
Steve: Agreed with Maddog, and added that open source developers usually know very clearly
what problem(s) they want to solve and they produce sound code that does provide the
solution they want, though it might not be the solution that a customer might have
requested in the first place. Even so, the solution will be solid and will answer a clear
need that the developers have identified a significant community of users want to take up.
Supplementary question from Carl: So how do customers engage the Open Source community to
provide an Open Source solution to a requirement?
Steve: You don't! - by all means raise the requirement, but the open source developers
will only respond to it in terms that they believe provide best value.
Dirk-Willem: the question is not framed well. The Open Source community is not just one
entity - it embraces a very loose federation of like-minded developers who are not
answerable to anyone except themselves.
Maddog: Although the answers Steve and Dirk-Willem are true, there are areas of special
interest in the open source community where there is particular interest in developing
solutions - for example in the medical telemetry sphere. So searching for such pockets of
special interest can bear fruit.
Question: Most small enterprise customers who are not developers do not have the in-house
skills to qualify and/or install open source products, so what can these SMEs do to
safeguard their businesses?
Steve: In his job in JPL, he provides his in-house customers with services, not with raw
open source code. These services are already wrapped so as to be useful and do what is
wanted. The costs of developing and delivering these services compares very well with the
frustrations of COTS solutions where purchase costs are high, quality is not so good, and
tailoring is often needed. Steve said he uses tons of Open Source code that he has never
checked but which he sees by its results works well and does the required job.
Maddog: Knew of a small business that runs perfectly well using contract professionals to
install and integrate their software. Installation and integration tools are improving all
the time, as is the availability of skilled integrator and installation consultants.
Question: The mobile computing world is increasing rapidly and soon we can expect open
software to emerge from this sector - what are the likely scaling problems here?
Maddog: There is no clear answer to this, but he believes that the threshold to
accommodate innovation is very high.
Steve: Linux came through to its current great success partly because in a climate where
there was significant frustration among software engineers over the limitations of their
existing systems, they were suddenly able to put together their own computer hardware from
various component bits and all at a fairly low cost, so they could develop their own
software on
their own systems. This has not happened with mobile phones yet, and the vendor control of
these devices is likely to ensure that similar ability to build own mobile devices and so
experiment with writing own code for them is some time away.
Question from Carl to the audience: In terms of engaging the Open Source community, was it
difficult to find the right people to talk to?
This question did not get a direct answer before another question came from the audience.
Question: Narita-san: How do you separate proprietary IPR from open source where they
co-exist in the same software systems?
Mary Ann: This is a business judgement that each vendor has to make, and it is surprising
how easy that decision is once the vendor has decided to contribute to open source.
Maddog: Open Source has its greatest strength when it has lots of users, not when it has
few customers, so this problem is one that the major software vendors have to address to
their own satisfaction, and they have their own ways to package their software products to
provide the level of IPR protection they feel they need.
Dean: For the Secure Messaging Challenge (SMC), it was in Boeing's best interest to get as
many users as possible to adopt the SMC solution, and so Boeing saw the sense in making it
open source to achieve widest possible adoption.
Dirk-Willem: Observed that open source channels offer a quick release mechanism for
software fixes that get the fix out to the user community while reducing
accountability/responsibility for the fix if it is found to be inadequate. Typically a fix
released quickly in this way this can then be followed by a more controlled release of a
well-tested software fix.
Question: We have heard how licensing can be a problem in open source - is a lawyer needed
when getting involved with it?
Steve: emphatically NO - the value of open source is the ideal capitalist model - spend as
little as possible and get the greatest value back. The licensing is secondary. Remember
that open source includes the word "open", which is not too difficult even for
the legal system to understand.
Maddog: Suggested that if customers are worried about software licenses, they should take
time to read the standard Microsoft license, because that contains an awful lot that they
have even more reason to start worrying about.
Question: What are the good business reasons for releasing an in-house software upgrade as
open source?
Maddog: Releasing and contributing code as open source is a business decision for those
who have it. Open source is about contributing good value to enable better software
availability and choice to other software users. Sharing is good, though not every
business decision-maker would agree, and it is also true to say that not sharing is not
bad. This will continue to be a subject for verbal combat between the open source
community and the proprietary software vendors.
Dirk-Willem: Appreciate Maddog's view, though when the developer is a Government agency
the business decisions regarding open source become a little more complex.
Carl closed this part of the meeting by thanking the audience for their stimulating
questions and the panelists for their illuminating answers.
Open Source and Boundaryless Information Flow -
Identifying Synergies
Walter Stahlecker (HP) gave a presentation titled "Open
Source and Boundaryless Information Flow - an attempt to describe synergies".
Referring to Walter's diagrams in his slides, he noted that businesses have traditionally
created departmental silos to cut costs, but with the advent of more integrated business
methods the greatest value from cross-functional projects is in sharing information, and
this requires an architected approach to enable silos to share their information across
the enterprise.
Open source proliferates organically but not many can use it "raw". There is
broad interest to connect developers of Open Source with consumers of Open Source.
However, Open Source developers in general have different priorities to the majority of
business users, and experience of how to bring the two closer together is sparse.
A basic approach to harnessing respective interests could be:
- sharing best practice about specifications for Open Source and legal issues
- providing an infrastructure to capture resulting specifications and resolve legal issues
- making good use of the resulting materials, through connecting them in architectures,
running tests and interoperability-fests, and running customer demonstration projects.
Walter illustrated how his approach here worked for the Secure Messaging Challenge. He
suggested that The Open Group could take an initiative (perhaps starting at the next
conference (Burlingame, 3-7 Feb 2003) to facilitate this approach, by:
- starting a new Forum in which Open Source projects can share experiences, record best
practices and get guidance on legal issues,
- setting up an easy-to-use infrastructure to agree publish & license specs for Open
Source projects
- fitting Open Source specifications inside TOGAF, organizing interoperability-fests for
open source projects, and hosting projects that demonstrate open source in customer
projects.
Maddog commented that while this approach seems logical, most Open Source people do not
have the means to cover travel costs and meeting fees so would not be able to participate
in such an initiative. Mike Lambert appreciated this point, but noted that The Open Group
is now recognizing the value of academic membership to mitigate costs of participation and
this greatly eases the ability of the open source community from academic institutions to
become involved. Walter suggested we should consider this and other barriers that arise as
challenges to be overcome rather than as problems that diminish the
worthy objectives.
Carl thanked Walter for his insights how The Open Group might take this initiative on open
source, and undertook to follow it up.
