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 OSS: myths, reality and medical IT

● 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) OSS: myths, reality and medical IT

OSS: myths, reality and medical IT

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. OSS: myths, reality and medical IT

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. OSS: myths, reality and medical IT

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. OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● 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. OSS: myths, reality and medical IT

● 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. OSS: myths, reality and medical IT

● ...but licensing affects participation and the possible coordination organization form: OSS: myths, reality and medical IT

● 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. OSS: myths, reality and medical IT

● 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. OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● 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: myths, reality and medical IT

● 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) OSS: myths, reality and medical IT

● 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) OSS: myths, reality and medical IT

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: OSS: myths, reality and medical IT

● 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? OSS: myths, reality and medical IT

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) OSS: myths, reality and medical IT

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). OSS: myths, reality and medical IT

● 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. OSS: myths, reality and medical IT

● 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. OSS: myths, reality and medical IT

● 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. OSS: myths, reality and medical IT

● 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. OSS: myths, reality and medical IT

● 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: myths, reality and medical 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) OSS: myths, reality and medical IT

● 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 ... OSS: myths, reality and medical IT

● Participation models are different, and show different long-terms perspectives: OSS: myths, reality and medical IT

● 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: OSS: myths, reality and medical IT

● 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. OSS: myths, reality and medical IT

● The results: OSS: myths, reality and medical IT

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.” OSS: myths, reality and medical IT

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% OSS: myths, reality and medical IT

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% OSS: myths, reality and medical IT

● “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 OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

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) OSS: myths, reality and medical IT

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 OSS: myths, reality and medical IT

● 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”) OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● 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”) OSS: myths, reality and medical IT

● 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) OSS: myths, reality and medical IT

● 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) OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

External patch/code sources Verification barrier Certified code base Stable point-in-time code base Periodic recertification OSS: myths, reality and medical IT

● 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.” OSS: myths, reality and medical IT

● 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): OSS: myths, reality and medical IT

● 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) OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● 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” OSS: myths, reality and medical IT

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 OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● 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. OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● FLOSSMETRICS software selection model: OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● 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.) OSS: myths, reality and medical IT

● 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. ) OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

● 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 OSS: myths, reality and medical IT

value appropriated collaborate and redefine champion contribute use Time engineering driven business driven denial single product multiple projects 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 OSS: myths, reality and medical IT

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 engineering driven business driven denial single product multiple projects OSS: myths, reality and medical IT

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 engineering driven business driven denial single product multiple projects OSS: myths, reality and medical IT

Thanks Carlo Daffara cdaffara@conecta.it

Oss healthcare

by Conecta Research on Apr 25, 2010

Accessibility

Upload Details

Usage Rights

1 Embed 3

Statistics

Oss healthcare — Presentation Transcript