Best Practices in Starting an Open Source Project for Companies
Download as PPTX, PDF0 likes271 views
The document outlines best practices for companies looking to start open source projects, emphasizing the importance of financial sponsorship, community interest, and proper governance. It discusses both good and bad reasons for initiating such projects, as well as considerations for code quality, licensing, and sustainability. Additionally, it highlights the project lifecycle and available resources to aid organizations in adopting open source methodologies.
Best Practices in Starting an Open Source Project for Companies
- 1. Best Practices in Starting an Open Source Project for Companies John Mertic Director of Program Management
- 2. Who am I? 4/23/201 8 2 › John Mertic ( @jmertic ) › Former PHP developer/community member › Author of PHP Windows Installer › Former SugarCRM Community Manager and Software Engineer › Former Bitnami BD leader › Current Director for ODPi, Open Mainframe, and R Consortium at Linux Foundation. › And I come from Ohio.
- 5. So you work for a company wanting to start an open source project… 54/23/2018
- 6. Why would you even want to do this? › Accelerate an open solution; provide a reference implementation to a standard; share development costs for strategic functions › Commoditize a market; reduce prices of non-strategic software components. › Drive demand by building an ecosystem for your products. › Partner with others; engage customers; strengthen relationships with common goals. › Offer your customers the ability to self-support: the ability to adapt your code without waiting for you. Source: Ibrahim Haddad 64/23/2018
- 7. Bad reasons for starting an open source project › Finding a home for old product/code › Freemium/entry-level product (often referred to as “Open Core”) › Get free labor › Want to get my company associated with open source ( and we’ve never even contributed before ) 74/23/2018
- 8. OK – so you still want to do this… 84/23/2018
- 10. Stages of Open Source engageme nt for companies (credit to Ibrahim Haddad - https://www.linke din.com/feed/upd ate/urn:li:activity: 6388821398688 796672/ ) 4/23/2018 10
- 12. Core vs Commodity 4/23/2018 12
- 13. What kinds of code are good to open source › Internal tooling › Development libraries › Application frameworks 134/23/2018
- 15. Questions to Ask Before Starting an Open Source Project › Can we financially sponsor the project? Do we have an internal executive champion? › Is it possible to join efforts with an existing open source project? › Can we launch and maintain the project using the OSS model? › What constitutes success? How do we measure it? › Will the project be able to attract outside enterprise participation (from the start)? › Is there enough external interest to form and grow a developer community? 154/23/2018 Source: Ibrahim Haddad
- 17. Steps › Identify code to seed to the project › Build the business case › Allocate resources to maintain 174/23/2018
- 18. “Perfect is the enemy of good” › You don’t need to have perfect code to release it in open source › But you should have… › Complete code › At least some tests › Getting started documentation › Legal clearances › Clear open source license 184/23/2018
- 19. Seriously, please choose a license … or it’s not FOSS And please use an OSI-approved license https://opensource.org
- 20. Hosting your project DIY vs Foundation 204/23/2018
- 21. Sustainable collaboration requires real work GOVERNANCE AND MEMBERSHIP DEVELOPMENT PROCESS INFRASTRUCTURE ECOSYSTEM DEVELOPMENT IP MANAGEMENT o Incorporation, Tax status, Bylaws, Member Agreements, Anti-trust, etc. o Ongoing business development and membership recruitment o Technical Decision Making Framework o Project Life Cycle o Release Process o Custom infrastructure using open source best practices o Security and reliability o Marketing o Events o Training o Code Provenance, license management o Trademark management o Legal defense and Collaboration
- 22. IP Management › Successful communities often have a neutral IP owner for trademarks, neutral governance of control › If it’s perceived as “just one company in control, that can be an inhibitor to adoption › Successful FOSS projects protect their IP, defend their trademark, use issues as opportunities to draw adopters in › If the first introduction is a trademark cease and desist to the company’s lawyers, good luck getting them to contribute › Good housekeeping is important – companies will scan your code, what will they find? › Enforce license headers, use SPDX license identifiers, scan your code too (try FOSSology) › What get’s pulled in at build time?
- 23. Poor IP management is easy to spot…
- 24. The Developer Certificate of Origin v1.1 The DCO captures code provenance at time of submitting a pull request, on every contribution. The Linux Foundation worked with GitHub to make it easy to implement “DCO required” in any project. https://github.com/apps/dco
- 25. Ready for launch! 254/23/2018 The Linux Foundation Internal
- 26. Final checklist › Legal review › Technical review › Governance and technical processes › Infrastructure 264/23/2018
- 27. The other important things people forget › Communication tools › Both internal and public › Marketing › Branding › Website › Social › Collateral assets › Community building › Advocates › Meetups › Events 274/23/2018
- 29. Products have a lifecycle INVESTMENT TIME Invest Reap rewards
- 30. Open Source Projects also follow a life cycle INVESTMENT TIME
- 31. Projects lifecycles often map to commercial lifecycles INVESTMENT TIME LAUNCH COMMERCIALIZATION MAINTAIN SUSTAIN…
- 32. Project needs change in each lifecycle stage INVESTMENT TIME LAUNCH COMMERCIALIZATION MAINTAIN SUSTAIN… • Be visible • Release code • Show momentum • Attract user interest • Add contributors • Create brand
- 33. Project needs change in each lifecycle stage INVESTMENT TIME LAUNCH COMMERCIALIZATION MAINTAIN SUSTAIN… • Products using code • Production users • Diverse contributor base • Stable release cadence • Organization, stability • Rate of new features slows • Conformance, interoperability
- 34. Project needs change in each lifecycle stage INVESTMENT TIME LAUNCH COMMERCIALIZATION MAINTAIN SUSTAIN… • Established community • Established products • Conformance program • Interdependency w/other projects • Long term support releases • Stable security policy • Bug tracking drives priorities
- 35. Project needs change in each lifecycle stage INVESTMENT TIME LAUNCH COMMERCIALIZATION MAINTAIN SUSTAIN… • Retain commercial contributions, support • Provide long term home • Availability, security updates, notices
- 36. Whew! That seems like a lot Fortunately, there’s help out there 364/23/2018
- 37. Open Source Guides For The Enterprise › Developed in collaboration with TODO Group › Leverage best practices to run or start an open source project within your organization › Topics include: › Creating an Open Source Program Tools for Managing Open Source Programs › Measuring Your Open Source Program’s Success https://www.linuxfoundation.org/resources/open-source-guides
- 38. Learn and adopt security best practices https://github.com/google/oss-fuz
- 40. Get a CII Best Practices Badge › Initiative launched in May 2016 to raise awareness of development and governance steps for better security outcomes › The badge makes it easier for users of open source projects to see which projects take security seriously › Not a “rubber stamp” process › 1,000 projects registered for the badge › While only 10% of the projects successfully passed, every one of them made an improvement to achieve a badge https://www.coreinfrastructure.org
- 41. Software Package Data Exchange® (SPDX®) › Standard: › A standard format for communicating the components, licenses and copyrights associated with a software package. › Key pillar in Linux Foundation’s Open Compliance Program › SPDX Group: › Workgroup of Linux Foundation › Participation from over 20 organizations including software, systems and tool vendors, consultants and foundations › Vision: › To help reduce redundant work in determining software license information and facilitate compliance › Learn more at https://spdx.org 41
- 43. Contact Us 4/23/2018 43 The Linux Foundation 1 Letterman Drive Building D, Suite D4700 San Francisco CA 94129 Phone/Fax: +1 415 7239709 www.linuxfoundation.org General Inquiries [email protected] Membership [email protected] Corporate Training [email protected] Event Sponsorship [email protected]
- 44. Legal Notices › The Linux Foundation, The Linux Foundation logos, and other marks that may be used herein are owned by The Linux Foundation or its affiliated entities, and are subject to The Linux Foundation’s Trademark Usage Policy at https://www.linuxfoundation.org/trademark-usage, as may be modified from time to time. › Linux is a registered trademark of Linus Torvalds. Please see the Linux Mark Institute’s trademark usage page at https://lmi.linuxfoundation.org for details regarding use of this trademark. › Some marks that may be used herein are owned by projects operating as separately incorporated entities managed by The Linux Foundation, and have their own trademarks, policies and usage guidelines. › TWITTER, TWEET, RETWEET and the Twitter logo are trademarks of Twitter, Inc. or its affiliates. › Facebook and the “f” logo are trademarks of Facebook or its affiliates. › LinkedIn, the LinkedIn logo, the IN logo and InMail are registered trademarks or trademarks of LinkedIn Corporation and its affiliates in the United States and/or other countries. › YouTube and the YouTube icon are trademarks of YouTube or its affiliates. › All other trademarks are the property of their respective owners. Use of such marks herein does not represent affiliation with or authorization, sponsorship or approval by such owners unless otherwise expressly specified. › The Linux Foundation is subject to other policies, including without limitation its Privacy Policy at https://www.linuxfoundation.org/privacy and its Antitrust Policy at https://www.linuxfoundation.org/antitrust-policy. each as may be modified from time to time. More information about The Linux Foundation’s policies is available at https://www.linuxfoundation.org. › Please email [email protected] with any questions about The Linux Foundation’s policies or the notices set forth on this slide. 4/23/2018 The Linux Foundation Internal 44