Oss healthcare

Open Source Software:
Myths, Reality
and Medical IT
Carlo Daffara
European Working Group on Libre Software
Conecta Research

● What is OSS, and why do we care
● A small historical introduction
● Three axis of discussion:
● Control

● Collaboration

● Business models

● Licensing and IPR in Open Source software
● Sustainability and business models
● R&D advantages of collaborative development
● Some data on software quality
● Adoption of OSS in medical IT: Three classes of projects
● Two examples: VistA and DOSSIA
● Introducing OSS: software selection
● Best practices for OSS

OSS: myths, reality and medical IT

● The strict definition: OSS is software that is
covered by a license formally accepted by the
Open Source Initiative (or recognized as a free
license by the Free Software Foundation)
● It does not imply anything more in terms of
collaborative models, distribution, participation
● Many reasons for people participation in OSS:

● Demonstrating ability

● “Scratch an Itch”

● Dissemination of research result/Open Science

● Legal reasons

● Economic reasons


● The notional value of Europe’s investment in FLOSS software
today is Euro 22 billion (36 billion in the US) representing 20.5%
of total software investment (20% in the US).
● Similar measures are predicted by independent consulting group
like Gartner: in [Gar 06] it is predicted that two years from now,
around 25% of the total software market will be FLOSS-based
(either through external providers, or by internal developments)


Due to the complexity and cost of development
(and the relatively limited power of those first
computers), to the business models of the
manufacturers (based on selling hardware), and to
other factors, users freely shared source code and
advice, in a collaborative way that led to the
creation of user groups like SHARE (Society to Help
Avoid Redundant Efforts, founded in 1955 and
centered on IBM systems) and DECUS (for Digital
Equipment computers and later for HP systems),
both still alive. Code was also commonly shared in
academic journals, like the famous "Algorithms"
column of the "Communications of the ACM"
journal.


Building on a tradition laid by academic
institutions like MIT, Richard Stallman founded in
1983 the Free Software Foundation (FSF) to find a
way to preserve the freedom of users to study,
understand and modify software, in direct link with
the hacker culture of openness and sharing of
information. The objective of the FSF was to create
a complete reimplementation of the Unix
operating system, at that time an important
reference for most large companies and research
centers.


While FLOSS as a definition covers exclusively the
licensing regime, by extension the “openness” of
the code introduced the possibility of sharing
development efforts among different groups, in a
way similar to those of the early user groups of the
sixties. In this sense, Eric Raymond introduced in
his seminal paper “The cathedral and the bazaar”
the concept of shared development, contrasting
this “bazaar” style where every developer is free
to choose on what part of the code to work, in
contrast to the “cathedral” or formalized
development approach that is rigid and structured.


● While the concept took hold quickly, the reality is
that collaboratively developed projects tend to be
executed in a continuum between cathedral and
bazaar; for example, for most projects there is a
formal structure (with many sub-projects, more
open to external contributions) while other are
strictly formal (for example, projects that use
FLOSS code in a certified environment, such as
avionics or safety-critical systems).
● The conclusion: licensing mode and development

model are orthogonal aspects, and folklore may be
wrong


● There are three proper axis: control (software
model), collaboration (development model),
revenue (business model).
● The software model axis is the one that is
discussed most often. On the one hand there is
proprietary software, for which the vendor retains
full control over the software and the user receives
limited usage permission through a license, which
is granted according to certain conditions. On the
other hand there is Free Software, which provides
the user with control over their software through
an ex-ante grant of irrevocable and universal
rights to use, study, modify and distribute the
software.


● The development model axis describes the barrier
to collaboration, ranging from projects that are
developed by a single person or vendor to projects
that allow extensive global collaboration. This is
independent from the software model. There is
proprietary software that allows for far-reaching
collaboration, e.g. SAP with it’s partnership
program, and Free Software projects that are
developed by a single person or company with
little or no outside input.


● ...but licensing affects participation and the possible
coordination organization form:


● The business model axis describes what kind of
revenue model was chosen for the software.
Options on this axis include training, services,
integration, custom development, subscription
models, “Commercial Off The Shelf” (COTS),
“Software as a Service” (SaaS) and more.


● Intellectual property (IP) are legal property rights
over creations of the mind, both artistic and
commercial, and the corresponding fields of law.
Under intellectual property law, owners are
granted certain exclusive rights to a variety of
intangible assets, such as musical, literary, and
artistic works; ideas, discoveries and inventions;
and words, phrases, symbols, and designs.
Common types of intellectual property include
copyrights, trademarks, patents, industrial design
rights and trade secrets.
● The majority of intellectual property rights
provide creators of original works economic
incentive to develop and share ideas through a
form of temporary monopoly.


● Open source software: software that is distributed
under a license that comply with the OSD
definition:

● Derived Works: The license must allow
modifications and derived works, and must allow
them to be distributed under the same terms as
the license of the original software.
● Integrity of The Author's Source Code

● No Discrimination Against Persons or Groups

● No Discrimination Against Fields of Endeavour

● Distribution of License

● License Must Not Be Specific to a Product

● License Must Not Restrict Other Software

● License Must Be Technology-Neutral


● Free software has a similar definition, and in fact
OSS and FS may be considered as legally similar
(but with different ethical backgrounds)
● It may seem that OSS and IPR are mutually
exclusive, as usually IPR is “protective” and is a
barrier against external leverage of an
intellectual resource
● The opposite is true: licenses are grounded in

copyright, and are strongly enforced
● There are 4 main area of interest in the research

community related to OSS and IPR: Legal basis
for OSS IPR (licensing), Business basis of OSS IPR
(business models and competition barriers),
External IPR in OSS (compliance), Patents,
standards and OSS


● There are more than 50 licenses identified as
"open source" or "free software"; those can be
classified in a very simple way as:
● "provide credit": use, modification,
redistribution are allowed, but credit to the
original author is due, if redistributed. Examples:
BSD license, Apache License v2.
● "provide fixes": use, modification,
redistribution are allowed, but source code for
any changes must be provided to the original
author, if redistributed. Examples: MPL
● "provide all": use, modification, redistribution

are allowed, but source code of any derived
product must be provided, if redistributed.
Example: GPL.


● OSS licenses have been enforced several times,
in the USA and in Germany, and several
commercial companies settled OSS licensing
issues out-of-court...
● … this means that licenses should be considered

valid for all purposes
● Different kind of licenses apply to different kind of

digital artifacts – for example, Creative Commons
licenses are used for documentation, images,
non-code contributions
● Very similar to the classification presented: do as

you like, share-alike, etc.
● Warning: CC does have a “non-commercial”
license (unlike the OSS definition)


● Exactly as it is important for companies that sell
systems (packages, devices, …) that contain code
to be sure that OSS is properly included, OSS
projects must check that code is properly vetted
(compliance process)


IPR issues in open source software

● When external collaboration takes place, it may be
not only in the form of source code: “In the year
2000, fifty outside contributors to Open Cascade
provided various kinds of assistance: transferring
software to other systems (IRIX 64 bits, Alpha
OSF), correcting defects (memory leaks…) and
translating the tutorial into Spanish, etc. Currently,
there are seventy active contributors and the
objective is to reach one hundred. These outside
contributions are significant. Open Cascade
estimates that they represent about 20 % of the
value of the software.”
● An example of non-code contributions in a large

project:


● Is OSS monetizable? Sustainable? Economic theory tells us that in a
commodity market, in absence of strong exclusionary protection the
price lowers to reach the marginal cost of production
● But is software a commodity?


Non solo software: modelli partecipativi di sviluppo QuiFree, 26/10/2007

● What approach is used to allow for monetization of OSS?
● This was answered in the FLOSSMETRICS project, through an
analysis of more than 210 companies
● The list was collected from public data, using participation in
OSS forums, website contents and EDGAR data
● This list was further refined by eliminating companies that were
not really adopting FLOSS, even using a very relaxed definition.
In the specific: any company that allowed source code access
only to non-commercial users, or that did not allowed for
redistribution was dropped from the list; also, companies for
which no information was available, or for which no clear
product or service was identifiable was equally eliminated
● Companies that have a significant OSS contribution, but for
which FLOSS is not the core business model were not included
(this for example includes IBM, HP and Sun; all of which are
important FLOSS contributors, but for which open source
software is just one of the overall revenue streams)


Main Licensing model Main revenue generation
OSS and multiple
Company dual licensing commercial Badgew are Pure OSS packages selection ITSC Subscription licens ing
versions covered

Funambol l l l

dual lic .
Lustre l l
MuleSource l l l l
Mysql l l l
OpenClovis l l
Pentaho l l l
sleepycatdb l l
A daptiv e Planning l l
A lterpoint l l l
A ltinity l l l
Codew eaver (WINE) l l
Coupa l l
Digium (A sterisk) l l

Split OSS/commercial releases
Enormalism l l
EnterpriseDB l l
GreenPlum l l
GroundWork l l
Hy peric l l
Jas perSof t l l
Know ledgeTree l l
OpenCountry l l
Open-Xchange l
NoMachine NX l l
rPath l l
Sc alix l l
Sendmail l l
Smoothw all l l
Sourcef ire (SNORT) l l
Splunk l l
SSLExplorer l l
SugarCRM l l l
TenderSystem l l l
V irtualBox l l
V yatta l l l
XenSource (Xen) l l
Zend (PHP) l l
ZIMBRA l l l
1bizcom l l
Badgew are

CA TS applicant tracking l l
EmuSof tw are/Netdirector l l l
Jbilling l l
OpenBravo l l
OpenEMM l l
OpenTerracotta l l
SocialText l l
A lf resc o l l l
Babel l l
CentraV iew l l
CleverSaf e l l
product specialists

Compiere l l l
Ex adel l l
Jitterbit l l l
Mergere l l
Mindquarry l l
Mirth l l
Of BIZ l l
Qlusters (OpenQRM) l l
Sy mbiot/OpenSIMS l l
Talend l l
UltimateEMR l l
V ISTA l l
vTiger l l
Zenoss l l
platf . Provid.

Jboss l l l l
RedHat linux l l l
Sourcelabs l l l l
SpikeSource l l l l
SUSE Linux l l l
WSO2 l l l
s elec tion –
consulting

ay amon l l l
Enomaly l l l
navica l l
openlogic l l
Optaros l l l
x-tend l l l
CiviCRM l
Other

Ec lipse l
Mozilla l
OSA F Chandler l
Sourcef orge
Open-source based business models OpenTTT 1st review

● Dual licensing: the same software code distributed under the
GPL and a commercial license. This model is mainly used by
producers of developer-oriented tools and software, and works
thanks to the strong coupling clause of the GPL, that requires
derivative works or software directly linked to be covered under
the same license. Companies not willing to release their own
software under the GPL can buy a commercial license that is in a
sense an exception to the binding clause; by those that value
the “free as in speech” idea of free/libre software this is seen as
a good compromise between helping those that abide to the GPL
and receive the software for free (and make their software
available as FLOSS) and benefiting through the commercial
license for those that want to maintain the code proprietary. The
downside of dual licensing is that external contributors must
accept the same licensing regime, and this has been shown to
reduce the volume of external contributions (that becomes
mainly limited to bug fixes and small additions).


● Open Core: this model distinguish between a basic FLOSS
software and a commercial version, based on the libre one but
with the addition of proprietary plugins. Most companies adopt
as license the Mozilla Public License, as it allows explicitly this
form of intermixing, and allows for much greater participation
from external contributions, as no acceptance of double
licensing is required. The model has the intrinsic downside that
the FLOSS product must be valuable to be attractive for the
users, but must also be not complete enough to prevent
competition with the commercial one. This balance is difficult to
achieve and maintain over time; also, if the software is of large
interest, developers may try to complete the missing
functionality in a purely open source way, thus reducing the
attractiveness of the commercial version.


● Product specialists: companies that created, or maintain a
specific software project, and use a pure FLOSS license to
distribute it. The main revenues are provided from services like
training and consulting (the “ITSC” class) and follow the original
“best code here” and “best knowledge here” of the original
EUWG classification. It leverages the assumption, commonly
held, that the most knowledgeable experts on a software are
those that have developed it, and this way can provide services
with a limited marketing effort, by leveraging the free
redistribution of the code. The downside of the model is that
there is a limited barrier of entry for potential competitors, as
the only investment that is needed is in the acquisition of
specific skills and expertise on the software itself.


● Platform providers: companies that provide selection,
support, integration and services on a set of projects,
collectively forming a tested and verified platform. In this sense,
even linux distributions were classified as platforms; the
interesting observation is that those distributions are licensed
for a significant part under pure FLOSS licenses to maximize
external contributions, and leverage copyright protection to
prevent outright copying but not “cloning” (the removal of
copyrighted material like logos and trademark to create a new
product). The main value proposition comes in the form of
guaranteed quality, stability and reliability, and the certainty of
support for business critical applications.


● Selection/consulting companies: companies in this class are
not strictly developers, but provide consulting and
selection/evaluation services on a wide range of project, in a
way that is close to the analyst role. These companies tend to
have very limited impact on the FLOSS communities, as the
evaluation results and the evaluation process are usually a
proprietary asset.
● Aggregate support providers: companies that provide a one-
stop support on several separate Free Software products, usually
by directly employing developers or forwarding support requests
to second-stage product specialists.
● Legal certification and consulting: these companies do not
provide any specific code activity, but provide support in
checking license compliance, sometimes also providing
coverage and insurance for legal attacks; some companies
employ tools for verify that code is not improperly reused across
company boundaries or in an improper way.


● Training and documentation: companies that offer courses,
on-line and physical training, additional documentation or
manuals. This is usually offered as part of a support contract,
but recently several large scale training center networks started
offering Free Software-specific courses.
● R&D cost sharing: A company or organization may need a new
or improved version of a software package, and fund some
consultant or software manufacturer to do the work. Later on,
the resulting software is redistributed as open source to take
advantage of the large pool of skilled developers who can debug
and improve it.


OSS Vendor Vendor Number of Sale condition Freeriding protection
Business model example covered
products
Dual licensing MySQL single or few integration of the product with non-OSS license choice
components in externally distributed
products

Open Core Zimbra single or few Need for the proprietary additions or need license choice, segmentation on features
of support
Product specialists Alfresco single or few Value perceived by user must be higher license choice
than the cost of going to an unsupported
recompilation (eg. CentOS); usually
mission-critical environments, need of
support or lack of internal expertise

Platfrom Providers RedHat many Value perceived by user must be higher license choice, copyrighted and
than the cost of going to an unsupported trademarked elements included in the
recompilation (eg. CentOS); usually product
mission-critical environments, need of
support or lack of internal expertise

Software Selection Navica many Complex requirements, many areas or Selection documents are usually
strict vertical requirements to match, proprietary; selection requires human
possibly large company size intervention (non-replicable)

Aggregate support OpenLogic many Large number of managed projects, use Inherent in the non-transferability of
providers in mission-critical infrastructure support contracts

Legal certification and Palamida many Potential legal risk Inherent in the non-transferability of
insurance certification and insurance

Training and documentation Gbdirect many Lack of internal experts (or too high cost Training material are usually non-public,
for creation of internal skills), complex trainers are inherently non-replicable
configuration and setup of OSS product

R&D cost sharing Eclipse single or few Significant R&D costs, higher than the license choice
cost of management of the shared
community

Indirect revenues Firefox single or few There should be an external source of license choice, copyrighted and
revenue linked to adoption (eg. trademarked elements included in the
Ecommerce sales of related products, product
search engine back-payments, etc.)
Usually linked to high adoption numbers

OSS Vendor Economic advantage for the Economic advantage for Potential disadvantages of the
Business model vendor the adopter model
Dual licensing Dissemination for the product The adopter may opt for the Low external participation (limited
with reduced costs, creation open source edition if it is code contributions)
of external ecosystem of add- deemed sufficient; for the
ons (outside the source), proprietary part, reduction in
visibility, self-segmentation of cost may give better
the market price/quality ratio
Open Core Reduction of R&D, reduced The adopter may opt for the Difficult to estimate the right
maintenance costs, visibility, open source edition if it is balance between open and closed
increased dissemination, deemed sufficient; for the parts, external groups may create
external ecosystem of add- proprietary part, reduction in substitutes for the proprietary parts
ons, self-segmentation of the cost may give better
market for the proprietary add- price/quality ratio
ons
Product specialists Reduction of R&D, reduced Reduction in cost may give Low barrier of entry for third-parties
maintenance costs, visibility, better price/quality ratio for
increased dissemination, the adopted software,
external ecosystem of add- stability, integrated support
ons reduces external costs
Platform Providers Reduction of R&D, reduced Reduction in cost may give Platform engineering requires large
maintenance costs, visibility, better price/quality ratio for R&D efforts even with shared
increased dissemination, the adopted software, resources
external ecosystem of stability, integrated support
software and additions reduces external costs,
legal protection is included,
easy to find trained
personnel, availability of
long-term options
Software Selection Cost of software certification Reduced selection costs; Limited market, difficulty in
and selection can be partially reduced risk of wrong following rapid evolution of the
shared across customers, as choice products covered (evaluation
most adopters have a large costs)
share of common needs

OSS Vendor Economic advantage for Economic advantage for Potential disadvantages of the
Business model the vendor the adopter model

Aggregate support Cost of support can be A single point of control Limited market, may be perceived as
providers partially shared across and cost for a large in partial competition with existing
customers, economies of number of project, reduced specialists
scale negotiation efforts for large
number of individual
vendors, simplified
management and
governance

Legal certification and Cost of legal certification and Equivalent to insurance; Limited market, difficult to estimate risk
insurance secondary-level insurance provides a materialized probabilities, need to cover separate
can be shared across the and stable costs against legal frameworks across the world with
most used OSS projects uncertain, difficult to different rules
quantify negative events

Training and A significant portion of Lower cost for training May be perceived as in partial
documentation training development costs compared to self-managed competition with existing specialists,
can be shared across training (from source code, human intensive, most of it cannot be
customers, economies of publicly available replicated at low cost
scale, reuse of community- documentation)
developed material

R&D cost sharing Reduction of R&D, reduced (same as vendor- in this Estabilishing the management and
maintenance costs case, vendor and adopter contribution structures may be
coincide) complex and costly, requires constant
effort

Indirect revenues Source availability reduces Adopters obtains a quality Requires a large external market for
engineering costs and product at no cost; incentives, may be dependent on a
increase visibility on multiple potential large ecosystem single (or small number) of actors
platforms for extensions increasing risk

● What is the advantage in participating? Two examples: Apple
and Nokia (Maemo platform)
● Maemo: The total software stack includes 10.5 million lines of
code (product and development tools), which is split into 85%
coming directly from OSS, and 15% either modified or developed
by Nokia. In source code lines the respective amounts are 8.9
Million lines of OSS code and 1.6 million lines of Nokia developed
software. Out of the 15% created by Nokia, 50% are made
available to the community as modifications to components or
totally new components, leaving roughly 7.5% of the software
stack closed. (…) Based on the COCOMO model we can estimate
the value of the utilized OSS to be $228,000,000, including both
product software and tools.”
● Apple: “Based on the COCOMO model the total cost of internally
developing the OSS included in the Darwin core and the used
development tools would be $350,000,000.”
● Also: reduced time-to-market thanks to the simplification of
acquisition and license negotiation processes (for Nokia: 6-12
months saved)


● BerkeleyDB BootCache BootX CF CFNetwork ChatServer Chess CommonCrypto Csu
CyrusIMAP DSAgent DSNISPlugin DSNSLPlugins DSPasswordServerPlugin DSTools
DirectoryService DiskArbitration DynamicPowerStep FirewallTool HeathrowATA ICU Jboss
JavaScriptCore JavaScriptGlue Kerberos KeyLargoATA Libc Libcpp_kext Libinfo Libkvm
Libm Libnotify Librpcsvc Libstreams Libsystem Liby MySQL NFS OpenAL OpenLDAP
OpenSSH OpenSSL PowerManagement SCSIHeaderInstaller SQLite Security
SecurityTokend SecurityTool SharedIP SmartCardServices SpamAssassin SquirrelMail
SystemStubs Tokend UserNotification WebCore X11 adv_cmds apache apache2
apache_mod_dav apache_mod_hfs_apple apache_mod_perl apache_mod_php
apache_mod_ssl architecture at_cmds autoconf autofs automake automount awk bash
basic_cmds bc bind9 bison bless blojsom boot bootp bootstrap_cmds bsdmake
bsdmanpages bsm bzip2 cctools cddafs configd cron crontabs cscope cups curl cvs
cvs_wrapped cxxfilt developer_cmds diffstat diskdev_cmds disklabel distcc doc_cmds
dyld eap8021x efax emacs enscript extenTools fetchmail file file_cmds files flex gcc gdb
gdbforcw gimp_print glibtool gm4 gnudiff gnumake gnuserv gnutar gnuzip gperf gpt
graphviz grep groff headerdoc hfs iodbc ipv6configuration isoutil jam kext_tools keymgr
ksh launchd ld64 less libedit libfs libiconv libpcap libproc libsecurityd libstdcxx
libstdcxx_SUPanWheat libtelnet libxml2 libxslt lsof lukemftp lukemftpd mDNSResponder
mail_cmds mailman man memberd misc_cmds modemccl msdosfs nano nasm ncurses
net_snmp netcat netinfo network_cmds ntfs ntp objc4 old_ncurses pam pam_modules
passwordserver_sasl patch_cmds pdisk perl portmap postfix ppp prebind procmail
project_makefiles python rcs rsync ruby samba screen securityd shell_cmds smb srm
stmalloc sudo syslog system_cmds system_config tcl tcp_wrappers tcpdump tcsh
texi2html texinfo text_cmds tidy top usertemplate vim volfs webdavfs wxWidgets xinetd
xnu yacc zip zlib zsh ...


● Participation models are different, and show different long-terms
perspectives:


● How to estimate when and how to reuse OSS code inside of a
product? We adapted the COCOMOII model, using a variation of
Boehm COTS adoption scheme:


● The “tailoring” of code is performed on 15% of the OSS code;
percentage comes from several separate projects, with
estimates ranging from 5% for mature projects with structured
and well-documented interfaces to 20% for complex, deeply-
interlocked code like that found in embedded systems.
● Tailoring cost is higher than traditional coding; for this reason,
the COCOMO complexity index is increased to 6 compared to
new-code development.
● Volatility is based on our own model for cost estimation and data
from literature on COTS (”Empirical observations on COTS
software integration effort based on the initial COCOTS
calibration database”, Abts C., Boehm B.W., Bailey Clark E.) and
it can be approximate with an average effort equivalent to 1.5 to
2.5 full time person-year.


● The results:


Fit with Acquisition Maintenance Support Control of
Require- Cost Cost Options Destiny
ments

• Tailored to • Full cost • Discretionary • Institution • Very high
require- • Expensive • Full costs for • Own the code
Build ments permanent changes
staff or • No on-going
contract fees

• Standard- • Shared cost • Mandatory • Vendor(s) • Very low
ized + vendor • Shared costs • Warran- • Limited/no
• Tailored via profit as + vendor ties and access to
add-ons license fee profit via service modify the
Buy annual level code
(vendor) license fees agreeme • Extensive add-
nts ons may
complicate
upgrades

• Assembled • Nil, minimal, • Discretionary • Institution • Very high
from or shared • Nil, minimal, • For fee • Full access to
Borrow standardi shared, or vendors the source
(open zed and full • Partners code
tailored • Commun-
source) ity

● “In 2000, Agfa HealthCare and Philips Medical Systems decided
to coordinate activities around DICOM validation testing by
bringing together efforts already started by both companies
under a joint DVT project. The intention was to produce a DVT
that could not only be used internally by both companies to test
their own products but also made freely available to other
original equipment manufacturers (OEMs) as a means of testing
their products to the same level of detail. The ultimate aim was
to reduce the time spent integrating proprietary systems by first
exposing these systems’ equipment to tests run using DVT.
● DVT project has a steering committee with responsibility for
guiding legal, technical, and commercial aspects. The steering
committee meets every 6 months to discuss past progress,
current issues, and future requirements. A project manager was
elected by the steering committee to manage the DVT project
on a daily basis and report back to the committee. Development
tasks were divided up based on the available skills of developers
who report to the project manager. In its first years, Agfa and
Philips provided the personnel to staff the DVT project.”


Collaborative development, sustainability models and licenses in OSS

● The increased R&D efficiency explains, along with “reputation
money”, the relatively high participation in terms of code
revealed by for-profit firms:

Type of firm Share of code revealed
Device manufacturers 42.30%
Component manufacturers 58.80%
Software firms 57.50%
universities 90.00%
hobbyists 93.30%


● And applies to many different kind of companies - OSS usage
increases employee efficiency independently of industry area:

Revenue per employee rating
(FLOSS firms vs. Industry average)
Computer Equipment 182%
Software consultancy and supply 427%
Services (excl. software cons. and supply) 211%
Manufacturing (excl. computer equip.) 136%
Other 204%
ALL: 221%


● “Finally, comparing the individual data on firms
with turnover of less than 500,000 Euro with the
variable on size classes of customers (by number
of employees), one can hypothesize a correlation
between the use of software Open Source and the
ability to attract customers of relatively larger
scale. At the same turnover, in other words,
companies “Open Source only” seem to have more
chances to obtain work orders from companies
with more than 50 employees (ie medium – large
compared to our universe of reference).” TEDIS
study on OSS, Venice University


● This set of common models will probably change in the future,
as more and more companies migrate the main revenue stream
from "products" to "services". We observed that models based
on recurring payments (like subscription services) seems to be
more effective than non-recurring ones, confirming previous
non-FLOSS research on IT firms like Weill-Malone
● The non-rival nature of most projects make it possible in a
simpler way to create “co-opetition” strategies, with companies
competing on the market and at the same time sharing effort for
improving their products (eg. Novell, IBM, Sun with the
OpenOffice.org project)
● Two main collaboration strategies were identified among smaller
companies: geographical (same product or service, different
geographical areas); “vertical” (among products) or “horizontal”
(among activities)
● Larger vendors are creating “certified marketplaces” that
leverage the market dominance of a platform (eg. RedHat,
MySQL) to provide simple access to packages already certified
by vendors


pkg1 pkg2 pkg3 ...pkg n

Software selection

Installation

Integration
Technical suitability cert.

Legal certification

Training

Maintenance and support

Legacy migration

● This is an example of a “product specialist” or a “platform
provider”, that performs an integrated set of activities on one or
more packages. Multiple vendors with overlapping products can
collaborate on a single offer (eg. operating system and Groupware)


pkg1 pkg2 pkg3 ...pkg n

Software selection

Installation

Integration
Technical suitability cert.

Legal certification

Training

Maintenance and support

Legacy migration

● This is an example of a “service specialist”, that performs a single
activity, on (usually) a very large number of packages. Collaboration
allows for the creation of an integrated service package along
multiple software offerings


● What can be said of OSS quality, in “live” and “successful”
projects?
● "The hypothesis that open source software fosters more
creativity is supported by our analysis. The growing rate, or the
number of functions added, was greater in the open source
projects than in the closed source projects. This indicates that
the open source approach may be able to provide more features
over time than by using the closed source approach.
● "In terms of defects, our analysis finds that the changing rate or
the functions modified as a percentage of the total functions is
higher in open source projects than in closed source projects.
This supports the hypothesis that defects may be found and
fixed more quickly in open source projects than in closed source
projects, and may be an added benefit for using the open source
development model.” (Paulson, Succi, Eberlein “An Empirical
Study of Open Source and Closed Source Software Products”)


● Similar results were obtained from static code analysis
companies; the average bug density of proprietary products is
on average 1 to 7 defects/Klocs depending on software class and
production quality methods; “mature” code has average bug
density of 0.5 d/Kl
● Reasoning:
● Apache Tomcat: 0.2 d/Kl
● MySQL: 0.09 d/Kl
● Linux TCP/IP: 0.1 d/Kl

● Coverity:
● BerkeleyDB 0.16 d/Kl
● PostgreSQL 0.026 d/Kl
● Linux (completo) 0.16 d/Kl


● Quality of “alive” OSS can be explained through reuse and
models of bug diffusion: (Mohagheghi, Conradi, Killi and Schwarz
“An Empirical Study of Software Reuse vs. Defect-Density and
Stability”)


● When development is performed using a controlled,
structured approach OSS is certifiable for life-critical or
security-sensitive use
● Among the standards matched:
● IEC 61508, safety-related programmable electronic
systems
● FDA 1252, COTS use in medical devices

● IEC 60880, software for use in nuclear plants

● DEF 00-55 and 00-56, software-based defense equipment

● ARINC 653, avionics

● FIPS 140, security and encryption in US governmental

systems
● SABI (Secret and Below Interoperability)

● various Common Criteria/EAL for traditional deployment,

including EAL4+
● EAL5 (Tokeneer, including formal specification and
verification)


● In 2001 the UK Health and Safety Executive
studied the Linux kernel, and found it to be
certifiable up to SIL3 (risk reduction >1000, prob.
of dangerous failures per hour <10-7), and
suggested use in
● ATC displays

● Railway control systems (except security
switches that are SIL4 only)
● Process plant control in oil, gas, chemical

● The HSE estimated the effort of certification at 6-8

person/year, with a realistic timeframe of 18
months (“Preliminary assessment of Linux for
safety related systems”, HSE Executive, 2002,
research report 011)


● Another HSE study found that most certification
schemes can be satisfied through:
● Creation of a single specification of behavior

● Consolidated test library

● Test execution procedures

● Code inspection and analysis

● Test execution with instrumented code to assess

coverage
● After first certification, cost of repeated
certification can be significantly reduced using a
specific integration process


External patch/code
sources

Verification barrier

Certified code base

Stable point-in-time code base

Periodic recertification


● What about innovation? Innovativeness ratios was found to be
on a par or better than proprietary software: (“Innovativeness of
open source software projects”, Klincewicz K., School of
Innovation Management, Tokyo Institute of Technology)
● Similar results were found by ARCFund in its study of Polish
companies, and Rossi, Lorenzi (“Innovativeness of Free/Open
Source solutions”): “Figures support the idea that FOSS solutions
are more innovative than proprietary ones: indeed, in all the
three dimensions, experts’ evaluations are higher for FOSS than
for proprietary software.”


● Another advantage comes from the integration of user-
generated innovation, that is possible when the contribution
process is open enough to allow external third-parties to affect
the development process. User-generated innovation is a (until
recently, through the efforts of Von Hippel) largely ignored effect
(Hippel E.V.,, “Democratizing innovation” MIT Press, 2004):


● What are the conditions for adoption by end-users?
● Apart from any ethical/development consideration, OSS must be
economically effective for companies and Public Administrations
● COSPA project: among the results, the demonstration that when
proper best practices are adopted, OSS can bring significant cost
reductions both in the short term (1 year) and long term (5
years)
● The project also demonstrated that finding support, software
selection and roadmap preparation are among the significant
costs (up to 40% of all costs, when intangibles are counted)
9000 16000

8000 14000
7000
12000
6000
10000
5000
OSS
4000 Proprietary 8000 OSS-5yrs
Prop-5yrs
3000 6000

2000
4000
1000
2000
0
SGV BH (phase 1) BH (phase 2) 0
SGV Estremadura BH (phase 1) BH (phase 2)


●
Beaumont hospital, Apache Tomcat, OpenLDAP,
Irlanda:
JasperReports, PHPnuke, JBOSS, Python, BIND, Junit,
PostgreSQL, CUPS, Linux (RedHat, Debian), FreeBSD, Samba,
Dia, KDE, SendMail, Dosemu, Postfix, Squid, OpenOffice, Firefox,
GCC, VNC, GIMP, MySQL, GNOME, Nagios, Wine, ZOPE


● The problem: as Open Source was introduced, the central Health
Care service reduced the available budget – as the “IT”
cathegory was refundable only for pre-approved companies and
services, and refunds were performed for licensing cost and in a
very limited way for customization services
● Procurement is in fact the largest technical factor both for pro-
and contra- OSS:
● On one side, the fact that OSS can be independently procured

without tenders encourages a “grassroots” effort from the
bottom to adopt ancillary software (usually in the IT
infrastructure category)
● On the other hand, most administrations (and some private

companies too) are still unable to handle properly the
acquisition process in absence of an OSS vendor that pushes
for what is at the end a packeted OSS solution
● The end result: most trials are successful, but not followed on

with practical implementations


● Also: most potential adopters are not aware of what projects are
available, and if those projects are suitable for adoption (or
make sense)
● In the EU SPIRIT initiative 485 projects were evaluated, and
classified in three groups:
● spontaneous, small scale: the majority of projects are small,

with few developers, usually young and of limited scope
● organized: either graduated from the first group or the result of

an open sourcing initiative, the second group is structured, old
(on average > 5 years) and usually commercially supported
● research project: structurally different from the “organized”

group, research projects tend to be younger but with the same
size. After the end of the research project, most software falls
in an abandoned state, unless it is taken up by external groups
(that may even be research groups...) and transformed in
“organized”


Realizzazione Web-based della scheda SVAMDI Padova, 25/6/2009

● VistA is a very good example of a successful open sourcing
process: Under the Freedom of Information Act (FOIA), the VistA
system, the CPRS interface, and unlimited ongoing updates
(500–600 patches per year) are provided as public domain
software.
● This was done by the US government in an effort to make VistA
available as a low cost electronic medical record system (EMR /
EHR) for non-governmental hospitals and other healthcare
entities.
● With funding from The Pacific Telehealth & Technology Hui, the
Hui 7 produced a version of VistA that ran on GT.M in a Linux
operating system, and that was suitable for use in private
settings


● VistA has since been adopted by commercial companies and
ported to a variety of environments, from individual practices to
clinics to hospitals, to regional healthcare co-ordination between
far-flung islands. In addition, VistA has been adopted within
similar provider environments worldwide - a non-profit
organization, WorldVistA, has also been established to extend
and collaboratively improve the VistA electronic health record
and health information system for use outside of its original
setting.
● Among the US adopters: non-VA healthcare facilities in Texas,
Arizona, Florida, Hawaii, Oklahoma, West Virginia, California,
New York, and Washington, D.C.
● Outside US: World Health Organization, Mexico, Samoa, Finland,
Jordan, Germany, Kenya, Nigeria, Egypt, Malaysia, India, Brazil,
and Pakistan


● Of similar scale, the Dossia project: “The Dossia Founders Group
is a consortium of large employers united in their goal of
providing employees, their dependents, retirees and others in
their communities with an independent, lifelong health record.
Dossia Founders are funding Dossia, an independent secure,
non-profit infrastructure for gathering and securely storing
information for lifelong health records.
The Dossia Founders Group includes AT&T, Applied Materials, BP
America, Inc., Cardinal Health, Intel Corporation, Pitney Bowes,
sanofi-aventis and Wal-Mart.
The Dossia project has been endorsed by the American Academy
of Pediatrics, the American Academy of Family Physicians, the
Centers for Disease Control and Prevention and the National
Association of Manufacturers”
● It is based on the Indivo platform (formerly PING) that has been
funded by the National Library of Medicine since 1998, and
Centers for Disease Control and Prevention since 2004, and the
Manton Center for Orphan Disease Research at Children's
Hospital Boston since 2008.


● The process of gradual introduction of OSS as part of a medical
IT solution can be performed in a structured way depending on
the environment and degree of user-impact
● The single, biggest cost in previous adoption experiments was
software selection – especially since there is little or no
“advertising” outside of some commercial OSS providers like
MedSphere
● Some large scale vendors are integrating OSS inside of their
products, but very few provide any information to the user
● A method that has been found effective in networked care
institutions is the “competence center” approach - a small,
technically oriented group of experts assessing packages and
implementability and distilling this knowledge for the partners
(including, eventually, guidance in obtaining commercial support
contracts).
● The evaluation process can be simplified using a two-tiered
evaluation schema, like QSOS, SQO-OSS, FLOSSMETRICS, that is
based on a code/community evaluation (liveness probability)
and a survey of functional capabilities


● FLOSSMETRICS software selection model:


● The adoption process can be simplified by introducing some
simple best practices (from COSPA/TOSSAD/OpenTTT):
● Three aspects of an adoption: management, technical, social
● The three aspects are equally important, sometimes the social
one is even more significant than the technical one
● Unfortunately, many migrations and adoption processes were
focused only on technical matters, and this explains the large
number of failures
● There are lots of successes, and a common thread is the
attention to ancillary aspects and good project management


● Management guidelines:
● Be sure of management commitment to the transition
(troubleshooting point: if the only people working on planning
the migration is from IT/MIS, there may be insufficient
information in upper management and financial planning for
continuing the migration after the initial step. )
● Prepare a clear overview of what is expected from the migration
or adoption, including measurable benchmarks (troubleshooting
point: if the only perceived advantage is that “the software
comes from the net for free”, there may be a set of wrong
assumptions that will probably lead to a final negative judgment
on the migration.)
● Make sure that the timetable is realistic (Troubleshooting point:
when migration time is measured in days, and no post-migration
effort is planned, the process may be forced to a stop after the
planned resources are expended.)


● Review the current software/IT procurement and development
procedure (Troubleshooting point: When no change of
procurement and development is planned, the management
may have not understood the scope of changed required for the
adoption of FLOSS. )
● Seek out advice or search for information on similar transitions
● Avoid “big switch” transition, and favor incremental migrations
● Assign at least a person to interacting with the OSS community
or the OSS vendor, and try to find online information sources
(Troubleshooting point: when no one knows where to find
information on the tools that are in use, or when everyone has
to search on web sites on their own for finding usage tips. )


● Technical guidelines:
● Understand the way OSS is developed (Troubleshooting point:
when the IT manager or the developers think that OS is some
kind of commercial software that someone has put for free on
the net, and that it “just works”. )
● Create a complete survey of software and hardware that will be
affected by the migration, and what functionality the company is
looking for
● Use the flexibility of OSS to create local adaptations
● There is much more software available than what is installed by
default
● In selecting packages, always favor stability over functionality or
at least understand the tradeoff (“nice! I just updated to the
lastest beta! why? The release number is higher! It must be
better, for sure!”)
● Design the workflow support infrastructure to reduce the
number of “impedance mismatches”
● Introduce a trouble ticket system
● Compile and update a detailed migration workbook


● Social guidelines:
● Provide background information on OSS
● Don't force the change on the users, provide explanations
● Use the migration as an occasion to improve users skill (identify
local “champions”, that is local FLOSS enthusiasts, that can
provide peer support to other users, and offer them additional
training occasions or management recognition. In general, it is
useful to create an internal Intranet accessible page that
provides links to all the different training packages. )
● Make it easy to experiment and learn


● What is the possible evolution, after initial adoption?
● The overall model of OSS adoption was studied by Carbone et al.
and is based on the “ladder model” of company evolution

value
appropriated

collaborate and
redefine

champion

contribute
use
Time

engineering driven business driven
denial
single product multiple projects


value
appropriated

collaborate and
redefine

champion

contribute
use
Time

denial

step 1: crossing the chasm between denial and use. It
requires knowledge on what is available, countering
wrong beliefs and FUD, best practices for adoption and
migration


value step 2: from users to contributors. It requires information
appropriated
on the reality of external contributions, on liveness of
projects, on how to cooperate and interact with projects

collaborate and
redefine

champion

contribute
use
Time

denial


value step 3: from contributors to champions. Requires
appropriated
information on business models, on sustainability,
on relative profitability of models and the interaction
between licensing and community

collaborate and
redefine

champion

contribute
use
Time

denial


Thanks

Carlo Daffara
cdaffara@conecta.it

Oss healthcare

Recommended

Recommended

More Related Content

Similar to Oss healthcare

Similar to Oss healthcare (20)

More from Carlo Daffara

More from Carlo Daffara (20)

Oss healthcare