1

Open Source – åpen kildekode

Understanding an open source project

2

The anatomy of an open source project

• Mission / goal

• Participants

• Discussions /mailing lists

• Documentation

• Downloads

• Bug tracking

• CVS access

= SourceForge

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

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

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

What does this requirefrom 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?