Dr Mark Little Red Hat, Inc.

Open Source Challenges in the Enterprise

1

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

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

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

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

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

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

Github activity

9

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

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

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

source12

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

Enterprise use of open source

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

14

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

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

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

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

Big Data/NoSQL/RDBMS/Data Grids

20

GE Energy and Smart Grid

21

FAA Next Generation

22

Space exploration!

23

High Energy Physics

24

25

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