HIS 2015

1. Dr Mark Little
Red Hat, Inc.
Open Source Challenges in the Enterprise
1

2. Some background
•Research into fault-tolerant distributed systems
since 1986
•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
2

3. 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.”
3

4. Dependability methods
•Fault prevention: how to prevent fault occurrence or
introduction;
•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.
4

5. Dependability challenges for open
source?
•Perception versus reality?
•Closed source is more dependable? How? Why?
•Should open source have more challenges?
•Design time?
•Skills and understanding of basic principles?
•Skills and understanding of complex principles?
•Implementation?
•Hardware provisioning and testing?
•Testing at scale?
5

6. Benefits of open source?
•Reliability
•“peer reviewed software, which leads to more reliability”
•Stress testing of software is critical
•Closed source “reliability through experts”
•Security
•“enables anyone to examine software for security flaws”
•What about exploiting issues?
•Closed source “security through obscurity”
6

7. 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
delay.’’
7

8. 8

9. Github activity
9

10. Community involvement
•Understand community differences
•Release schedules
•Project lead versus group consensus for features, bug
fixes etc.
•Code reviews, push model
•Some things may not be accepted upstream
•Contributor and user communities
•They're all important for different reasons
10

11. Upstream development
•It's important to develop as much upstream first
•Not always possible given time constraints
•Push/merge upstream as soon as possible
•Collaborative development
•Influence project roadmaps
•Everything should go upstream eventually
•Security and critical bug fix builds
11

12. Productisation is crucial
•Few projects are product ready by default
•Not everything in an upstream project should go into
a product
•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
upstream yet
•Not everything in a project may have been built from
source
12

13. Testing
•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
software!
13

14. Enterprise use of open source
•Enterprise adoption of open source is a fact
•You may be surprised …
14

15. 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/
SOAP
15

16. Linux
•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
•Open source!
•Taken to heart by academic and research communities
•Huge contributor community
•Linux replaced Unix at the backend
16

17. Java
•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
17

18. Mobile, cloud and language explosion
•Android
•Linux
•Java (-ish)
•EC2
•Linux
•OpenStack, OpenShift, …
•More new languages in the last 10 years than
previous 30
•Ruby, Clojure, Ceylon, Scala, Erlang, Lisp, …
18

19. 19

20. Big Data/NoSQL/RDBMS/Data Grids
20

21. GE Energy and Smart Grid
21

22. FAA Next Generation
22

23. Space exploration!
23

24. High Energy Physics
24

25. 25

26. Conclusions
•Open source is no less dependable than closed
source
•Often more dependable
•Remember you don’t always control your own
destiny
•Be prepared to bring your own hardware
•Scale testing may be an issue upstream
•Reliability testing may be an issue upstream
26