Running a Successful Open Source Project
summary
If the goal is adoption rather than a private repo, pick an OSI‑approved license early, require a contributor agreement or developer certificate of origin, and track provenance with SPDX identifiers so relicensing and audits are possible. Use scanners like Fossology, provide a CONTRIBUTING file, limit patch size (few hundred lines), and supply IDE metadata (Eclipse Che/Oomph) so newcomers can build and test. Foundations hold trademarks and manage IP to prevent vendor takeover.
AI-written summary · about
chapters (29)
- 0:00Introduction
- 0:26Wayne Beaton
- 1:12What is success
- 2:02What is open source
- 6:24Roles of open source
- 8:43Community
- 9:32Governance
- 11:07The Community
- 11:24User Help
- 12:23Transparency Openness
- 14:20Conferences
- 14:35Contributions
- 14:49How to deal with contributions
- 16:15Choosing a license
- 19:45Managing copyright
- 23:41Establish guides in convention
- 26:48Keep patches focused
- 27:56Tracking intellectual property
- 31:44Thirdparty dependencies
- 32:35Intellectual property
- 35:07Public record
- 36:01Trademarks
- 39:55Diversity
- 42:01Questions
- 42:54Warranty vs IP
- 44:23Risk Mitigation
- 45:45Computer Agreement
- 47:03Committee Agreement
- 48:13Eclipse Foundation
related talks
31mOperationalizing Open Source Projects: When the Rubber Meets the Road
48mAnatomy of an Open Source Project
55mOpen source is just about the source, isn't it?
40mBoF: Positioning Your Next Open Source or Standard Project for Success
40mHow to Open Source a Project and Possibly Not Fail While Trying
55mRunning an open source project like a professional
25mWhat Makes Open Source Work: Licensing and Beyond
23mGrowing A Successful and Sustainable Project