Day: Open Development

978 views

Published on

Day's R&D philosophy is designed to leverage open development through leadership in a triad of infrastructure innovation: open source, open standards, and open architecture. This talk
is about how open development works, the science behind our approach, and why it provides long-term benefits for our products, our customers, and our growth as a company.

Roy Fielding, Chief Scientist, Day Software

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
978
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Day: Open Development

  1. 1. Monday, October 18, 2010
  2. 2. Open Development Roy T. Fielding, Ph.D. Chief Scientist, Day Software Monday, October 18, 2010
  3. 3. OPEN SOURCE 3 Monday, October 18, 2010
  4. 4. OPEN SOURCE OPEN STANDARDS 4 URI HTTP CMIS JSOP JCR URI Templates HTML Monday, October 18, 2010
  5. 5. OPEN SOURCE OPEN STANDARDS OPEN ARCHITECTURE 5 REST OSGi Monday, October 18, 2010
  6. 6. Collaboration It’s all about Monday, October 18, 2010
  7. 7. Collaboration but how? Monday, October 18, 2010
  8. 8. Effective Collaboration ✴ (One) Shared Goal ✴ Agree how to disagree & decide ✴ Shared Workspace ✴ Dynamic Awareness ✴ Parallelization Monday, October 18, 2010
  9. 9. OPEN SOURCE OPEN STANDARDS OPEN ARCHITECTURE 9 Monday, October 18, 2010
  10. 10. Open Architecture ? Not talking about open exoskeleton buildings 10 Monday, October 18, 2010
  11. 11. Open Architecture ? Not talking about Open Sourced Architecture 11 Monday, October 18, 2010
  12. 12. Open Architecture ? Not even talking about personal computer open architecture 12 Monday, October 18, 2010
  13. 13. Open Architecture ? versus Mainly talking about design for open systems 13 Monday, October 18, 2010
  14. 14. Why talk about Open Architecture? 14 Open Development Collaborative open source development > emphasizes community > takes advantage of the scalability obtainable through Internet-based virtual organizations > adapts to the volunteer nature of developers Monday, October 18, 2010
  15. 15. Why talk about Open Architecture? 15 Open Development + Conway’s Law Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. Melvin E. Conway, Datamation, April 1968 http://www.melconway.com/law/ index.html Monday, October 18, 2010
  16. 16. True open development (a.k.a, Community-driven Design) will only occur when the design of your system reflects the organizational structure of open development! Why talk about Open Architecture? 16 Open Development + Conway’s Law Monday, October 18, 2010
  17. 17. Why talk about Open Architecture? 17 Open Development + Conway’s Law + Change is inevitable! Decentralized Software Evolution (or rapid obsolescence) Monday, October 18, 2010
  18. 18. 20 August 2010 18 Decentralized Software Evolution Requires Architecture by Design open (software) architecture used by open development projects to enable decentralized software evolution so that others can continue to design the software and fulfill Conway’s Law leading to success over time! Monday, October 18, 2010
  19. 19. Challenges ✴ Trade-off: Adaptability vs Consistency ✴ what changes are possible? ✴ what assurances are provided? ✴ Where to place the open points ✴ behavioral junctions (APIs, callback hooks) ✴ virtual machines (command tables, scripting) ✴ data flow (filters, plug-ins) Monday, October 18, 2010
  20. 20. Closed Source Examples ✴ Adobe Monday, October 18, 2010
  21. 21. Closed Source Examples ✴ Apple iPhone Ecosystem Monday, October 18, 2010
  22. 22. Open Source Examples ✴ What is common to all of the largest and most successful open source projects? ✴ a software architecture ✴ designed to promote anarchic collaboration ✴ through extensions ✴ while preserving control over the core interfaces Monday, October 18, 2010
  23. 23. 23 Apache httpd: modules [Apache Modeling Project, f-m-c.org] Modules • simplify core • enable independent development • promote experiments Project improves • reduced friction • anarchic growth • more features • less communication Monday, October 18, 2010
  24. 24. 24 Apache httpd: I/O filters [Apache Modeling Project, f-m-c.org] Filters provide more extensibility • protocol replacement • httpd, ftpd, nntpd, … • stackable content manipulation • extensions that can extend other extensions Monday, October 18, 2010
  25. 25. 25 Linux Kernel Modules Modules • simplify core • enable independent development • promote experiments Project improves • reduced friction • anarchic growth • more features • less communication [diagram from Ivan T. Bowman, 1998] Monday, October 18, 2010
  26. 26. 26 Mozilla Firefox Open Source Extensible Architecture Plug-in Tools Layered CSS Editor Platform Monday, October 18, 2010
  27. 27. World Wide Web Project Browsers Information 27 next table of contents elements attributes index HTML 4.01 Specification W3C Recommendation 24 December 1999 This version: http://www.w3.org/TR/1999/REC-html401-19991224 (plain text [794Kb], gzip'ed tar archive of HTML files [371Kb], a .zip archive of HTML files [405Kb], gzip'ed Postscript file [746Kb, 389 pages], gzip'ed PDF file [963Kb]) Latest version of HTML 4.01: http://www.w3.org/TR/html401 Latest version of HTML 4: http://www.w3.org/TR/html4 Latest version of HTML: http://www.w3.org/TR/html Previous version of HTML 4.01: http://www.w3.org/TR/1999/PR-html40-19990824 Previous HTML 4 Recommendation: http://www.w3.org/TR/1998/REC-html40-19980424 Editors: Dave Raggett <dsr@w3.org> Arnaud Le Hors, W3C Ian Jacobs, W3C Copyright ©1997-1999 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Abstract This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 [HTML32] and HTML 2.0 [RFC1866]), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide. HTML 4 is an SGML application conforming to International Standard ISO 8879 -- Standard Generalized Markup Language [ISO8879]. Status of this document Network Working Group R. Fielding Request for Comments: 2068 UC Irvine Category: Standards Track J. Gettys J. C. Mogul DEC H. Frystyk T. Berners-Lee MIT/LCS January 1997 Hypertext Transfer Protocol -- HTTP/1.1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as “HTTP/1.1”. Network Working Group T. Berners-Lee Request for Comments: 3986 W3C/MIT Obsoletes: 2732, 2396, 1808 R. Fielding STD: 66 Day Software Updates: 1738 L. Masinter Category: Standards Track Adobe Systems January 2005 Uniform Resource Identifier (URI): Generic Syntax Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright © The Internet Society (2005). All Rights Reserved. Abstract A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. Protocols Monday, October 18, 2010
  28. 28. Web Implementation 28 Application Servers Dynamic Content Centralized Data RDBMS, NFS, SAN Webservers/Gateways Accelerator Cache User Agents Intermediary Proxy Cache Monday, October 18, 2010
  29. 29. Web Architecture 29 $ $ $ $ $ $ $ $User Agents Proxies Gateways Origin Servers Monday, October 18, 2010
  30. 30. Web Architecture 30 next table of contents elements attributes index HTML 4.01 Specification W3C Recommendation 24 December 1999 This version: http://www.w3.org/TR/1999/REC-html401-19991224 (plain text [794Kb], gzip'ed tar archive of HTML files [371Kb], a .zip archive of HTML files [405Kb], gzip'ed Postscript file [746Kb, 389 pages], gzip'ed PDF file [963Kb]) Latest version of HTML 4.01: http://www.w3.org/TR/html401 Latest version of HTML 4: http://www.w3.org/TR/html4 Latest version of HTML: http://www.w3.org/TR/html Previous version of HTML 4.01: http://www.w3.org/TR/1999/PR-html40-19990824 Previous HTML 4 Recommendation: http://www.w3.org/TR/1998/REC-html40-19980424 Editors: Dave Raggett <dsr@w3.org> Arnaud Le Hors, W3C Ian Jacobs, W3C Copyright ©1997-1999 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Abstract This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 [HTML32] and HTML 2.0 [RFC1866]), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide. HTML 4 is an SGML application conforming to International Standard ISO 8879 -- Standard Generalized Markup Language [ISO8879]. Status of this document Network Working Group R. Fielding Request for Comments: 2068 UC Irvine Category: Standards Track J. Gettys J. C. Mogul DEC H. Frystyk T. Berners-Lee MIT/LCS January 1997 Hypertext Transfer Protocol -- HTTP/1.1 Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as “HTTP/1.1”. Network Working Group T. Berners-Lee Request for Comments: 3986 W3C/MIT Obsoletes: 2732, 2396, 1808 R. Fielding STD: 66 Day Software Updates: 1738 L. Masinter Category: Standards Track Adobe Systems January 2005 Uniform Resource Identifier (URI): Generic Syntax Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright © The Internet Society (2005). All Rights Reserved. Abstract A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. Protocols Monday, October 18, 2010
  31. 31. Architecting It’s all about Open Development for 31 Monday, October 18, 2010
  32. 32. Architectural Styles 32 Ionic Order Monday, October 18, 2010
  33. 33. A horizontal abstraction on architecture ‣ a way of naming architectural patterns in implementation An architectural style is a set of constraints ‣ unfortunately, constraints are hard to visualize  kind of like gravity or electromagnetism  observed only by their effect on others ‣ and style constraints are voluntary  there are no architecture police, but there are many architecture critics Constraints induce architectural properties ‣ both desirable and undesirable properties  a.k.a., software qualities and design trade-offs 20 August 2010 Architectural Styles 33 Monday, October 18, 2010
  34. 34. 20 August 2010 Representational State Transfer The REST architectural style is 1 a model of ideal Web application behavior 2 a guide for optimizing Web architecture 3 a pattern for communicating ‣ architectural constraints ‣ induced properties ‣ resulting trade-offs 4 a new software industry buzzword 34 Monday, October 18, 2010
  35. 35. REST on a slide the disadvantages) of the optional constraints when they are known to be in effect for some Figure 5-9. REST Derivation by Style Constraints RR CS LS VM U CSS LCS COD$ C$SS LC$SS LCODC$SS REST replicated on-demand separated layered mobile uniform interface stateless shared intermediate processing cacheable extensible simple reusable scalable reliable multi- org. visible programmable 35 Monday, October 18, 2010
  36. 36. Monday, October 18, 2010
  37. 37. Monday, October 18, 2010
  38. 38. Monday, October 18, 2010
  39. 39. 39 Eclipse Platform [Birsan, ACM Queue, Mar 2005] Taking modular extensibility to the next level OSGi Monday, October 18, 2010
  40. 40. 40 Eclipse Platform Monday, October 18, 2010
  41. 41. 41 Eclipse Platform Monday, October 18, 2010
  42. 42. Apache Sling 42 Drop-in Extensibility using OSGi Bundles jsp rubyscala groovy esp... JCR backed Content-oriented WebDAV-able REST-based + OSGi REST Monday, October 18, 2010
  43. 43. OPEN SOURCE OPEN STANDARDS OPEN ARCHITECTURE 43 REST OSGi Monday, October 18, 2010
  44. 44. OPEN SOURCE OPEN STANDARDS Standards 44 URI HTTP CMIS JSOP JCR URI Templates HTML Monday, October 18, 2010
  45. 45. OPEN SOURCE 45 Monday, October 18, 2010
  46. 46. The ASF in 2010 > 2359 committers 84 projects (+ 36 incubating) No offices almost no f2f meetings all decisions on mailing listsHundreds of releases ASF members: 330 3 TB/day www traffic Monday, October 18, 2010
  47. 47. Apache Decisions +1 Monday, October 18, 2010
  48. 48. revision control system mailing lists + archives IRC Wikis blogs issue tracker automated builds httpd (of course) Shared workspace Monday, October 18, 2010
  49. 49. Dynamic Awareness Monday, October 18, 2010
  50. 50. Traditional Feedback code feedback developer user manager How fast is your loop? Days? Weeks? Monday, October 18, 2010
  51. 51. Communication OD Central HubMess Media? ? ? ? ? ? ? ?? oral tradition? permanent record or Monday, October 18, 2010
  52. 52. Real-time updates Collaboration hub! code issues tests decisions RSS feeds email events subscriptions Monday, October 18, 2010
  53. 53. Real-time updates Source code control system instead of “code on the fileserver”. Issue tracker events instead of “what did you do today”? Mailing list “events” instead of “yell around the office”. Automated builds instead of “wait for Bob to build it on Linux”. Monday, October 18, 2010
  54. 54. Effective Collaboration ✴ (One) Shared Goal ✴ Agree how to disagree & decide ✴ Shared Workspace ✴ Dynamic Awareness ✴ Parallelization Monday, October 18, 2010
  55. 55. alexkli, angela, dpfister, fielding [*], fmeschbe, jukka, mreutegg, ppiegaze, stefan, tripod, uncled bdelacretaz [*], cziegeler, fmeschbe [*] member of the Board of Directors Committers, PMC members and mentors on these projects, and others Monday, October 18, 2010
  56. 56. What does Day get? Industry recognition (+ JSR-170) Credibility with world-class people The Open Development Way of Working (works inside the company as well) Contacts. Networks. Ideas. Great infrastructure software, Many eyeballs. Monday, October 18, 2010
  57. 57. OPEN SOURCE 57 dev@httpd.apache.org dev@jackrabbit.apache.org dev@sling.apache.org dev@felix.apache.org Monday, October 18, 2010

×