Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

HIS 2015: Prof. Mark Little - Open Source Challenges in the Enterprise

HIS 2015

Related Books

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

HIS 2015: Prof. Mark Little - Open Source Challenges in the Enterprise

  1. 1. Dr Mark Little Red Hat, Inc. Open Source Challenges in the Enterprise 1
  2. 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. 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. 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. 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. 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. 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. 8
  9. 9. Github activity 9
  10. 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. 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. 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. 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. 14. Enterprise use of open source •Enterprise adoption of open source is a fact •You may be surprised … 14
  15. 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. 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. 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. 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. 19
  20. 20. Big Data/NoSQL/RDBMS/Data Grids 20
  21. 21. GE Energy and Smart Grid 21
  22. 22. FAA Next Generation 22
  23. 23. Space exploration! 23
  24. 24. High Energy Physics 24
  25. 25. 25
  26. 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

    Be the first to comment

    Login to see the comments

HIS 2015


Total views


On Slideshare


From embeds


Number of embeds