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

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

3. 3 April 14, 2008 3 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. 4 April 14, 2008 4 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, http://freshmeat.net/http://freshmeat.net/ ● Source forge, http://www.sourceforge.net/http://www.sourceforge.net/ ● Free Software Foundationhttp://directory.fsf.org/http://directory.fsf.org/

5. 5 April 14, 2008 5 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. 6 April 14, 2008 6 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. 7 April 14, 2008 7 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. 8 April 14, 2008 8 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. 9 April 14, 2008 9 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. 10 April 14, 2008 10 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. 11 April 14, 2008 11 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. 12 April 14, 2008 12 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. 13 April 14, 2008 13 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. 14 April 14, 2008 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. 15 April 14, 2008 15 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. 16 April 14, 2008 16 Communication ● Want to hear from people using the software ● List contact info on front page: ● Mail lists ● IRC

17. 17 April 14, 2008 17 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. 18 April 14, 2008 18 Example Output and Screen Shots ● A picture is worth a thousand words. ● Sometime easiest to have actually output from software in documentation

19. 19 April 14, 2008 19 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. 20 April 14, 2008 20 Developer Documentation ● “Use the source, Luke.” ● Can release code without developer documentation ● Often people ask others on IRC or email about software internals

21. 21 April 14, 2008 21 Further Reading ● http://producingoss.com/ http://producingoss.com/ ● http://www.catb.org/~esr/writings/cathedral-bazaar/ http://www.catb.org/~esr/writings/cathedral-bazaar/