HIS 2015: Prof. Mark Little - Open Source Challenges in the Enterprise
Dr Mark Little
Red Hat, Inc.
Open Source Challenges in the Enterprise
•Research into fault-tolerant distributed systems
•Arjuna, Argus, Isis/Horus, Emerald, Xerox, …
•DCE, DCOM, CORBA, JavaRMI, HTTP, Web Services, …
•Active in OMG, OASIS, W3C, JCP, GGF and others
•Co-author of a number of OMG, WS-* etc.
specifications and standards
•Joined JBoss in 2005, Red Hat since 2006
Requirements from dependability
•What is dependability?
• IFIP 10.4 “the trustworthiness of a computing
system which allows reliance to be justifiably
placed on the service it delivers, enables these
various concerns to be subsumed within a single
conceptual framework. Dependability thus includes
as special cases such attributes as reliability,
availability, safety, security.”
•Fault prevention: how to prevent fault occurrence or
•Fault tolerance: how to provide a service complying
with the specification in spite of faults;
•Fault removal: how to reduce the presence (number,
seriousness) of faults;
•Fault forecasting: how to estimate the present
number, the future incidence, and the
consequences of faults.
Dependability challenges for open
•Perception versus reality?
•Closed source is more dependable? How? Why?
•Should open source have more challenges?
•Skills and understanding of basic principles?
•Skills and understanding of complex principles?
•Hardware provisioning and testing?
•Testing at scale?
Benefits of open source?
•“peer reviewed software, which leads to more reliability”
•Stress testing of software is critical
•Closed source “reliability through experts”
•“enables anyone to examine software for security flaws”
•What about exploiting issues?
•Closed source “security through obscurity”
Open vs closed source
•Apache more reliable that MSFT IIS
•1988 first internet worm via sendmail and fingers
•But code availability mitigated the spread
•MITRE 2001 “open-source products have access to
extensive expertise, and this enables the software
to achieve a high level of efficiency”
•Software defects at similar levels but …
•e-Week Labs “FOSS organizations in general respond to
problems more quickly and openly, while proprietary
‘software vendors instinctively cover up, deny, and
•Understand community differences
•Project lead versus group consensus for features, bug
•Code reviews, push model
•Some things may not be accepted upstream
•Contributor and user communities
•They're all important for different reasons
•It's important to develop as much upstream first
•Not always possible given time constraints
•Push/merge upstream as soon as possible
•Influence project roadmaps
•Everything should go upstream eventually
•Security and critical bug fix builds
Productisation is crucial
•Few projects are product ready by default
•Not everything in an upstream project should go into
•May be too immature
•May be a feature that doesn't make sense
•Sanitisation of projects is important
•Not everything in a product may have gone
•Not everything in a project may have been built from
•Upstream projects typically focus on unit tests
•Unit tests != QA
•Hardware and software limitations
•Also impacts time to release
•Performance testing similarly
•It's hard to do!
•Be prepared to commit people, hardware and
Enterprise use of open source
•Enterprise adoption of open source is a fact
•You may be surprised …
The World Wide Web
•CERN httpd released as open source 1991
•Huge adoption and kicked off e-commerce, global
use of internet
•Amazon, Google, Twitter, Facebook, …
•List of ALL websites in 1993 captured on one page!
•Other benefits came later … REST, Web Services/
•1987 saw Minix adoption in academic circles
•Not open source originally
•Trend was to have something at home similar to work
•Also for cheaper student equipment
•1991 saw first Linux release
•Taken to heart by academic and research communities
•Huge contributor community
•Linux replaced Unix at the backend
•Java (Oak) released in 1996
•Not open source, but source was available
•Code available to Blackdown Java project
•GCJ in 2005
•Apache Harmony announced in 2005
•OpenJDK released in 2007
Mobile, cloud and language explosion
•OpenStack, OpenShift, …
•More new languages in the last 10 years than
•Ruby, Clojure, Ceylon, Scala, Erlang, Lisp, …
•Open source is no less dependable than closed
•Often more dependable
•Remember you don’t always control your own
•Be prepared to bring your own hardware
•Scale testing may be an issue upstream
•Reliability testing may be an issue upstream