1 April 14, Starting New Open Source Software Projects William Cohen NCSU CSC 591W April 14, 2008

2 2 Outline ● Software Creation ● Existing Open Source Software ● Audiences for Software ● Transforming software into an Open Source Project

3 April 14, Software Creation ● Many Open Source Software projects originally developed to address personal or institutional need ● Goal is to solve problem (not sell a software product) ● People working on the software closely connected to people using software: ● Same person developing and using the software ● People in the same organization ● Tight feedback helps to make the software good

4 April 14, Existing Software Projects ● Why start from scratch? ● Look for existing projects: ● May already have much of the work implemented ● Easier to add desired functionality ● Already have existing community ● Use search engines ● Places to look: ● Fresh Meat, ● Source forge, ● Free Software Foundationhttp://directory.fsf.org/

5 April 14, Users and Developers ● Two distinct audiences: ● Users – people wanting to use the software ● Developers – people interested in working on or enhancing the software ● Keep audience in mind when writing documentation: ● Users do not care about the internal details of the software ● Make it clear what audience the documentation is for, e.g. label clearly ● With open source software users can potentially become developers

6 April 14, Transformation to Open Source Code ● May already have existing code to transform to opensource, e.g. Mozilla project ● Reviews and Audits: ● Ownership of the source code (no licensed third-party code) ● No confidential information (e.g. customer info in bug tracking system) ● Reduce the barriers to build, install, and use: ● Documentation ● Source code organization

7 April 14, Minimizing Barriers to Entry ● Try to make it as easy as possible for people to: ● Find the project ● Download the project ● Build and install the project ● Develop on the project ● The higher the barriers the fewer users and contributions from potential developers

8 April 14, Naming Project ● Naming important ● Need to have name that clearly identifies project: ● Example problem name, PAPERS (Purdue's Adapter for Parallel Execution and Rapid Synchronization) ● Want to have the give people some idea what the project does ● Generally stick to English ● Avoid infringing on trademarks: ● Minimize confusion and possible legal issues ● Check and get.com.net and.org top-level domain name for project

9 April 14, Mission Statement ● Short blurb that allow people to decide whether the project is for them ● Example mission statement from OpenOffice: To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format.

10 April 14, Project Licensing ● Make it clear what software license is being used ● Do not assume that people will dig for that information ● Put licensing information on front page for project ● See about using an existing license rather than creating a new one: ● Many existing license work well ● A new license can increase barrier to entry (people have to review new license)

11 April 14, Features and Requirements ● What does the software do that people would care about? ● Avoid frustrating users, set expectation on environment: ● List what hardware is needed to run the software (e.g. only works on x86 machines or particular video cards) ● List what software is needed to build and run the software

12 April 14, Development Status ● Give people an idea of how things are progressing on the project: ● List historical information on previous releases ● TODO lists things that remain to be done

13 April 14, Download ● Make it easy for users to get a copy of the source: ● Link to down load current release (or snapshot) ● Have download in standard formats (e.g. tar or zip) ● Standardize build of the software

14 April 14, Version Control ● Want to make sure that revision control system is available anyone ● Default read only access is sufficient ● Reduce the barrier to entry for people trying their hand at development on the code ● Potential developers need access to the latest copy ● Users may want to see if a bug is already fixed

15 April 14, Bug Tracking System ● Make it easy for people to report and search for problems on the software ● Having a bug tracking system sign that project a bit more serious

16 April 14, Communication ● Want to hear from people using the software ● List contact info on front page: ● Mail lists ● IRC

17 April 14, Documentation ● Make it possible to view documentation without downloading the software ● Keep in mind the audience for the document (user or developer) ● Keep the documentation concise and easily searched ● Write documentation in stages: ● Start with quick installation and tutorial guide ● Expand into more detailed topic, e.g. software internals ● Label incomplete areas (maybe someone will expand them) ● FAQ (Frequently Asked Questions)

18 April 14, Example Output and Screen Shots ● A picture is worth a thousand words. ● Sometime easiest to have actually output from software in documentation

19 April 14, Developer Guidelines ● People may want to contribute to the project ● Make it easy for them to understand the process to contribute ● Describe process of getting patches into the project ● Where to contact people for technical questions

20 April 14, Developer Documentation ● “Use the source, Luke.” ● Can release code without developer documentation ● Often people ask others on IRC or about software internals

21 April 14, Further Reading ● ●