|
|
The Open Group
Customer Council
Report of Meeting in Cannes
on Tuesday 15 October 2002, 10.30-12.30
Introduction & Welcome
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 managent 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 modelled 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 availoable 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 analyse the resulting data, for which they are moving towards using Beowolf.
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.
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 resuloting 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 writen 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 comunities 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 threshhold 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
exsting 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: Oya-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.
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 - 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 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 good 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, which is why there is continuing 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".
Walter noted that businesses 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 acroiss 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 this approach works by mapping it to
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) 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 agreed but noted that
The Open Group is now recognizing the value of academic membership to mitigate costs of
participation. Walter suggested we should address this and other barriers that arise as
challenges to be overcome rather than 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 with Walter and
The Open Group.
|
