oss healthcare

Open Source Software:Myths, Realityand Medical IT

Carlo DaffaraEuropean 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)


Open-source based business models OpenTTT 1st review

Main Licensing model Main revenue generation

Company dual licensing Badgew are Pure OSS selection ITSC Subscription licensing

du

al lic

.

Funambol l l l

Lustre l l

MuleSource l l l l

Mysql l l l

OpenClovis l l

Pentaho l l l

sleepycatdb l l

Sp

lit

OS

S/c

om

me

rc

ial re

lea

se

s

Adaptive Planning l l

Alterpoint l l l

Altinity l l l

Codew eaver (WINE) l l

Coupa l l

Digium (Asterisk) l l

Enormalism l l

EnterpriseDB l l

GreenPlum l l

GroundWork l l

Hyperic l l

JasperSoft l l

Know ledgeTree l l

OpenCountry l l

Open-Xchange l

NoMachine NX l l

rPath l l

Scalix 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

VirtualBox l l

Vyatta l l l

XenSource (Xen) l l

Zend (PHP) l l

ZIMBRA l l l

Ba

dg

ew

are

1bizcom l l

CATS 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

pro

du

ct

sp

ec

ialis

ts

Alf resco l l l

Babel l l

CentraView l l

CleverSafe l l

Compiere l l l

Exadel l l

Jitterbit l l l

Mergere l l

Mindquarry l l

Mirth l l

OfBIZ l l

Qlusters (OpenQRM) l l

Symbiot/OpenSIMS l l

Talend l l

UltimateEMR l l

VISTA l l

vTiger l l

Zenoss l l

pla

tf.

Pro

vid

.

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

ayamon l l l

Enomaly l l l

navica l l

openlogic l l

Optaros l l l

x-tend l l l

Oth

er

CiviCRM l

Eclipse l

Mozilla l

OSAF Chandler l

Sourceforge

OSS and commercial

versions

multiple packages covered

se

lec

tio

n –

co

ns

ultin

g

● 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 Business model

Vendor example

Number of covered products

Sale condition Freeriding protection

Dual licensing MySQL single or few integration of the product with non-OSS components in externally distributed products

license choice

Open Core Zimbra single or few Need for the proprietary additions or need of support

license choice, segmentation on features

Product specialists Alfresco single or few Value perceived by user must be higher than the cost of going to an unsupported recompilation (eg. CentOS); usually mission-critical environments, need of support or lack of internal expertise

license choice

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

license choice, copyrighted and trademarked elements included in the product

Software Selection Navica many Complex requirements, many areas or strict vertical requirements to match, possibly large company size

Selection documents are usually proprietary; selection requires human intervention (non-replicable)

Aggregate support providers

OpenLogic many Large number of managed projects, use in mission-critical infrastructure

Inherent in the non-transferability of support contracts

Legal certification and insurance

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

Training and documentation Gbdirect many Lack of internal experts (or too high cost for creation of internal skills), complex configuration and setup of OSS product

Training material are usually non-public, trainers are inherently non-replicable

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

license choice

Indirect revenues Firefox single or few There should be an external source of revenue linked to adoption (eg. Ecommerce sales of related products, search engine back-payments, etc.) Usually linked to high adoption numbers

license choice, copyrighted and trademarked elements included in the product


Economic advantage for the vendor

Economic advantage for the adopter

Potential disadvantages of the model

Dual licensing Dissemination for the product with reduced costs, creation of external ecosystem of add-ons (outside the source), visibility, self-segmentation of the market

The adopter may opt for the open source edition if it is deemed sufficient; for the proprietary part, reduction in cost may give better price/quality ratio

Low external participation (limited code contributions)

Open Core Reduction of R&D, reduced maintenance costs, visibility, increased dissemination, external ecosystem of add-ons, self-segmentation of the market for the proprietary add-ons

The adopter may opt for the open source edition if it is deemed sufficient; for the proprietary part, reduction in cost may give better price/quality ratio

Difficult to estimate the right balance between open and closed parts, external groups may create substitutes for the proprietary parts

Product specialists Reduction of R&D, reduced maintenance costs, visibility, increased dissemination, external ecosystem of add-ons

Reduction in cost may give better price/quality ratio for the adopted software, stability, integrated support reduces external costs

Low barrier of entry for third-parties

Platform Providers Reduction of R&D, reduced maintenance costs, visibility, increased dissemination, external ecosystem of software and additions

Reduction in cost may give better price/quality ratio for the adopted software, stability, integrated support reduces external costs, legal protection is included, easy to find trained personnel, availability of long-term options

Platform engineering requires large R&D efforts even with shared resources

Software Selection Cost of software certification and selection can be partially shared across customers, as most adopters have a large share of common needs

Reduced selection costs; reduced risk of wrong choice

Limited market, difficulty in following rapid evolution of the products covered (evaluation costs)


Economic advantage for the vendor

Economic advantage for the adopter

Potential disadvantages of the model

Aggregate support providers

Cost of support can be partially shared across customers, economies of scale

A single point of control and cost for a large number of project, reduced negotiation efforts for large number of individual vendors, simplified management and governance

Limited market, may be perceived as in partial competition with existing specialists

Legal certification and insurance

Cost of legal certification and secondary-level insurance can be shared across the most used OSS projects

Equivalent to insurance; provides a materialized and stable costs against uncertain, difficult to quantify negative events

Limited market, difficult to estimate risk probabilities, need to cover separate legal frameworks across the world with different rules

Training and documentation

A significant portion of training development costs can be shared across customers, economies of scale, reuse of community-developed material

Lower cost for training compared to self-managed training (from source code, publicly available documentation)

May be perceived as in partial competition with existing specialists, human intensive, most of it cannot be replicated at low cost

R&D cost sharing Reduction of R&D, reduced maintenance costs

(same as vendor- in this case, vendor and adopter coincide)

Estabilishing the management and contribution structures may be complex and costly, requires constant effort

Indirect revenues Source availability reduces engineering costs and increase visibility on multiple platforms

Adopters obtains a quality product at no cost; potential large ecosystem for extensions

Requires a large external market for incentives, may be dependent on a single (or small number) of actors 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:


• Very high• Full access to

the source code

• Institution• For fee

vendors• Partners• Commun-

ity

•Discretionary•Nil, minimal,

shared, or full

• Nil, minimal, or shared

• Assembled from standardized and tailored

Borrow(open

source)

• Very low• Limited/no

access to modify the code

• Extensive add-ons may complicate upgrades

•Vendor(s)•Warran-

ties and service level agreements

•Mandatory•Shared costs

+ vendor profit via annual license fees

• Shared cost + vendor profit as license fee

• Standard-ized

• Tailored via add-ons

Buy(vendor)

• Very high• Own the code

• Institution• Discretionary • Full costs for

changes• No on-going

fees

• Full cost• Expensive

permanent staff or contract

• Tailored to require-mentsBuild

Control ofDestiny

SupportOptions

MaintenanceCost

AcquisitionCost

Fit with Require-ments

● “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 revealedDevice manufacturers 42.30%Component manufacturers 58.80%Software firms 57.50%universities 90.00%hobbyists 93.30%


Collaborative development, sustainability models and licenses in OSS

● 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


Software selection

Installation

Integration

Technical suitability cert.

Legal certification

Training

Maintenance and support

Legacy migration

pkg1 pkg2 pkg3 ...pkg n

● 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)


Software selection

Installation

Integration

Technical suitability cert.

Legal certification

Training

Maintenance and support

Legacy migration

pkg1 pkg2 pkg3 ...pkg n

● 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

Periodic recertification

Stable point-in-time code base

Certified code base

● 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):


SGV BH (phase 1) BH (phase 2)

0

1000

2000

3000

4000

5000

6000

7000

8000

9000

OSSProprietary

SGV Estremadura BH (phase 1) BH (phase 2)

0

2000

4000

6000

8000

10000

12000

14000

16000

OSS-5yrsProp-5yrs

● 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)


● Beaumont hospital, Irlanda: Apache Tomcat, OpenLDAP, 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

Time

denial

usecontribute

champion

engineering driven business driven

single product multiple projects

collaborate and redefine

value appropriated

Time

denial

usecontribute

champion




step 1: crossing the chasm between denial and use. Itrequires knowledge on what is available, counteringwrong beliefs and FUD, best practices for adoption andmigration


value appropriated

Time

denial

usecontribute

champion




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


value appropriated

Time

denial

usecontribute

champion




step 3: from contributors to champions. Requiresinformation on business models, on sustainability,on relative profitability of models and the interactionbetween licensing and community


Thanks

Carlo [email protected]

oss healthcare

Documents

pkg1 pkg2

open source

trademarked

technical

aggregate

reduced maintenance

closed source

average bug