Your SlideShare is downloading. ×
How to start an Open Source Project
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

How to start an Open Source Project


Published on

How to start an Open Source Project

How to start an Open Source Project

Published in: Technology

    Are you sure you want to  Yes  No
    Your message goes here
  • عقار
    Are you sure you want to  Yes  No
    Your message goes here
  • Thanks for your work, it is a good starting point for beginners.
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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