1. 1 Open Source – åpen kildekode Understanding an open source project

2. 2 The anatomy of an open source project Mission / goal Participants Discussions / mailing lists Documentation Downloads Bug tracking CVS access =SourceForge

3. 3 Open Source projects JDOM – Java representation of XML documents Jaxen – Java implementation of XPath integrated with JDOM Rhino – Javascript engine for Java Jabber – Server for XML based messaging incl. Instant Messaging and Presence MUSE – Java API for Jabber client programming JGraph – Java API for direct manipulation diagram editors LispMe – Scheme/Lisp implementation for PalmOS xmllib – XML parser for PalmOS

4. 4 How to judge / evaluate projects? How is confidence created? –open source, tolerant (although demanding) dialog Functionality –mission statements, demos, tutorials, documentation –downloadable code and binary versions Architecture –explicit structure and implicit assumptions –standard compliance, API usage and relations to other projects Quality measures –explicit goals and implicit values, e.g. maintainability Project management –accessible status and predictable timeline

5. 5 Classification of projects Dugnadsgjengen (JDOM og Jabber) –small core of developers managing the code base –common interests and values Hobbyisten (Jaxen, Jgraph, LispMe, xmllib) –single person project given to the community –originator controls development –attracts other interested programmers as contributors Charity (Jabber, MUSE) –company opens up core technology / platform upon which value is added –asks for contributions from others (ideas, bug fixes, code) Consortium (GNU’s Rhino, Mozilla, Apache, etc) –organisation initiates and manages project –large-scale development with many contributors

6. 6 Characterization of JDOM – www.jdom.org Product maturity: –A series of betas (0.7, 0.8) have been delivered, 1.0 is coming soon –Specification has been stable, current download works well Market Share –Used by a large number of open source and commercial projects –Is on track for becomming a Java ”standard” API Scalability –Does not handle large documents very well Safety/security –No support for security –Focusses on standard compliance (no shooting in the foot) Reliability –Many surprised users when manipulating live XML data

7. 7 Characterization of JDOM, cont’d Product support –Source and binary distributions –CVS access –Discussion forum / mailing list, including archives Documentation –JavaDoc API documentation and FAQ –Articles, talks and (online) book chapters –Discussion forum / mailing list archives Usability –Good error reporting Modifiability –Simple and easy to understand design (e.g. compared to DOM) –Examples: IdDocument, NotifyingDocument and RhinoDocument

8. 8 Characterization of JDOM, cont’d Hardware/software requirements –Runs on Java 1.1, 1.2 and 1.3 (should run on 1.4) Change frequency –2 beta-releases this year License type –Apache-style open source license, acknowledgment clause removed –”among the least restrictive license available” Cost –Free Standard conformance –Strives to be completely XML 1.0 compliant Classification –client/server(/data), executable (source and binary), runtime library

9. 9 Steps in usage and participation Read, listen, learn –Understand content, scope and state of project –Download, test and use products –Build own code on top of product, based on API documentation –Read and understand open source code Participate and contribute –Modify open source code for own purpose –Participate in discussions –Fix bugs and contribute fixes –Develop and contribute own modules –Become ”worthy” member of core development team Initiate –Initiate own project, e.g. hosted by sourceforge.net

10. 10 What does this require from us and our students? We have to be able to read and write code –reading is actually more difficult than writing –documenting is more difficult than reading We have to have knowledge of architecture –architecture is more difficult to change than functionality –less explicitly expressed –required for integration We have to have experience in team design and coding –basic experience with version control (CVS) –to understand ”hacker” dialog Do we meet these requirements ourselves? Do we teach to help our students meet them?