How to start an Open Source Project
48 likes9,073 views
This document provides guidance on starting an open source project. It outlines common pitfalls like underestimating resources and having an unclear vision. The key first steps are to learn from other projects, define goals and build a community. Successful projects have active management, coordination of tasks, and processes for decision making and releases. While many are volunteer efforts, large projects often rely on funding and paid contributors to coordinate activities. Managing volunteers is challenging and requires finding roles that motivate contributors.
![Contact information Anthony I. (Tony) Wasserman post: Carnegie Mellon West Moffett Field, CA 94035 USA tel: +1.415.641.1180 (ofc) +1.415.612.0600 (m) email: [email_address] Skype: tony.wasserman AIM, YIM: twasserman Googletalk: tony.wasserman](https://image.slidesharecdn.com/how-to-start-an-open-source-project-257/85/How-to-start-an-Open-Source-Project-13-320.jpg)
How to start an Open Source Project
- 1. How to Start an Open Source Project Tony Wasserman Carnegie Mellon West Gnunify'07 Pune, January, 2007
- 2. Open Source is Everywhere (even on Windows ™ ) Infrastructure Web server, application server, DBMS, content management systems, web browsers, email servers and clients, portal development, collaboration tools, operating system Application development Modeling, compilers, development environments, testing, issue tracking, version control, configuration management, project management, installers Applications Finance, CRM, SFA, vertical apps, image management, drawing, audio/video But you were looking for something else, and didn't find it.
- 3. Lesson One New open source projects are similar to commercial startups. The most important step in starting a new project is to avoid making any fatal errors.
- 4. Typical fatal errors Underestimating people, time, money needed Wrong people Unclear goals and objectives No previous management experience Focus on code only Failure to build community The major problems are not technical!
- 5. First steps Learn from others Join and contribute to one or more projects Meet and communicate with other project leaders Search carefully for similar projects Develop your leadership and communication skills Define your vision and goals Build support for your project Find people who share your vision and goals Look for sponsors Develop basic rules for project management Decision-making process Key roles
- 6. Getting underway Select project repository, e.g., SourceForge Create, refine, and review software architecture Define some milestones for release(s) Start to build a community Word of mouth Postings on discussion boards Everyone is a “salesman” for the project Develop some project management processes Awarding committer status Version and configuration management Build processes Issue tracking and followup
- 7. The Myths of Community Open Source Software is produced by a geographically distributed group of highly motivated volunteers who contribute their time freely, expecting only recognition for their work in return Large projects can be built and maintained through the efforts of a small group of project leaders and committers
- 8. The Reality of Community Open Source Virtually all of the large, successful community open source projects rely on industrial sponsors and/or government funding The majority of people working on these projects are paid to do so Large projects have community managers who coordinate efforts, attract contributors, promote project use, interact with other projects, and monitor discussion forums There is active management of the projects
- 9. Summary: key management issues What will the planned system do? Who will do the various tasks? Architecture, implementation, testing, documentation, etc. What are the development milestones? What is the development and release schedule? How is quality of the release assured? How will the software be supported and augmented over time? Who is responsible for coordination among contributors? How are decisions made? What's the process for changing them?
- 10. Community open source projects No explicit business or revenue goals Many are volunteer efforts; others are backed by companies that pay their employees to work on projects Wide variation in governance, management styles, centralized vs. decentralized communication and management Focus on community development for testing, mutual support (discussion boards) , generating awareness Volunteers work in their available time, but only on things that interest them It's hard to manage volunteers!
- 11. Managing volunteers Finding the right roles for people, e.g., coding vs. writing vs. testing Attracting and retaining valuable contributors, while discouraging weak ones Encouraging volunteers to work on those tasks most valuable to the overall project Finding ways to reward people for their work Coordinating activities of paid project members with those of volunteers
- 12. In Conclusion Keep your eyes on your vision and goals Don't be afraid to take measured risks Good luck!
- 13. Contact information Anthony I. (Tony) Wasserman post: Carnegie Mellon West Moffett Field, CA 94035 USA tel: +1.415.641.1180 (ofc) +1.415.612.0600 (m) email: [email_address] Skype: tony.wasserman AIM, YIM: twasserman Googletalk: tony.wasserman