├── LICENSE ├── README.md ├── building-leadership-in-an-open-source-community.md ├── casestudies ├── README.md ├── autodesk.md ├── capitalone.md ├── comcast.md ├── dropbox.md ├── facebook.md ├── images │ ├── capitalone1.jpg │ ├── capitalone2.jpg │ ├── capitalone3.jpg │ ├── comcast1.jpg │ └── comcast2.jpg ├── microsoft.md ├── oath.md ├── redhat.md └── salesforce.md ├── creating-an-open-source-program.md ├── images ├── building-leadership-in-an-open-source-community1.png ├── building-leadership-in-an-open-source-community2.png ├── building-leadership-in-an-open-source-community3.jpg ├── building-leadership-in-an-open-source-community4.png ├── building-leadership-in-an-open-source-community5.jpg ├── building-leadership-in-an-open-source-community6.jpg ├── creating-an-open-source-program1.png ├── improve-open-source-dev-impact1.png ├── improve-open-source-dev-impact2.png ├── improve-open-source-dev-impact3.png ├── improve-open-source-dev-impact4.png ├── improve-open-source-dev-impact5.png ├── improve-open-source-dev-impact6.png ├── improve-open-source-dev-impact7.png ├── measuring-your-open-source-program1.png ├── measuring-your-open-source-program2.png ├── measuring-your-open-source-program3.png ├── measuring-your-open-source-program4.png ├── open-source-reading-list1.jpg ├── open-source-reading-list10.jpg ├── open-source-reading-list11.jpg ├── open-source-reading-list12.jpg ├── open-source-reading-list13.jpg ├── open-source-reading-list14.jpg ├── open-source-reading-list15.jpg ├── open-source-reading-list16.jpg ├── open-source-reading-list18.jpg ├── open-source-reading-list19.jpg ├── open-source-reading-list2.jpg ├── open-source-reading-list20.jpg ├── open-source-reading-list3.jpg ├── open-source-reading-list4.jpg ├── open-source-reading-list5.jpg ├── open-source-reading-list6.jpg ├── open-source-reading-list7.jpg ├── open-source-reading-list8.jpg ├── open-source-reading-list9.jpg ├── starting-an-open-source-project1.jpg ├── starting-an-open-source-project2.jpg ├── starting-an-open-source-project3.jpg ├── tools-for-managing-open-source-programs1.png ├── tools-for-managing-open-source-programs2.png ├── tools-for-managing-open-source-programs3.png ├── tools-for-managing-open-source-programs4.png └── tools-for-managing-open-source-programs5.png ├── improve-open-source-dev-impact.md ├── measuring-your-open-source-program.md ├── open-source-reading-list.md ├── participating-in-open-source.md ├── recruiting-developers.md ├── shutting-down-an-open-source-project.md ├── starting-an-open-source-project.md ├── tools-for-managing-open-source-programs.md └── using-open-source.md /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | 307 | including for purposes of Section 3(b); and 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public 411 | licenses. Notwithstanding, Creative Commons may elect to apply one of 412 | its public licenses to material it publishes and in those instances 413 | will be considered the “Licensor.” The text of the Creative Commons 414 | public licenses is dedicated to the public domain under the CC0 Public 415 | Domain Dedication. Except for the limited purpose of indicating that 416 | material is shared under a Creative Commons public license or as 417 | otherwise permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the 425 | public licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. 428 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | --- 2 | # THIS REPO IS ARCHIVED. CONTENT IS BEING MAINTAINED [HERE](https://github.com/todogroup/todogroup.github.io/blob/master/content/en/guides/) 3 | --- 4 | 5 | # TODO Guides 6 | 7 | These Open Source Guides are developed by the TODO Group in collaboration with The Linux Foundation and the larger open source community. They collect best practices from the leading companies engaged in open source development, and aim to help your organization successfully implement and run an open source program office. We expect these guides to be living documents that evolve via community contributions. 8 | 9 | For guides tailored to individual contributors, we recommend GitHub’s [community guides](https://github.com/github/opensource.guide). 10 | 11 | ## Open Source Guides 12 | 13 | To build a successful open source program, start here: 14 | 15 | * [How to Create an Open Source Program](creating-an-open-source-program.md) 16 | * [Measuring Your Open Source Program](measuring-your-open-source-program.md) 17 | * [Tools for Measuring Your Open Source Program](tools-for-managing-open-source-programs.md) 18 | 19 | For open source program management best practices: 20 | 21 | * [Using Open Source Code](using-open-source.md) 22 | * [Participating in Open Source Communities](participating-in-open-source.md) 23 | * [Recruiting Open Source Developers](recruiting-developers.md) 24 | * [Starting an Open Source Project](starting-an-open-source-project.md) 25 | * [Open Source Reading List](open-source-reading-list.md) 26 | * [Improve Your Open Source Development Impact](improve-open-source-dev-impact.md) 27 | * [Shutting Down an Open Source Project](shutting-down-an-open-source-project.md) 28 | * [Building Leadership in an Open Source Community](building-leadership-in-an-open-source-community.md) 29 | 30 | ## Open Source Program Case Studies 31 | 32 | * [Autodesk](casestudies/autodesk.md) 33 | * [Capital One](casestudies/capitalone.md) 34 | * [Comcast](casestudies/comcast.md) 35 | * [Dropbox](casestudies/dropbox.md) 36 | * [Facebook](casestudies/facebook.md) 37 | * [Microsoft](casestudies/microsoft.md) 38 | * [Oath](casestudies/oath.md) 39 | * [RedHat](casestudies/redhat.md) 40 | * [Salesforce](casestudies/salesforce.md) 41 | 42 | If your open source program would like to add a case study, please send a pull request! 43 | 44 | ## License 45 | 46 | All content is licensed under [CC-BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). 47 | -------------------------------------------------------------------------------- /building-leadership-in-an-open-source-community.md: -------------------------------------------------------------------------------- 1 | # Building Leadership in an Open Source Community 2 | 3 | Integrating into open source communities takes time and effort and requires a new approach to product development. Where traditional, proprietary development requires secrecy and a management hierarchy, open source development requires openness and values consensus. Code contributions, not title or position, are what determine influence and technical direction in an open source project. 4 | 5 | Open source projects are developed in diverse and geographically dispersed communities that have their own rules, conventions, tools, and processes. Simply put, each community has its own unique culture and it takes time to establish the trust, ways of collaborating, and cultural understanding required to be effective in open source. 6 | 7 | This guide explains how organizations can build leadership and influence within the open source projects they’re involved in and on which they are commercially dependent. Learn about leadership culture and roles within a project, how decisions are made, how an organization can build leadership, and tips for being a good leader in open source communities. 8 | 9 | ## Why build leadership in an open source project 10 | 11 | Although the open source culture is collaborative, contributing upstream is only the first step in shaping an open source project’s progression. Taking an active role in guiding or influencing the project’s direction is also important if the project is critical to your company’s own products. 12 | 13 | While open source projects have repeatedly proved the value of collaborations that even – and maybe especially – include competitors, having no say in a project’s direction can quickly prove to be a competitive disadvantage. And this is why building and maintaining leadership in open source projects is key to corporate strategies and goals. However, it isn’t as easy as pounding desks and throwing around cash-based clout. 14 | 15 | ## Leadership culture in open source 16 | 17 | It is common for companies to first assume that leadership in an open source community works the same way as leadership does in a corporation. It doesn’t. 18 | 19 | “Companies often go through a phase of thinking ‘Oh, well, we’re huge. Why can’t we pound our fist on the table and just make the community do what we want?’” explains [Guy Martin](https://www.linkedin.com/in/guywmartin/), Director of the Open@ADSK initiative at Autodesk. “They soon come to realize that tactic won’t work. They come to understand that the only way to gain leadership is to earn the role within the community. And the only way to do that is to gain credibility and make contributions.” 20 | 21 | ![Source: Ibrahim Haddad, http://www.ibrahimatlinux.com/charts.html](images/building-leadership-in-an-open-source-community1.png) 22 | 23 | ## Corporate vs open source leadership 24 | 25 | While gaining leadership in an open source project can be vital to a company’s own success in the commercial world, taking on such a radically new approach to product development is often counterintuitive and sometimes awkward in the beginning. 26 | 27 | Traditional, proprietary development requires secrecy and a management hierarchy. By contrast, titles and positions are meaningless in open source development, which instead puts a premium on openness and consensus. 28 | 29 | Code contributions are what determine influence and technical direction in an open source project. That means no fudging on code contributions; they must be substantial and truly advance the project in some way. 30 | 31 | At first, making upstream contributions and openly collaborating can feel like giving away the store. But that feeling is not based in the open source reality; instead, it is a twinge of apprehension commonly associated with making a significant change in thinking and actions that is so very necessary to innovating. 32 | 33 | The open source leadership mindset involves thinking about: 34 | 35 | * Influence, not control 36 | * Transparency as a means of crowd-sourcing solutions, not as exposure 37 | * Leading, not herding 38 | 39 | Successfully making the shift from a proprietary to an open source mindset and culture requires time and effort and sometimes a regular reminder of the benefits in doing so. [Ibrahim Haddad](https://www.linkedin.com/in/ibrahimhaddad/), vice president of R&D and Head of Open Source at Samsung Electronics, built this chart for ease of reference. 40 | 41 | ![Source: Ibrahim Haddad, http://www.ibrahimatlinux.com/charts.html](images/building-leadership-in-an-open-source-community2.png) 42 | 43 | ## Governance overview 44 | 45 | Governance guidelines in open source communities tend to be few but they are nonetheless rigidly enforced. The code of conduct or community guidelines are unique to the community but generally address acceptable and expected behavior and the procedures for handling unacceptable behavior or other incidents. A governance policy details the management of the open source project’s policies, structures and roadmap. A maintenance policy typically addresses other project decisions such as software updates. 46 | 47 | But governance at and surrounding the project and community level does not represent the entirety of governance policies and issues. Those also exist at the points where open source software is consumed, contributed to, redistributed and/or produced by commercial interests or other organizations. Therefore, open source governance is by necessity part of the broader IT governance effort. 48 | 49 | Companies tend to experience similar issues, such as multiple processes for how open source is consumed, inconsistent ways of contributing upstream in communities, and variances in how open source projects are created internally. Developing a standardized set of governance is key to taming the chaos. 50 | 51 | “We aimed for one single process for contributing upstream and as an engineer I wanted it streamlined,” Martin said. “I didn’t want a ten-week process with 500 pages of documentation for a five-line bug fix, so I worked with legal to streamline the workflow so an engineer could accomplish it in a reasonable amount of time. And then we did the same thing for creation of opensource projects from code that’s in the company.” 52 | 53 | It’s best for each company to work out the particulars in its own open source governance policies and processes so that it best fits how their company actually works; in effect mirroring how governance is best done at the community level. But be aware that you may not be able to repeat a single process for all open source activities in your company. 54 | 55 | A consistent governance plan prevents a huge version skew, as well as open source license and security issues. “A consistent governance model for open source consumption helps ensure compliance so that when we ship something, we know we’ve got the right license compliance in place.” 56 | 57 | ![Source: Ibrahim Haddad, http://www.ibrahimatlinux.com/charts.html](images/building-leadership-in-an-open-source-community3.jpg) 58 | 59 | ## Culture overview 60 | 61 | While there is a pressing need to shift an organization’s internal culture to an open source state of mind, such must be accomplished without losing sight of, or disconnecting from, the open source community outside of the company walls. 62 | 63 | “In order to develop influence on an open source project, you have to get a group of people whom you don’t know, who work for different companies, and may have different objectives to agree with you,” explains [Gil Yehuda](https://www.linkedin.com/in/gilyehuda/), senior director of open source at Oath (Yahoo+AOL). 64 | 65 | That’s often easier said than done, since disputes and pushbacks are common and resolutions can take one of many directions depending on community consensus. 66 | 67 | “In an open source community, you have people who work for different companies who may have lots of areas of shared purpose and shared outcome and some areas of contention and cross purposes,” explains Yehuda. 68 | 69 | For example, there may be one set of developers who want new functionality because they need it to make something work, but another group that doesn’t want that new functionality because they want stability. 70 | 71 | “Perhaps the new functionality compromises the stability or the scalability. There’s going to be a fight or at least some tension over that,” explains Yehuda. 72 | 73 | Resolving the issue so that the project proceeds in one direction or the other is no small feat considering that no one person is in charge of making the decision. Instead, it’s a communal decision. 74 | 75 | “One of the things that can help the community arrive at what you would consider favorable resolution is if you have more influence in the project,” says Yehuda. “They’re going to support you even in a decision that might have small short term negative impact to them if you have leadership and you’re a trusted member of the community, and you have the community’s interest at heart.” 76 | 77 | But building that leadership and maintaining it is as much a company mission as it is an individual developer’s goal. 78 | 79 | Oath’s approach is to instruct its developers to involve company assistance when they see situations that could potentially be contentious. 80 | 81 | “We have active consulting, we have internal conversations about situations and how to best approach them, we have developers that share anecdotes with each other about situations and how they can resolve them,” says Yehuda. 82 | 83 | It’s also important to understand that leadership rests with the person, not the company. So even though the individual developer has the backing and assistance of his or her employer, that employer is at risk of losing influence if that developer chooses to leave. 84 | 85 | “If you’ve got an open source project that is super critical to your product and you’ve only got one person from your company making upstream contributions, you have a single point of failure,” explained Martin. “You have to a succession plan in place and it needs to include more than couple of people at your company.” 86 | 87 | That means multiple people in your company will be making upstream contributions. A common first reaction to that idea is fear of tying up too many human resources on an open source project that other companies will benefit from. But that’s not the case if you organize their time well. 88 | 89 | “It’s more palatable to engineering management when less of Joe Smith’s time is used to make upstream contributions because that burden is shared with three or four other developers,” Says Martin. 90 | 91 | By balancing the workload, you also reduce the risk to the company in losing project influence when a key developer leaves. This is also an attractive plan to developers who actively seek to increase their exposure in building leadership in the community as that ultimately boosts their careers and earning power. More developers get a lead role in this plan. 92 | 93 | Further, a company can adopt open source practices and principles internally through innersourcing, in order to complete the culture shift to open source, improve their innovation rate and successes, and further connect with the open source community which helps build leadership and attract developers. 94 | 95 | ![Source: Ibrahim Haddad, http://www.ibrahimatlinux.com/charts.html](images/building-leadership-in-an-open-source-community4.png) 96 | 97 | In short, culture is imperative in all its many nuances and on many levels, if the goal is to build and maintain leadership and thus some measure of control over critical projects. 98 | 99 | Through it all, remember to be mindful of the one percent rule. “90% are along for the ride and participate passively – this is the user community; 9% participate actively, submitting bugs, answering questions publicly – we call these ‘contributors’; 1% help to guide or control the project, assign bugs, determine direction – these are ‘maintainers’, or more simply, leaders,” explains Jeff Osier-Mixon, Intel/Yocto Project. 100 | 101 | Each project is unique; adapt on a project by project basis. 102 | 103 | ## Leadership roles in a collaborative project 104 | 105 | While roles appear similar to corporate roles and structure, every project is different and structured and managed by a specific set of community guidelines and a governance policy. Be sure to read the documentation, join IRC for real-time, private chats, join mailing lists, etc. for guidance on how roles are defined and how the project is structured and managed. 106 | 107 | Meanwhile, the following will give you a general understanding of some of the common types of leadership roles. 108 | 109 | ### Technical leadership 110 | 111 | * Committer/Maintainer 112 | * TAB/TSC member 113 | * TSC chair/chief architect 114 | * Documentation/technical writer – “this is a special case maintainer” 115 | 116 | ### Governance leadership 117 | 118 | * Executive director 119 | * Committees/subcommittees 120 | * Board member/member representatives 121 | 122 | ### Operational leadership 123 | 124 | * Project managers 125 | * Community managers and advocates 126 | 127 | ## Leadership roles matrix 128 | 129 | Keep in mind that while these roles resemble their traditional counterparts in a historical management hierarchy, they are not the same. One cannot simply transpose the values, processes and principles from the old closed model to the new open source model. In many ways they are direct opposites, or perhaps mirror images. In any case, they are different in every important way. To choose one is to reject the other. 130 | 131 | The leaders in open source are comfortable and even promote transparency and must obtain consensus before a project can move ahead. The process and leadership style can be maddening to those who prefer to cling to the traditional business structure. 132 | 133 | In response to the frustrations often encountered in this sweeping cultural change, “a lot of companies will take the path of least resistance, which is ”oh this is great. I’m going to start with this as a base, fork it and do my own thing internally," says Martin. 134 | 135 | “The problem is that’s not sustainable and scalable in the long term because the further you diverge away from the rest of the community, the harder it’s going to be when there’s a next major upgrade that you want to pull from the community,” he said. 136 | 137 | Simply put, open source is a community effort and anything you do that pulls your work away from the community will eventually be to your company’s detriment. 138 | 139 | ## How to become a leader 140 | 141 | Becoming a leader in a collaborative environment requires considerable people skills and a willingness to see no work as beneath your rank. 142 | 143 | > “It is as simple as noticing that something needs to be done, and doing it – filing a bug, answering a question, offering to sit in the booth at a conference.” – Jeff Osier-Mixon, Open Source Community Manager at Intel, speaking at Open Source Leadership Summit 2017. 144 | 145 | And, of course, it requires significant technical skills in open source and the audacity in boldly using them – but only after you’ve studied the lay of the land, understood the group dynamics, and done some of the dirty work yourself. 146 | 147 | In other words, becoming a leader starts with earning the group’s respect. You can’t demand it, you must earn it. 148 | 149 | ### Where to join in to prove your chops and earn leadership 150 | 151 | Projects document how to join a committee, become a maintainer, and how to do join in at almost any level. Look at those documents to find a place to begin fitting into the group. You can start anywhere you like, just don’t cut in line. 152 | 153 | “The one thing a person can do to develop influence is listen, understand, really try to read a situation before jumping in. If you can develop that habit over time then I think people will respect your contributions and find you to be more influential,” says Yehuda. 154 | 155 | Open source conferences also provide a great way to meet other developers and leadership in a community. Beyond networking, making presentations at such events is a noteworthy way to share your and your company’s accomplishments and contributions to open source projects. 156 | 157 | Yehuda says his company, Oath, helps developers hone their presentation skills and polish specific presentations so that they succeed on stage. Practice makes perfect, so the more presentations developers make, the better they get at doing it – and the more recognizable their face, name and work becomes to the open source community. 158 | 159 | Contributions upstream will do the most in establishing your credentials and reputation in the community, however. Jump in and fix bugs where you see them and make contributions that will be helpful to the entire community and not just for your own projects. 160 | 161 | ### Joining vs creating a project 162 | 163 | Joining a project may seem like a slow path to a leadership position. Indeed, it does take time. However, it has advantages too, including immediate gains by benefitting from the work the community has already done and none of the expense of starting your own project. 164 | 165 | Starting your own projects in order to establish leadership, won’t gain you much. 166 | 167 | As Martin put it, “if you’re the only group of kids in the sandbox, all from the same company, are you really leaders, or are you just the only people working on the project?” 168 | 169 | If you do start a project, do so for reasons other than establishing leadership because frankly no one else might join. That’s especially true if your project is less than stellar or competes with an established project. 170 | 171 | “Starting a project takes a lot of work. Don’t start it if your code would be better off served contributing to another project where you could become a leader in that project by the basis of your code contributions,” advises Martin. 172 | 173 | ![Source: Ibrahim Haddad, http://www.ibrahimatlinux.com/charts.html](images/building-leadership-in-an-open-source-community5.jpg) 174 | 175 | ### Technical contributions 176 | 177 | Donating code is serious business in open source communities. Building the project is exactly the point of the joint exercise. With many hands, the work is lighter, and by many contributions the risks are lowered and the quality heightened. Those are the goals anyway. 178 | 179 | The number one rule is to make sure that your contributions are useful to others and not just self-serving. But usefulness isn’t limited to big advancements; smaller bug fixes and other tweaks are appreciated too. The point is to make your contribution universally helpful, whether big or small. 180 | 181 | Ibrahim Haddad also counsels contributors to follow the proper coding style, work within the project’s submission processes, provide documentation and explanations, listen to feedback, and wait patiently for acceptance. 182 | 183 | ![Source: Ibrahim Haddad, http://www.ibrahimatlinux.com/charts.html](images/building-leadership-in-an-open-source-community6.jpg) 184 | 185 | ### Hiring talent 186 | 187 | It’s no secret that open source developers are in short supply. That is likely to remain the case for the foreseeable future given that adoption of open source projects is at an all-time high and shows no signs of slowing. Not only does this mean that it is hard to find skilled developers to hire, but it is also tough to retain them if you do. 188 | 189 | A 2016 Cloud Foundry [report](https://www.cloudfoundry.org/developer-gap-2016/) found that there are “a quarter-million job openings for software developers in the U.S. alone and half a million unfilled jobs that require tech skills.” Additionally, the analysts forecast that the number of unfillable developer jobs will “grow to one million within the next decade.” 190 | 191 | The demand for open source developers is even more extreme. 192 | 193 | Still you can find out who are the leaders and who are regular and skilled contributors in an open source community and try to hire them directly. Or, you can ask them to recommend developers they themselves would like to work with. 194 | 195 | “If you’re planning on hiring a maintainer, or hiring a strong contributor, keep in mind that those people are in high demand and they’re the most job flexible people on the planet. Meaning, they can go from company to company, and still work on the same project. The only thing that changes is the name of the company signing their paycheck,” says Martin. 196 | 197 | You can find additional guidance on hiring open source developers in the Linux Guide “[Recruiting Open Source Developers](https://www.linuxfoundation.org/recruiting-open-source-developers/).” 198 | 199 | ### Building talent (the best way) 200 | 201 | Fortunately, open source is so hotly in demand that developers actively seek opportunities to develop or hone their open source chops. Martin says that every developer he’s interviewed to date has asked him how the company will help him build his own open source brand. Helping the developer grow into leadership in an open source community is a prime perk and useful in recruitment. 202 | 203 | Raising your own company’s visibility in its open source work can thus also help recruit developers. Some companies even offer open source training to add to the appeal. Presenting the company’s open source projects at conferences and contributing code in communities hare the best ways to raise your company’s visibility. Asking your developers to network with other developers and invite them aboard also tends to work well. 204 | 205 | Another key approach to attracting developers is by offering apprenticeships. Developers like to work on significant projects with plenty of reputation-building challenges. Offering apprenticeships and mentorship programs tends to be a successful draw and a great way to leverage the talent you already have onboard. 206 | 207 | Above all, gain the community’s trust so that your company is attractive to open source developers and to developers who seek to advance their career by working with a trustworthy, open source leader. 208 | 209 | > “Like anyone else, commercially-motivated developers gain influence in the project through the quality and quantity of their contributions.” – [Open Source Guides](https://opensource.guide/leadership-and-governance/#what-happens-if-corporate-employees-start-submitting-contributions), GitHub, Leadership and Governance, corporate employees. 210 | 211 | ### Strategic contributions 212 | 213 | Strategic contributions are significant in establishing leadership. They tend to address a large problem shared across the ecosystem, or provide a key advancement that pushes the project past a community set goal line. 214 | 215 | However, you can’t just release the code and forget about it. There’s work to do in providing documentation, expanding the ecosystem, partnering to advance this code or toolset even further, and so on. Staying in the game and remaining both visible and reliable is key. 216 | 217 | ### Non-technical contributions and support 218 | 219 | Beyond technical contributions, strategic and otherwise, are other ways to contribute and support the community thereby further building leadership. 220 | 221 | Those include contributing to and supporting developer education and providing mentorship. Providing support for the technical aspects is another successful way to establish leadership. 222 | 223 | The key is to look around and see what the community needs beyond technical contributions and then step up to contribute some of that. 224 | 225 | ## Final words 226 | 227 | In summary, being a good leader and winning influence takes time and hard work. 228 | 229 | Specific ways to work at becoming a leader include: 230 | 231 | * Adapt to the OSS project culture, practices and tools. Work to fit in and follow the rules and processes. Remember it’s not about you; it’s about the project. 232 | * Do the grunt work. Projects need workhorses, not all-stars. Besides, if you can’t do the work, you can’t earn the right to lead. Be quick to show you can and will do the work needed. 233 | * Be magnanimous. Contribute code that benefits the whole project. 234 | * Build consensus. True leaders can build consensus, work to help achieve consensus even before becoming a leader to show that you aren’t a grandstander or a tyrant. 235 | * Accept that leadership changes. Recognize and accept that leadership roles move with the people, not the company that employs them. 236 | 237 | ## Acknowledgements 238 | 239 | Contributors to this guide: 240 | 241 | * Guy Martin, Autodesk 242 | * Gil Yehuda, Oath 243 | 244 | *These resources were created in partnership with the TODO Group: the professional open source program networking group at The Linux Foundation. A special thank you to Pam Baker for writing assistance and the open source program managers who contributed their time and knowledge to making these comprehensive guides. Participating companies include Autodesk, Comcast, Dropbox, Facebook, Google, Intel, Microsoft, Netflix, Oath (Yahoo + AOL), Red Hat, Salesforce, Samsung and VMware. To learn more, visit: [todogroup.org](http://todogroup.org/)* 245 | -------------------------------------------------------------------------------- /casestudies/README.md: -------------------------------------------------------------------------------- 1 | # Open Source Program Case Studies 2 | 3 | We have seen a recent trend in open source program formation. We have seen companies like AWS [build out an open source program](http://fortune.com/2016/12/01/amazon-open-source-guru/) via [@AWSOpen](https://twitter.com/AWSOpen) and even companies like [VMWare hired their first Chief Open Source Officer](https://thenewstack.io/makers-dirk-hohndel-vmware-role-open-source-commercial-software/). 4 | 5 | We've had many organizations approach TODO Group members asking for advice on how to get started with an open source program and we have decided to build out case studies from our membership to share best practices: 6 | 7 | * [Autodesk](autodesk.md) 8 | * [Capital One](capitalone.md) 9 | * [Comcast](comcast.md) 10 | * [Dropbox](dropbox.md) 11 | * [Facebook](facebook.md) 12 | * [Microsoft](microsoft.md) 13 | * [Oath](oath.md) 14 | * [Red Hat](redhat.md) 15 | * [Salesforce](salesforce.md) 16 | 17 | If you have an open source program and you're interested in adding a case study, please send a pull request! 18 | -------------------------------------------------------------------------------- /casestudies/autodesk.md: -------------------------------------------------------------------------------- 1 | # Autodesk 2 | 3 | Autodesk is undergoing a company-wide shift to open source and inner source. And that’s on top of the culture change that both development methods require. 4 | 5 | Inner source means applying open source development practices and methodologies to internal projects, even if the projects are proprietary. And the culture change required to be successful can be a hard shift from a traditional corporate hierarchy to an open approach. Even though they’re connected, all three changes are distinct heavy lifts. 6 | 7 | They began by hiring Guy Martin as Director of Open Source Strategy in the Engineering Practice at Autodesk, which was designed to transform engineering across the company. Naturally, open source would play a huge role in that effort, including spurring the use of inner source. But neither would flourish if the company culture didn’t change. And so the job title swiftly evolved to Director of Open @ADSK at Autodesk. 8 | 9 | > “I tend to focus a lot more on the culture change and the inner source part of my role even though I'm working through a huge compliance initiative right now on the open source side,” Martin said. 10 | 11 | The history of Autodesk’s open source transformation began shortly after the shift of all its products to cloud began, including its AutoCAD architecture software, building information modeling with its Revit products, as well as its media and entertainment products. The company’s role in open source in entertainment is now so significant that Martin often speaks at the Academy of Motion Picture Arts and Sciences on open source. They want to hear about what Autodesk is doing as part of a larger collection of initiatives that the Academy is working on, Martin said. 12 | 13 | At Autodesk, the goal is to spring engineers loose from their business silos and create a fully open source, cloud-centric company. 14 | 15 | > “Your primary identity detaches from being part of the AutoCAD team or part of the Revit team, or the 3ds Max or Inventor team or any of these products,” Martin explained. “It’s now shaping you into part of the Autodesk engineering team, and not your individual silo as a product organization in the company.” 16 | 17 | Talent acquisition is among the top business goals for Open@Autodesk, especially given the company’s intense focus on innovation as well as making all of its products work seamlessly together. It takes talent skilled in open source methodologies and thinking to help make that happen. But it also means setting up the team dynamics so collaboration is more natural and less forced. 18 | 19 | > “With company cultures and some engineering cultures, the freedom to take an unconventional route to solve a problem doesn’t exist,” Martin said. “A lot of my job is to create that freedom so that smart and motivated engineers can figure out a way to put things together in a way that maybe they wouldn’t have thought of without that freedom and that culture.” 20 | 21 | To help create an open source culture, the right tools must be in place and, oddly enough, those tools sometimes aren’t open source. For example, Martin created a single instance of Slack rather than use IRC because Slack was more comfortable for users in other lines of the business who were already using it. The intent was to get teams to start talking across their organizational boundaries. 22 | 23 | Another tool Martin is working with is [Bitergia](https://bitergia.com/) Analytics to monitor and manage Autodesk’s use of GitHub Enterprise. 24 | 25 | Martin says the three key lessons he’s learned as an open source program manager are: 26 | 27 | 1. Stay flexible because change happens 28 | 2. Be humble but bold 29 | 3. Be passionate. 30 | 31 | > “I've been at Autodesk two years but I'm still bootstrapping some of the things around culture. We have strong contributors in some projects, while in some projects we're consuming. I think you have to do both, especially if you're bootstrapping a new open source effort in a company.” 32 | 33 | > “The challenge is always balancing the needs of the product teams, who have to get a product out the door, and who (and as an engineer I can say this) will take shortcuts whenever possible. They want to know, ‘why should we be doing this for the community? All we care about is our stuff.’ And it’s getting them past that. Yes, we're doing work that’s going to be used elsewhere, but in the end we're going to get benefits from pulling work from other people who have done work that they knew was going to be used in the community.” -------------------------------------------------------------------------------- /casestudies/capitalone.md: -------------------------------------------------------------------------------- 1 | # Capital One: Open Source in a Regulated Environment 2 | 3 | ## Lessons Learned on Our Open Source Journey at Capital One 4 | 5 | ![](images/capitalone1.jpg) 6 | 7 | Most people know Capital One as one of the largest credit card companies in the U.S. Some also know that we’re one of the nation’s largest banks — number 8 in the U.S. by assets. But Capital One is also a technology-focused digital bank that is proud to be [disrupting the financial services industry](https://medium.com/capital-one-developers/we-re-a-disruptive-bank-a21f7cce25b6#.7swhf6tt4)through our commitment to cutting edge technologies and innovative digital products. Like all U.S. banks, Capital One operates in a highly regulated environment that prioritizes the protection of our consumers and their financial data. This sets us apart from many companies who don’t operate under the same level of oversight and responsibility. 8 | 9 | Our goal to reimagine banking is attracting amazing engineers that want to be part of the movement to reinvent the financial technology industry. During interviews, they are often surprised to find we want them to use open source project and contribute back to the open source community. Even more are blown away that we sponsor open source projects built by our engineers. 10 | 11 | *People expect that kind of behavior at a start-up, not a top bank. There is nothing traditional about Capital One and our approach to technology.* 12 | 13 | When we see opportunities, especially in technology, we deliberately pursue them. Our approach to managing technology, guided by general industry regulations and company-specific policies, provide the guardrails for using, contributing to, and launching open source software projects. The Open Source Office adopted a comprehensive risk management approach wherein we have identified clear risk ownership around when to use, contribute to, and launch open source projects. 14 | 15 | Our journey to managing open source risk and implementing this strategic approach followed this trajectory: 16 | 17 | * Engineers wanted to use and contribute to open source projects. 18 | * Risks were identified, analyzed, and a path to managing them was mapped out with the Open Source Office, Legal, and Security teams. 19 | * Focus on education, with external partnerships providing guidance (Linux, TODO, etc.). 20 | * Momentum increased as we matured our internal partnerships with Engineering, Legal, Security, and Audit Teams. 21 | * Explaining and demonstrating our risk management approach to leaders secured sponsorship and resources. 22 | 23 | ### Organizing Into an Office 24 | 25 | With strong leadership support, in 2015 we formalized oversight and governance through the creation of Capital One’s Open Source Office (OSO). With strong partnerships in Legal and Security, resources accountable for advising and overseeing open source activities were established within the OSO. 26 | 27 | Through these partnerships, the OSO team manages the company’s open source contributions, including these three crucial pillars: 28 | 29 | * **Manage direction** — Policy, guidance, and education. 30 | * **Manage connections** — Internal and external, as well as partnerships with Legal, Security, and other stakeholders. 31 | * **Manage technologies** — Support open source processes and community needs. 32 | 33 | As a horizontal function, OSO manages the direction and risk-based approach Capital One takes with open source. We collaborated to define a corporate level policy for Open Source Software and developed educational materials and videos to guide teams and individual developers on how to manage defined risks. On a daily basis, OSO team members, along with our partners in Legal and Security, work with engineers and data scientists to understand use cases and provide guidance on how to appropriately manage risk. 34 | 35 | In addition to OSO managing internal connections with various teams in Capital One (Engineering, Legal, Trademarks, Security, Brand, Corporate Communications, Risk Management, Audit etc.), we actively manage our relationships with external communities such as the [Linux](https://www.linuxfoundation.org/) and [Apache](https://www.apache.org/)Foundations. We are also active members in the [Open API Initiative](https://www.openapis.org/), [Cloud Native Computing Foundation](https://www.cncf.io/) (CNCF) and the [TODO Group](http://todogroup.org/). We are also actively interacting with members of our own open source project communities (e.g. [Hygieia](https://developer.capitalone.com/opensource-projects/hygieia/) and [Cloud Custodian](https://developer.capitalone.com/opensource-projects/cloud-custodian/)). 36 | 37 | ### Formalizing Guardrails Through a Corporate Policy and Standard 38 | 39 | In 2016, the OSO defined a corporate level Open Source Software Policy and Open Source Software Standard based upon an example from the Linux Foundation. The policy addresses three use cases and calls out the requirements to manage risk when: 40 | 41 | 1. Using open source software projects. 42 | 2. Contributing to open source projects. 43 | 3. [Sponsoring open source projects](https://developer.capitalone.com/open-source/) 44 | 45 | The policy also formalizes accountabilities for the three main open source stakeholders at Capital One, including: 46 | 47 | 1. The developer/engineering community. 48 | 2. Establishes a new strategic partnership between from diverse groups called the Open Source Steering Committee. 49 | 3. Defines the tactical partnership between OSO, Legal, and Security within an Open Source Review Board. 50 | 51 | ![](images/capitalone2.jpg) 52 | 53 | As we developed this policy and formalized accountabilities, we established the tactical partnership between OSO, Legal, and Security as the OSRB. This tactical team works to guide open source activities with the development community. We also established a strategic leadership committee named the OSS Steering Committee, a group comprised of a dozen leaders who provide strategic direction for the development community. 54 | 55 | ### Taking it to the Next Level 56 | 57 | As we look ahead in our open source journey, we plan to focus on: 58 | 59 | * Continue to educate our growing technology organization. 60 | * Strike a balance between managing risks and minimizing development bottlenecks. 61 | * Further automate license and security scanning and integrate it into our build process. 62 | * Establish and grow a robust governance function. 63 | 64 | Specifically, in 2018 we’re focusing on education, strengthening awareness in the development community, and establishing our role as an advisor. 65 | 66 | ![](images/capitalone3.jpg) 67 | 68 | Collaboration among the multiple stakeholders has been key to navigating our open source journey. Capital One is a technology driven company and we are unified across our organization on taking our open source activities to the next level in 2018. 69 | 70 | At the end of the day, we strongly believe in the benefits of involvement in open source projects. By managing the associated risks through policies, standards, and cross-departmental collaboration, the OSO allows Capital One to fully leverage our involvement in this community. 71 | 72 | ## Acknowledgments 73 | 74 | Thank you to Nadine Hoffman and the Capital One OSPO for contributing this guide based on this [original article](https://medium.com/capital-one-developers/open-source-in-a-regulated-environment-dc4b4d9af3f8). -------------------------------------------------------------------------------- /casestudies/comcast.md: -------------------------------------------------------------------------------- 1 | # Comcast 2 | 3 | [Comcast](http://corporate.comcast.com/)’s involvement in open source was a gradual process that evolved over time. The company eventually created two open source program offices, one for the NBC business and another for the cable side of the business, which is the subject of this profile. 4 | 5 | Comcast began contributing to open source around 2006 when Jon Moore, Chief Software Architect, made a patch contribution to Apache HTTP. He showed the management team that it was more cost effective to have the patch incorporated into the main project than it was to maintain it separately. 6 | 7 | Working with an interdisciplinary team, Moore worked to set up an open source advisory council, which consisted of legal and technical subject matter experts. They reviewed contributions and created internal guidelines focused on good open source practices and community building. In 2013, when they started tracking these contributions, they had 13. This year, they plan to do almost 10x that. 8 | 9 | > “When companies establish open source practices they send a big message saying that we're serious about open source and that we want to invest in it.”* – Nithya Ruff, Senior Director Open Source Practice at Comcast. 10 | 11 | **Six C’s of Open Source Program Practice** 12 | 13 | In 2016, Comcast hired Ruff to lead an increasingly vital open source strategy. The practice has support from the highest levels of the Comcast leadership team who wanted an organization that would field questions, educate employees, and create awareness. 14 | 15 | The open source program practice currently has three full-time people while relying on functional experts in legal, engineering, IT, PR, and more to help scale the programs. The goal is to coach, guide, advise, recommend, and serve as a consultant to employees. Ruff summarizes the function of an open source practice with “the six C’s”: consumption, contribution, compliance, communication, collaboration, and competency-building. 16 | 17 | ![](images/comcast1.jpg) 18 | 19 | The open source practice has two main goals. 20 | 21 | 1. Make it easier for people inside the company to work in open source. Whether it’s consumption of open source, contribution to open source, or collaboration with communities, foundations, and organizations, the goal is to remove legal, process, tool, communication, and awareness barriers. 22 | 23 | 2. Be visible externally in open source and technology communities. Many people don’t know that Comcast is a technology company with thousands of developers so they want to raise awareness and share what they’re doing. 24 | 25 | **Open source contributions** 26 | 27 | Comcast has [open sourced a few projects](https://github.com/Comcast) in addition to contributing significantly to existing open source communities, like OpenStack. [Apache Traffic Control](https://trafficcontrol.incubator.apache.org/) was started within Comcast and has been contributed to the Apache Software Foundation where it is currently in incubation. 28 | 29 | They were also instrumental in setting up an independent consortia called the [RDK Management Project ](http://rdkcentral.com/)focused on creating a standard around set-top boxes. The RDK software uses the Yocto build system to create a consistent layer such that everyone from the semiconductor vendors right up the chain to OEMs and ISVs can use a consistent system and structure to build the content for set-top boxes and similar devices. 30 | 31 | Comcast open sourced its [Speed-TestJS tool](https://github.com/Comcast/Speed-testJS), which is a test of internet speed, because the company wanted to be transparent to the world in terms of how they measure speed. The project also allows people to use the tool themselves to make sure that they felt that Comcast was delivering what it promised. This is a great example of a tool that could create more trust as a result of being open. 32 | 33 | In addition to contributing to projects, Comcast is also a member of a number of foundations, including [Cloud Foundry Foundation](https://www.cloudfoundry.org/membership/), the [Apache Software Foundation](https://www.apache.org/), [The Linux Foundation](https://www.linuxfoundation.org/membership/), [Yocto Project](https://www.yoctoproject.org/), [Linaro](https://www.linaro.org/), [OpenStack Foundation](https://www.openstack.org/foundation/), [Open Network Automation Platform (ONAP)](https://www.onap.org/), and [OpenDaylight](https://www.opendaylight.org/). 34 | 35 | ![](images/comcast2.jpg) 36 | 37 | Through these contributions, Comcast has benefited from the goodwill that comes from participating in open source communities. Comcast’s contributions have also helped the company recruit new developers. Developers today want to work for companies that are good open source citizens, and Comcast’s contributions in a variety of communities demonstrate that they are serious about their commitment to open source. 38 | 39 | **Aligning with the Business** 40 | 41 | > “The establishment of the practice, visible engagement at the foundation level, increased contributions, leadership support, and tooling support as a company have made it easy to do open source.*” – Nithya Ruff, Senior Director Open Source Practice at Comcast. 42 | 43 | It’s important to make sure that your company’s open source strategies are closely aligned with its business strategy. The open source office should really understand the goals of the company and enable them in the open source strategy. This strategic alignment allows the open source practice to remain aligned with the broader company goals at Comcast to encourage long-term success for the practice and the company as a whole. 44 | 45 | **Acknowledgments** 46 | 47 | *For this feature we interviewed Nithya Ruff (@nithyaruff), Senior Director Open Source Practice at Comcast, to learn more about the Comcast’s open source program. Dawn Foster performed the interview. * 48 | -------------------------------------------------------------------------------- /casestudies/dropbox.md: -------------------------------------------------------------------------------- 1 | # Dropbox 2 | 3 | The open source program at Dropbox was initially just a mailing list, where some interested engineers wanted to open source projects and develop with open source. Over time, things became more formalized, with a focus on ensuring that the company was consistent about what code it would release versus what code was best kept internal. 4 | 5 | They also wanted to ensure that the things they were releasing were things that would actually provide value. 6 | 7 | “We set minimum standards for what we would release as open source projects, including a review process, and our program just started to drive a lot of value,” said Luke Faraone, Security Engineer at Dropbox. 8 | 9 | ## What drives Dropbox’s open source program 10 | 11 | It’s important to ensure that the metrics and goals you track are not just related to volume, such as measuring the number of open source projects that you're releasing or the number of lines of code you're releasing. Those sort of metrics don’t necessarily provide business value or community value. 12 | 13 | > “We make sure to be thoughtful with our program’s goals, focusing on things that either provide back some business through external contributions or otherwise indicate that others are getting value out of our projects,” said Faraone. “We want to make sure that the community is connected back to us. Also, it is good to make sure to have fun and not have a process that is too onerous. We want people to feel comfortable working with us, and we want to be partners with folks as they work on projects. Ensuring that we have good relationships is really important.” 14 | 15 | ## How Dropbox measures community success with open source 16 | 17 | One of the most important things when building an open source community is making sure that your own processes are open. 18 | 19 | > “The more transparent you can make your decision-making processes, the more of a sense of ownership your community will have. You also want to make sure that your process doesn’t become a blocker. If your open source process for either inbound or outbound contributions is onerous, people will look to bypass the process or simply decide that contributing is too difficult,” said Faraone. 20 | 21 | ## How Dropbox tracks contribution and release metrics with open source 22 | 23 | It is important to track metrics related to contributions to projects, including such questions as: 24 | 25 | * What rate of contribution are you getting on a per-contributor basis? 26 | 27 | * Do people tend to come back to contribute to particular projects or would they also be interested in contributing to other projects that we are involved with? 28 | 29 | * How likely is a contributor who provides one patch to come back? 30 | 31 | At Dropbox, according to Faraone, they also monitor the time between releases and the amount of churn that occurs between releases, where the goal is to encourage releases early and often. They also check in with teams if they have gone several months without committing to a new version. 32 | 33 | ## Zulip stands out 34 | 35 | Among Dropbox’s open source successes – if you look at the number of contributions – a project called Zulip stands out. Zulip was an open source chat system that the company acquired in 2014, but eventually they decided that they wanted to release it to the community. 36 | 37 | > “As an open source project, members of the community had set up hosting services for the chat system, and we eventually sunsetted our hosted service. We offered all of our users an opportunity to elect to have their data migrated to one of the community-operated hosting providers. What’s really impressive is that the Zulip open source project has a higher commitment velocity than it did when it had 10 or 15 employees working on it full time,” said Faraone. 38 | 39 | ## Key lessons for open source program managers 40 | 41 | Faraone offers the following tips to help ensure success when developing an open source program. 42 | 43 | * Community involvement can often give a project higher commitment velocity than dedicating a lot of full time employees to the project. 44 | 45 | * In driving community around projects, it is critical to make sure that your own processes and decisions are open and not too onerous. 46 | 47 | * Track metrics related to community contributions closely, including whether contributors participate in more than one project, and whether releases are arriving early and often. 48 | 49 | * When compared to tracking community ecosystem health and evaluating whether your program is creating business value, tracking metrics such as lines of code created has less value. 50 | 51 | * Evaluate whether you are choosing highly restrictive licenses, and if you are, what impact that will have as you start receiving external contributions. 52 | -------------------------------------------------------------------------------- /casestudies/facebook.md: -------------------------------------------------------------------------------- 1 | # Facebook 2 | 3 | Facebook’s open source team was “formally” created in 2009, but the company has built with open source from its inception.[ Facebook.com](http://Facebook.com) was originally built on top of the LAMP (Linux/Apache/MySQL/PHP) stack. And over time Facebook has used and contributed back to these projects, as well as evolved and released new projects such as Hack which has its roots in PHP. 4 | 5 | > “Open source is core to our engineering DNA. We believe that sharing our code and even hardware designs accelerates the pace of innovation in the world. We believe that our projects help move the industry forward while giving other companies and individuals the opportunity to use our platform to scale more quickly and build better products.” – [Christine Abernathy](https://twitter.com/abernathyca), Open Source Developer Advocate at Facebook. 6 | 7 | ## Custom tools to manage open source 8 | 9 | Facebook has a dedicated Tools team within the open source program office that is responsible for building internal tools to help manage its open source portfolio. This includes the projects that Facebook shares, which are mostly hosted on GitHub, as well as the other external projects they contribute to such as the Linux Kernel. 10 | 11 | The program office provides a dashboard for each project that includes GitHub metrics such as the number of open issues or the ratio of internal to external contributions for a given time period. Project maintainers are given tools so they can bring GitHub pull requests and issues into their internal review and bug tracking systems. This makes it easier for engineers to manage external issues where they're most comfortable. Maintainers also have access to workflow tools to reliably push internal commits out to GitHub, making it easy to quickly sync internal and external code bases and reducing the churn on landing external contributions. 12 | 13 | The open source team can look at these project dashboards to help analyze the health of a particular project. They’ve even open-sourced some of these workflow tools:[ mention-bot](https://github.com/facebook/mention-bot) and[ FBShipIt](https://github.com/facebook/fbshipit). 14 | 15 | The team collects top-level statistics on how the overall portfolio is doing through aggregate dashboards across the GitHub orgs they manage. These are used to provide high-level reports to stakeholders and a community of internal open source enthusiasts. The tools team also provides insight into top contributors. Project maintainers are encouraged to refer to this list and reward their top contributors. The company periodically thanks its top internal contributors and makes some of this information available to its internal review systems. 16 | 17 | The open source office also provides tooling to guide potential projects through the review process. This helps streamline the process and helps the team easily spot and correct bottlenecks. 18 | 19 | The open source team also provides services such as documentation. This includes helping out with the technical content as well as building out some of the documentation infrastructure and templates that projects can use. 20 | 21 | ## Open Source Success Through Steady Progress 22 | 23 | At the end of each half the program office identifies goals around metrics they want to achieve. The metrics they track include: 24 | 25 | * The average age of open issues or open pull requests 26 | * The ratio of external to internal commits 27 | * The number of commits 28 | * The growth in followers and forks 29 | * The number of social media followers. 30 | 31 | They’re periodically tweaking what they measure as they refine what it means to maintain a healthy portfolio. 32 | 33 | Facebook also surveys new hires every six months to gauge their awareness of its open source program. They set baseline metrics a few surveys back and the goal is to maintain or grow those numbers. 34 | 35 | Their open source success isn’t the result of one action but the cumulative effect of a steady stream of quality releases over the years and a focus on growing thriving communities to support those projects. 36 | 37 | > “Projects like React, React Native, Create-React-App, Immutable, HHVM, Fresco, and GraphQL are the constant beat that have contributed to the success of our program,” Abernathy said. 38 | 39 | One of Facebook’s most successful projects is React Native. It makes use of many of Facebook’s tools to help manage the community. For example, mention-bot came out of this project and was a way to quickly identify reviewers for a pull request. FBShipIt helped it cut down the time to bring in external contributions, review them internally, and land these contributions back out to GitHub. In the early days this process sometimes took a day as much of it is manual. Now this can be done in as little as minutes if it’s an automatic reviews. 40 | 41 | The open source program office also provided documentation services to help refresh and keep the React Native site up to date. 42 | 43 | ## Tips for New Open Source Program Managers 44 | 45 | Organizations that are just establishing an open source strategy and program office can learn from the success of Facebook’s open source program. Here are the three key practices that Abernathy shared that have contributed to their success as a program office: 46 | 47 | 1. When evaluating what to share, it should be something that’s useful to your company. Many of the projects that Facebook shares are used in production and include all the benefits that come along with that. This means those projects are likely to have continued support which in turn means the community is well supported. 48 | 2. Find a way to highlight, promote, and reward your open source contributors, both internal and external. Facebook has periodic reports that highlight its open source heroes. This helps raise the profile of engineers and their work with managers who may sometimes not be managers of that open source project. 49 | 3. As a central program office, find pain points that cut across the various projects and tackle them. 50 | 51 | For example, many projects had previously built their own commit copying scripts and it was the number one pain point from a survey they ran at that time. FBShipIt, which copies commits between repositories, was built to address this and it’s owned by the open source team. It moved the burden off the engineering teams and is universally praised for helping smooth the workflow for pulling in external contributions. 52 | 53 | ## Acknowledgments 54 | 55 | *For this feature we interviewed Christine Abernathy (@abernathyca), Open Source Developer Advocate at Facebook, to learn more about the Facebook’s open source program. Libby Clark performed the interview.* 56 | -------------------------------------------------------------------------------- /casestudies/images/capitalone1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/casestudies/images/capitalone1.jpg -------------------------------------------------------------------------------- /casestudies/images/capitalone2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/casestudies/images/capitalone2.jpg -------------------------------------------------------------------------------- /casestudies/images/capitalone3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/casestudies/images/capitalone3.jpg -------------------------------------------------------------------------------- /casestudies/images/comcast1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/casestudies/images/comcast1.jpg -------------------------------------------------------------------------------- /casestudies/images/comcast2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/casestudies/images/comcast2.jpg -------------------------------------------------------------------------------- /casestudies/microsoft.md: -------------------------------------------------------------------------------- 1 | # The Open Source Program at Microsoft: How Open Source Thrives 2 | 3 | Microsoft is now an accepted big player in the open source space, but just a few years ago such a role for the software giant, seemed inconceivable. Many people were thus surprised when Microsoft emerged from its market lead as a proprietary software maker to make a move towards open source in a big way. Although the company’s story is remarkable, its open source journey has been neither as abrupt or unexpected as it may have appeared. 4 | 5 | > “Despite perception, Microsoft has been doing open source for quite a while. At first, it was experimental pieces here and there but about six years ago, in 2011, we brought much of that into focus in an entity called Microsoft Open Technologies,” explained Jeff McAffer, Director of Open Source Programs Office at Microsoft. 6 | 7 | ## Open source in earnest 8 | 9 | That’s when the exploration of what Microsoft could do with open source began in earnest, McAffer said. In the early days, if anyone in the company was interested in doing anything with open source, they came to the centralized group for assistance from the open source developers, contributors, and maintainers involved. 10 | 11 | About three years ago, things began to change. Microsoft decided to make open source pervasive throughout the company and rolled open source into the main engineering groups. 12 | 13 | > “If that’s all we had done, we would have left an untenable vacuum around how we do open source,” said McAffer. “Someone has to think about policy and how all the open source efforts would be coordinated, the processes and tools they would use, how would we keep track of projects, etc. So, we created what is now known as the Open Source Programs Office to handle all those issues.” 14 | 15 | Some of the technical people from the earlier open source group moved to the newly formed program office, while the others joined engineering groups pertinent to their work. It turned out that Microsoft needed additional talent to make sure all projects and processes were fully manned, and so recruitment efforts, both internally and externally, were soon under way. Today, open source is a thriving part of Microsoft’s global works. 16 | 17 | ## Business and programmatic goals 18 | 19 | Microsoft does not have a central open source strategy or a central approval body. Instead, the Open Source Programs Office facilitates those discussions and decisions throughout the company. Teams still need to have their open source engagement reviewed, but it is done more locally. 20 | 21 | > “They know their business, they understand how they want their technical interactions to work, where they want to drive in terms of ecosystems, and all the various nuances of what needs to happen,” McAffer said. 22 | 23 | > “We defer most of those decisions and directions to the local management, but we give them a structure in which to think about those decisions and directions. We do have central policies about how we manage IP and what do we do about security issues. We give them tools and processes that embody those policies to make it super simple for them to execute in a coherent yet specific way.” 24 | 25 | ## The tools to manage 26 | 27 | Microsoft’s policies boil down into processes that then are tooled accordingly to handle the workload. One example is open source releases. As a matter of policy, releases are made on GitHub. 28 | 29 | > “We've got a bunch of tooling around our presence on GitHub, where we manage something like 10,000+ repos across about 100 organizations with about 12,000 Microsoft people interacting in that space,” said McAffer. 30 | 31 | > “That gets up to a scale where you really need a system to manage a multitude of aspects. For example, when people want to contribute to one of the projects that we're running, we need tools to help manage the contributor license agreements or CLA’s. For all of those things, we've either built up solutions ourselves or turned to open source solutions.” For example, for CLA management, Microsoft uses [CLA Assistant](https://cla-assistant.io), an open source program that SAP originated. 32 | 33 | > “On the GitHub management side, we went the other direction, as there wasn’t an existing set of tooling to help manage an enterprise presence on GitHub,” said McAffer. “So we ended up creating what’s now called the [open source portal](https://github.com/Microsoft/opensource-portal), which is available on GitHub as open source.” 34 | 35 | Elements of that are easily seen on [opensource.microsoft.com](https://opensource.microsoft.com/), but then there’s an internal side, too, where Microsoft employees manage repos and teams. “We've open sourced that and other companies are picking it up and using that internally for themselves, so it’s a bi-directional thing,” McAffer explained. 36 | 37 | GitHub is a very rich environment, where lots of interactions are possible. Microsoft, like a lot of companies, was finding it difficult to keep track of everything going on and understanding what was happening with its repos. 38 | 39 | > “We ended up engaging with the GHTorrent project. We did quite a bit of work with them, and we actually are now sponsoring the GHTorrent project so we pay for all their Azure resources, everything you can see that at [GHTorrent.org](http://ghtorrent.org/),” he said. 40 | 41 | GHTorrent helps Microsoft understand what’s going on at GitHub but also internally in terms of its own projects. Even so, there are some things that GHTorrent was not set up to do, including work with private repositories and some of the more detailed data concerning teams where admin permissions are required. 42 | 43 | The company ended up creating another system called [GHCrawler](https://github.com/microsoft/ghcrawler), which it also open source. This tool tracks everything on GitHub down to the commit level, team, and permissions changes. That data is then used in metrics and tracking analysis to discover insights such as how many pull requests are coming in, how fast they are getting action, and how long they take to close or merge. “It gives us a way of tracking our presence,” said McAffer. 44 | 45 | ## Simplifying open source use 46 | 47 | Consumption of open source is an entirely different matter, and a different process, at Microsoft. The company uses open source in myriad ways, and the need to track them all and to manage the legal security aspects is enormous. 48 | 49 | > “We've done a massive amount of work to simplify the processes and the policies around open source use, to really understand the key attributes of being a responsible consumer of open source, how to do it right, and to make sure we adhere to the licenses,” McAffer said. 50 | 51 | > “To that end, we've written a lot of tools internally to discover, track, and monitor what’s going on there and report on the use of open source,” he continued. Those tools also tend to be somewhat proprietary as they are deeply integrated with Microsoft’s engineering systems. 52 | 53 | > “We've been trying to see ways we can tease that out and make more of that available to the open source community more broadly, but it’s been a bit hard because it is very specific in many ways to our business policy or our engineering system, which isn’t going to be the same as anybody else’s,” McAffer said. 54 | 55 | The Microsoft open source journey has been an interesting one over the years and in the true open source spirit, we will continue to share what we learned with everyone in that process, from tools to code. 56 | 57 | ## Acknowledgements 58 | 59 | We would like to thank Carol Smith, Senior Open Source Program Manager at Microsoft and Jeff McAffer, Director of Open Source Programs Office at Microsoft for being interviewed. We would also like to thank Pam Baker for performing the interview. 60 | 61 | -------------------------------------------------------------------------------- /casestudies/oath.md: -------------------------------------------------------------------------------- 1 | # Oath 2 | 3 | For seven years and counting, Gil Yehuda, Senior Director of Open Source at Oath Inc. (which owns the Yahoo and AOL brands), has led the open source program at Yahoo. Now with an expanded scope, he is gearing up to grow his team and improve the program. The company’s formal open source program office serves as a hub to connect all open source activities across the company, he says, but it didn’t start out that way. 4 | 5 | As with many other companies, the open source program started informally with a group of diligent engineers and a few legal people. But the ad hoc group soon realized it needed a more formal program if it was going to be able to scale to address more issues and achieve specific business goals. With a formal program in place, they are poised to achieve its goals. 6 | 7 | The top five of Oath’s numerous open source goals, according to Yehuda, are: 8 | 9 | 1. Keep aligned with the industry on open source technology standards by avoiding creating unique tech stacks that Oath alone would have to manage at its own expense. 10 | 2. Make it easy for engineers to interact with open source as users and as contributors. 11 | 3. Be viewed as an open source friendly company for partnerships and collaborations. 12 | 4. Be known as a great place for engineers to work on open source projects. 13 | 5. Give back to the Open Source community by sharing code and practices. 14 | 15 | Measuring and monitoring success requires the right tools and attitudes. Yehuda says at Oath they actively solicit and listen to the needs of their many engineering teams, track all their work transparently in JIRA, and spread the work across many teams who help with the process. 16 | 17 | > “We have custom tools we use to check code and manage projects, but we’re hoping to work more with our peers in the [TODO Group](http://todogroup.org/) on tooling we can share across many of our peer open source program offices,” he said. 18 | 19 | ## Success comes from being open, at scale 20 | 21 | Yahoo helped make [Apache Hadoop](http://hadoop.apache.org/) the cornerstone of the big data revolution when it took the early code and created a team around it to help it scale to internet-scale. They agreed to publish it all as open source. When the need for real-time processing came to the forefront, Yahoo created S4 and open sourced it too, but then discovered Storm was just published too, and it looked more promising. The team ditched their own code and put their efforts into helping make Storm even better. 22 | 23 | > “We applied to [Apache Storm](http://storm.apache.org/) what we learned from Hadoop and S4,” Yehuda said. “Our goal was to make it great, even though it kind of competed with our own first stab.” 24 | 25 | Storm is a success today, and the company runs it alongside Hadoop to power many of its products. They added machine learning and high-scale data serving capabilities by adding [Vespa Engine](http://vespa.ai/), to their platforms, and then published that too. And they helped other machine learning projects scale better too, all by publishing open source. 26 | 27 | > “We’ve leveraged our expertise with Storm to help both Caffe and TensorFlow achieve better scalability. We don’t own these solutions exclusively. Rather we share our code and help others – all the while we get to leverage our expertise to build one of the industry’s most scalable platforms for our use,” he said. “This saves us money while making us a fantastic place to work on projects that impact hundreds of millions of people.” 28 | 29 | The program office worked on strategy, legalities, and execution of these and similar projects. Leveraging open source licensing and processes effectively was a key element throughout. Now as Oath, this work continues and expands. 30 | 31 | Yehuda cited three key lessons he learned managing an open source program: 32 | 33 | 1. Be a service to the engineers, not a barrier. 34 | 2. Accept that challenges will be never-ending. 35 | 3. Run the program office like you run an open source project: Be transparent in the way decisions are made and be open to input and collaboration from everyone. 36 | 37 | > “There are so many edge cases that come up – partnerships, acquisitions, unclear contract terms – and we simply need to be open to learn, explore, and come up with an answer to every open source related question. But the most rewarding part of my job is when people tell me they joined our company because they knew about our open source friendly culture. You know, we’re always looking for open source talent, and I’m hiring into the program office.” added Yehuda. 38 | 39 | -------------------------------------------------------------------------------- /casestudies/redhat.md: -------------------------------------------------------------------------------- 1 | # Red Hat 2 | 3 | ## Open Source and Standards Team: How Red Hat Measures Open Source Success 4 | 5 | Red Hat is, by its very nature, a deviation from the norm in this series of profiles. It is not a company with an open source program, but rather an open source company with an open source and standards office and an engineering team dedicated to curating communities and tending upstream contributions. In essence, Red Hat is a living, breathing testament to the success of open source. However, it still benefited from some organization and goal-setting in its community efforts. 6 | 7 | > “The [open source and standards office](http://community.redhat.com/), or what some would refer to as an open source program office, was established six years ago to create a consistent way to support communities and open source technologies from companies we acquired from time to time. We created a centralized organization of expertise to support the rest of the company in achieving their goals through open source,” explained Deborah Bryant, senior director, open source and standards, in the office of the CTO at Red Hat. 8 | 9 | However, there wasn’t any need to advocate open source or push for its adoption internally. Red Hat hired open source expertise rather than growing it internally, so everyone on board was already firmly in the open source camp. 10 | 11 | > “Most open source program offices encourage engineers to contribute to open source, or to educate people on what open source is, or to assist in choosing an open source license. These are things that are a done deal at Red Hat,” says Bryant. “Rather than just seeing how we can use open source to improve our business, or be more flexible in operational efficiencies, or bringing more money to the bottom line, we are at the level of maturity where open source is our actual business practice and model.” 12 | 13 | Therefore, the focus is on reaching specific goals rather than on transitioning to open source. 14 | 15 | > "For us, open source is an important part of our business model, and our business goals are to make sure that those communities that we rely upon are healthy and thriving, said Bryant. 16 | 17 | ## In Red Hat’s open source toolbox 18 | 19 | Having goals is one thing, achieving them is quite another. Several tools can be used to measure progress and results. Red Hat uses a range of tools to make sure it is hitting the mark, and communications-based tools top the Red Hat list of must-haves. 20 | 21 | > “Collaboration tools are a very big deal for us, because we have a high degree of collaboration across engineering and product and business lines. I know I'm probably understating that, but collaboration across Red Hat is huge,” Bryant said. 22 | 23 | The company also uses the kinds of open source project, program and community tools you would expect, as well as wikis and web Kanban boards for organizing tasks. 24 | 25 | > “A lot of these are developed organically, independently through the communities that we curate. We use Kanban boards to track progress. We measure using metrics that are established community by community and in terms of what Red Hat’s hoping to achieve or contribute. We use both publicly published metrics and internal metrics for custom boards,” says Bryant. 26 | 27 | The company also started using OKRs, or Objectives and Key Results. The framework is used to define and track business objectives and outcomes. Red Hat plans to use OKRs across projects to connect the business side of Red Hat with the work of product managers and engineering to better support long term objectives. 28 | 29 | Bryant says that “probably the most critical tool we use is IRC.” The acronym stands for Internet Relay Chat and it’s a system used for real-time communications between people anywhere on the planet. 30 | 31 | > “Most of us are working virtually in about five or six or different time zones. IRC is our virtual building, our team is there and collaborating on a conventional level,” she said. “We use a tool called Telegram to do non-sensitive logistics and coordination when are traveling at big events.” 32 | 33 | ## Measuring Success 34 | 35 | At Red Hat, success is defined differently for each open source project. 36 | 37 | > “When you talk about measuring upstream contributions and such, we actually go through a formal process on an annual basis, and then we refresh it several times a year to define what the success criteria are with the folks here at Red Hat who have the biggest stake in the project,” says Bryant. 38 | 39 | > “But in other cases, such as Fedora, where we have a lot of red hat contributors, we've started to measure the number of upstream contributions from other organizations, and not just from our own. For us, healthy ecosystems are a key goal, so we measure our successes partly by measuring how many other contributors there are.” 40 | 41 | Dave Neary, a senior principal software engineer working on SDN and NFV in the open source and standards office, added another example in Open Daylight. 42 | 43 | > “There is already an ecosystem of companies that contribute to Open Daylight, and there is a developer team inside Red Hat. Our goal could be to increase the adoption of Open Daylight as an FCN backend for OpenStack, for example. Or, it could be to increase the awareness of Open Daylight as an end-to-end solution. Then you would need to define and raise awareness and measure it,” he said. 44 | 45 | > “But the goals are going to be different from one project to another, where one project cares much more about developing the user community and other projects may care much more about developing a vendor ecosystem.” 46 | 47 | ## Acknowledgements 48 | 49 | We would like to thank Dave Neary (senior principal software engineer working on SDN and NFV in the open source and standards office and CTO’s office) and Deb Bryant (senior director, open source and standards, in the office of the CTO at Red Hat) for contributing content to this article, along with Pam Baker who performed the interviews. 50 | 51 | -------------------------------------------------------------------------------- /casestudies/salesforce.md: -------------------------------------------------------------------------------- 1 | # Salesforce 2 | 3 | [Salesforce](https://www.salesforce.com/) learned early on that open source projects stay healthy when they have a diverse community of stakeholders that have an interest in making the software succeed. 4 | 5 | [Apache Phoenix](https://phoenix.apache.org/) started at Salesforce as its own open source Phoenix project. But it didn’t find success until people from outside Salesforce also got invested and the project no longer depended on the needs and desires of one company. In a true community effort, people from other companies joined in and said, ‘this is useful for us and we want to contribute,’" says Ian Varley, a Software Architect at Salesforce who recently led the open source program there. In the end, this diverse community is what allowed it to become an Apache project and incorporate new features that the company’s own engineers could never have dreamed up. 6 | 7 | Salesforce stays focused on this concept of cultivating diverse interests to use and participate in its projects. At the same time, it’s equally focused on aligning its internal stakeholders – from engineering to legal, marketing and PR – with its open source efforts. 8 | 9 | ## Open source program goals at Salesforce 10 | 11 | Salesforce has many priorities around open source. The company’s open source strategy keeps everyone aligned. The dedicated open source program team circulates internal documents to the company’s engineering team that provide strategic guidance and encourage the creation and use of open source. The documents provide the foundation for an open source culture and let the team know in no uncertain terms that the company’s leaders are fully behind the strategy. 12 | 13 | Open source is increasingly a part of just about every software project in every company that’s out there. It stands to reason that every possible type of business model you can have with open source is going to come into being and try its hand in the market. 14 | 15 | Salesforce is a Software-as-a-service vendor, and doesn’t release the end customer-facing products that it sells as open source. Instead, the engineering team focuses on open sourcing shared infrastructure components, libraries, and tools that other companies might find generally useful, as well as samples, and SDKs that are of benefit to their customers. 16 | 17 | ## How Salesforce measures open source success 18 | 19 | One goal of the company’s open source program is building its reputation among developers. Engineers who may not use Salesforce products will sometimes look at the company’s open source projects and say, “Hey, this company is really involved with some great stuff,” Varley said. 20 | 21 | > “Open source is a window for (external developers) to see the great engineering that’s going on inside of the company that they otherwise wouldn’t be able to.” – Ian Varley, Software Architect at Salesforce. 22 | 23 | The open source program also focuses on expanding the communities that align behind the company’s own open source projects. The communities don’t just use their software, they also contribute to it. So they focus on creating “on ramps” to their projects such as a clear approval process for patches, improved documentation, healthy forums, and welcoming and responsive maintainers. 24 | 25 | > “We’ve succeeded when we have given people ways to get involved with our projects that don’t require them to have a PhD or to have been working in a similar area for 25 years. You need ways for them to get involved quickly,” Varley says. 26 | 27 | Salesforce also measures its own success against the industry-wide success of open source. The more progress there is in open source, in all of its many dimensions, the better off everyone is because more open source means more progress in the industry as a whole. If Salesforce can raise the baseline of what is commodity software and what constitutes shared components that everybody can depend on, the whole industry benefits. 28 | 29 | ## Example: Apache Phoenix 30 | 31 | Apache Phoenix is an open source big data analytics platform that’s now part of the Apache Software Foundation. But when Phoenix started, it was just a project a couple of Salesforce engineers built for some specific internal use cases. But, before long, the small team realized that anybody could benefit from the project and its velocity would improve if the whole world was working on it. So he made the pitch to open source it and turn it into a community project. 32 | 33 | Within the first year of creating the open source Phoenix project, the Salesforce engineers started getting significant contributions in functionality from two or three big companies that had found Phoenix and wanted to join the project. By opening the project up to outside use and contribution, the Phoenix project progressed far beyond what the original engineers would have been able to do on their own. 34 | 35 | ## 5 Key lessons for open source program managers 36 | 37 | Looking back at his 4 years of experience managing open source at Salesforce, Varley has five key lessons for companies that may just be getting started with their own open source programs: 38 | 39 | * Create a company-wide policy that strongly encourages the use and creation of open source internally. 40 | * Recognize that a community can advance a project far beyond what can be achieved internally. 41 | * Seek input on your open source program from many different types of stakeholders. Engineers should not be the only stakeholders—your legal team and executive management should also be directly involved, for example. 42 | * Focus on good “on ramps” to your open source projects with great set up documentation and healthy forums. 43 | * Recognize that open source success can drive industry-wide success and better products everywhere. 44 | -------------------------------------------------------------------------------- /images/building-leadership-in-an-open-source-community1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/building-leadership-in-an-open-source-community1.png -------------------------------------------------------------------------------- /images/building-leadership-in-an-open-source-community2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/building-leadership-in-an-open-source-community2.png -------------------------------------------------------------------------------- /images/building-leadership-in-an-open-source-community3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/building-leadership-in-an-open-source-community3.jpg -------------------------------------------------------------------------------- /images/building-leadership-in-an-open-source-community4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/building-leadership-in-an-open-source-community4.png -------------------------------------------------------------------------------- /images/building-leadership-in-an-open-source-community5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/building-leadership-in-an-open-source-community5.jpg -------------------------------------------------------------------------------- /images/building-leadership-in-an-open-source-community6.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/building-leadership-in-an-open-source-community6.jpg -------------------------------------------------------------------------------- /images/creating-an-open-source-program1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/creating-an-open-source-program1.png -------------------------------------------------------------------------------- /images/improve-open-source-dev-impact1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/improve-open-source-dev-impact1.png -------------------------------------------------------------------------------- /images/improve-open-source-dev-impact2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/improve-open-source-dev-impact2.png -------------------------------------------------------------------------------- /images/improve-open-source-dev-impact3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/improve-open-source-dev-impact3.png -------------------------------------------------------------------------------- /images/improve-open-source-dev-impact4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/improve-open-source-dev-impact4.png -------------------------------------------------------------------------------- /images/improve-open-source-dev-impact5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/improve-open-source-dev-impact5.png -------------------------------------------------------------------------------- /images/improve-open-source-dev-impact6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/improve-open-source-dev-impact6.png -------------------------------------------------------------------------------- /images/improve-open-source-dev-impact7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/improve-open-source-dev-impact7.png -------------------------------------------------------------------------------- /images/measuring-your-open-source-program1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/measuring-your-open-source-program1.png -------------------------------------------------------------------------------- /images/measuring-your-open-source-program2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/measuring-your-open-source-program2.png -------------------------------------------------------------------------------- /images/measuring-your-open-source-program3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/measuring-your-open-source-program3.png -------------------------------------------------------------------------------- /images/measuring-your-open-source-program4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/measuring-your-open-source-program4.png -------------------------------------------------------------------------------- /images/open-source-reading-list1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list1.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list10.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list10.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list11.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list11.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list12.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list12.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list13.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list13.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list14.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list14.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list15.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list15.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list16.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list16.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list18.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list18.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list19.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list19.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list2.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list20.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list20.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list3.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list4.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list4.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list5.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list6.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list6.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list7.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list7.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list8.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list8.jpg -------------------------------------------------------------------------------- /images/open-source-reading-list9.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/open-source-reading-list9.jpg -------------------------------------------------------------------------------- /images/starting-an-open-source-project1.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/starting-an-open-source-project1.jpg -------------------------------------------------------------------------------- /images/starting-an-open-source-project2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/starting-an-open-source-project2.jpg -------------------------------------------------------------------------------- /images/starting-an-open-source-project3.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/starting-an-open-source-project3.jpg -------------------------------------------------------------------------------- /images/tools-for-managing-open-source-programs1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/tools-for-managing-open-source-programs1.png -------------------------------------------------------------------------------- /images/tools-for-managing-open-source-programs2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/tools-for-managing-open-source-programs2.png -------------------------------------------------------------------------------- /images/tools-for-managing-open-source-programs3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/tools-for-managing-open-source-programs3.png -------------------------------------------------------------------------------- /images/tools-for-managing-open-source-programs4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/tools-for-managing-open-source-programs4.png -------------------------------------------------------------------------------- /images/tools-for-managing-open-source-programs5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/todogroup/guides/496e27b32928cb28fba8261140a4e978ad4d1596/images/tools-for-managing-open-source-programs5.png -------------------------------------------------------------------------------- /open-source-reading-list.md: -------------------------------------------------------------------------------- 1 | # Open Source Reading List 2 | 3 | 21 Must-read books for open source program managers, recommended by members of the [TODO Group](http://todogroup.org/) community. 4 | 5 | [New Frontiers in Open Innovation](https://www.amazon.com/Frontiers-Open-Innovation-Henry-Chesbrough/dp/0198803990/ref=sr_1_cc_1?s=aps&ie=UTF8&qid=1507753139&sr=1-1-catcorr&keywords=New+Frontiers+in+open+innovation), OUP Oxford, by Henry William Chesbrough (2014) 6 | 7 | An overview of research findings on open innovation in the enterprise. 8 | 9 | ![New Frontiers in Open Innovation](images/open-source-reading-list1.jpg) 10 | 11 | [The Open Organization: Igniting Passion and Performance](https://hbr.org/product/the-open-organization-igniting-passion-and-performance/13980-HBK-ENG), Harvard Business Review Press, by Jim Whitehurst (2015) 12 | 13 | Red Hat’s guide on how to structure and manage an organization that’s open source to the core, from the world’s first billion-dollar open source company. 14 | 15 | ![The Open Organization: Igniting Passion and Performance](images/open-source-reading-list2.jpg) 16 | 17 | [The Open Organization book series from Opensource.com](https://opensource.com/open-organization/resources/book-series) 18 | 19 | The open organization community turns Jim Whitehurst’s _The Open Organization_ into a book series, with installments including _The Open Organization Leaders Manual_, _The Open Organization Guide to IT Culture Change_, and _The Open Organization Workbook_. 20 | 21 | [Open Innovation: The New Imperative for Creating And Profiting from Technology](https://www.amazon.com/Open-Innovation-Imperative-Profiting-Technology/dp/1422102831), Harvard Business School Press, by Henry Chesbrough (2005) 22 | 23 | A foundational work that takes an academic view of how and why IT companies have effectively innovated through collaboration. 24 | 25 | ![Open Innovation: The New Imperative for Creating And Profiting from Technology](images/open-source-reading-list3.jpg) 26 | 27 | [Open Business Models: How to Thrive in the New Innovation Landscape](https://hbr.org/product/open-business-models-how-to-thrive-in-the-new-inno/an/4273-HBK-ENG), Harvard Business School Press, by Henry Chesbrough (2006) 28 | 29 | Builds on Chesbrough’s previous work and reads as a guide to making money through open innovation. 30 | 31 | ![Open Business Models: How to Thrive in the New Innovation Landscape](images/open-source-reading-list4.jpg) 32 | 33 | [Wikinomics: How Mass Collaboration Changes Everything](https://www.amazon.com/dp/B000QBYEH8/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1), by Don Tapscott and Anthony D. Williams, (2006) 34 | 35 | ![Wikinomics: How Mass Collaboration Changes Everything](images/open-source-reading-list5.jpg) 36 | 37 | [The Cathedral and the Bazaar](http://shop.oreilly.com/product/9780596001087.do): Musings on Linux and Open Source by an Accidental Revolutionary, O’Reilly Media, by Eric Raymond (1999) 38 | 39 | A seminal work that defined the open source movement and its role in the enterprise. 40 | 41 | ![The Cathedral and the Bazaar](images/open-source-reading-list6.jpg) 42 | 43 | [The Magic Cauldron](http://www.catb.org/esr/writings/magic-cauldron/) by Eric Raymond (1999) 44 | 45 | A free essay from The Cathedral & The Bazaar on the economics of open source. 46 | 47 | [Philosophy of the GNU Project](https://www.gnu.org/philosophy/philosophy.html), by Richard Stallman 48 | 49 | Whether you agree or disagree, it’s helpful to understand Stallman’s perspective. 50 | 51 | [Producing Open Source Software](http://producingoss.com/en/index.html): How to Run a Successful Free Software Project, O’Reilly Media, by Karl Fogel (2005) 52 | 53 | A guide to how successful projects operate, the expectations of users and developers, and the culture of free software. 54 | 55 | ![Producing Open Source Software](images/open-source-reading-list7.jpg) 56 | 57 | [Open Sources 2.0](http://shop.oreilly.com/product/9780596008024.do): The Continuing Evolution, O’Reilly Media, by Chris DiBona, Mark Stone, Danese Cooper 58 | 59 | A collection of essays on the impact open source has on diverse industries, from an experienced group of enterprise open source managers and advocates. 60 | 61 | ![](images/open-source-reading-list8.jpg) 62 | 63 | [The New Kingmakers](https://www.amazon.com/New-Kingmakers-Developers-Conquered-World-ebook/dp/B0097E4MEU), O’Reilly Media, by Stephen O'Grady (2013) 64 | 65 | Read this if you want to understand the role of developers in technology decision-making today. 66 | 67 | ![](images/open-source-reading-list9.jpg) 68 | 69 | [The Software Paradox](https://www.amazon.com/Software-Paradox-Rise-Commercial-Market/dp/1491900938), O’Reilly Media, by Stephen O’Grady (2015) 70 | 71 | Learn why the commercial software market has changed from a RedMonk analyst. 72 | 73 | ![](images/open-source-reading-list10.jpg) 74 | 75 | [The Art of Community: Building the New Age of Participation](https://www.amazon.com/Art-Community-Building-New-Participation/dp/1449312063), O’Reilly Media, by Jono Bacon (2012) 76 | 77 | An essential guide to creating and working with open source communities from former Ubuntu community manager Jono Bacon. 78 | 79 | ![](images/open-source-reading-list11.jpg) 80 | 81 | [Open Sources: Voices from the Open Source Revolution](http://www.oreilly.com/openbook/opensources/book/index.html), O’Reilly Media, by Eric S. Raymond (1999) 82 | 83 | A free collection of essays from some of the early leaders in open source. 84 | 85 | ![](images/open-source-reading-list12.jpg) 86 | 87 | [Codev2](http://codev2.cc/), by Larry Lessig (2005)[ http://codev2.cc/](http://codev2.cc/) 88 | 89 | A classic treatise on Internet regulation and the role of code as a form of law. 90 | 91 | ![](images/open-source-reading-list13.jpg) 92 | 93 | [Open Source for Business: A Practical Guide to Open Source Software Licensing, 2nd Edition](http://www.pdffull.co/files/book.php?id=1544737645) by Heather Meeker 94 | 95 | Read this to understand open source software licensing. 96 | 97 | ![](images/open-source-reading-list14.jpg) 98 | 99 | [The Open Source Alternative](https://www.amazon.com/Open-Source-Alternative-Understanding-Opportunities/dp/0470194952/ref=pd_sim_14_2?_encoding=UTF8&psc=1&refRID=TRNY5HWZJ8WXZJFPW2A1), Wiley, by Heather Meeker (2008) 100 | 101 | A user manual for understanding open source licensing issues in business. 102 | 103 | ![](images/open-source-reading-list15.jpg) 104 | 105 | [“The Success of Open Source”](https://www.amazon.com/dp/B002OSXS0U/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1), by Steven Weber 106 | 107 | Great for understanding the significance of open source from an outsider’s perspective. 108 | 109 | ![](images/open-source-reading-list16.jpg) 110 | 111 | [http://www.amazon.com/Intellectual-Property-Open-Source-Protecting/dp/0596517963](http://www.amazon.com/Intellectual-Property-Open-Source-Protecting/dp/0596517963) – Intellectual Property and Open Source, by Van Lindberg 112 | 113 | A book on open source licensing from an engineer’s rather than a lawyer’s perspective that includes a little history of the relevant laws. Why do we have trademarks? Why do we have copyright? Etc. 114 | 115 | ![](images/open-source-reading-list18.jpg) 116 | 117 | [Managing 3rd-Party Software Licenses,](https://www.amazon.com/Managing-3rd-Party-Software-Licences-ebook/dp/B01JJC7LD8) Self-published, by Giles Middleton (2016) 118 | 119 | A quick read that covers a lot of ground. 120 | 121 | ![](images/open-source-reading-list19.jpg) 122 | 123 | [The International Free and Open Source Software Law Book](http://ifosslawbook.org/), Open Source Press, by Ywein Van den Brande, Shane Coughlan, and Till Jaeger (2014) 124 | 125 | A free and fascinating read on how different countries’ laws affect open source licences by preeminent attorneys in FOSS law. 126 | 127 | ![](images/open-source-reading-list20.jpg) 128 | -------------------------------------------------------------------------------- /participating-in-open-source.md: -------------------------------------------------------------------------------- 1 | # Participating in Open Source Communities 2 | 3 | Open source has become the de facto way to build software – not only in tech, but across diverse industries. As companies use open source code to build their own commercial products and services, they also see the strategic value of contributing back to those projects. 4 | 5 | However, diving in without an understanding of those projects, their communities, and how they operate can lead to frustrations for those companies as well as the open source communities. Approaching open source contributions without a strategy can tarnish a company’s reputation in the open source community and incur legal risks. 6 | 7 | This guide covers what it means to contribute to open source as an organization and how to become a good corporate citizen. Learn how open source projects are structured, how to contribute, why it’s important to devote internal developer resources to participation, and why it’s important to create a strategy for open source participation and management. 8 | 9 | **Table of Contents** 10 | 11 | - [Why contribute to open source?](#why-contribute-to-open-source) 12 | - [How open source projects are managed](#how-open-source-projects-are-managed) 13 | - [How contributions work](#how-contributions-work) 14 | - [What it means for an organization to contribute](#what-it-means-for-an-organization-to-contribute) 15 | - [How to be a good corporate citizen when participating in an open source project](#how-to-be-a-good-corporate-citizen-when-participating-in-an-open-source-project) 16 | - [Best practices to contribute code upstream](#best-practices-to-contribute-code-upstream) 17 | - [How to create your open source contribution strategy](#how-to-create-your-open-source-contribution-strategy) 18 | - [11 tips for mastering open source contributions](#11-tips-for-mastering-open-source-contributions) 19 | - [Final words](#final-words) 20 | 21 | ## Why contribute to open source? 22 | 23 | It might be impossible to find an organization today that doesn’t benefit in some way from open source software. Some companies, like Intel, IBM, and Samsung, have entire open source programs devoted to contributing to open source communities. Other companies become consumers of open source almost accidentally when the software is brought in by system administrators or developers. 24 | 25 | Many companies are commercially dependent on open source software that is critical to the success of the company, so it becomes advantageous (and necessary) to contribute to open source software projects. Since 2005, more than 13,500 developers from more than 1,300 different companies have contributed to the Linux kernel, and it is just a single project! 26 | 27 | > “For many larger projects, we know that most of our contributors are going to be people who work at companies that need to use projects like Ceph and Gluster. We have customers, and customers often contribute to software because they're using it. We consider both the individual participation and the company participation as success stories.” [Stormy Peters](https://twitter.com/storming) – Senior Manager, Community Leads at Red Hat 28 | 29 | While some of these contributions may come from organizations that just want to give back to the community, there are plenty of strong business reasons to contribute to the open source software projects used within your organization. Here are just a few of the benefits of contributing: 30 | 31 | * **Attract talent.** When you rely on open source software, the best place to find people who know the project inside and out is in the community for that project. By working publicly in the community, you can attract people who see that they can get paid to work on their favorite open source project. When your employees are working side by side with these people every day, they can help you identify good fits for your company. (See also: our guide on Recruiting Developers.) 32 | * **Lower maintenance costs.** Companies that start fixing bugs or adding new features and functionality to an open source project without contributing them back into the upstream project quickly learn that upgrading later to add new features or apply security fixes can be a nightmare that drives maintenance costs through the roof. Contributing your changes back into the upstream project means that they will automatically be included in future updates without incurring additional maintenance costs. 33 | * **Influence the direction.** In an open source project, new features and functionality come from contributions that inevitably influence the project’s direction. If you want a project to offer functionality important to your organization, then you need to have active contributors who can any implement potential changes. Through your contributions, you can influence the project’s direction (assuming that your changes align with the project’s goals). 34 | 35 | However, you need to be a bit careful about how you engage these communities to avoid perception problems or other issues with your contributions. Every open source project has slightly different norms, expectations, and processes that need to be thoroughly understood before your organization should begin contributing. This can be achieved by having someone join the community and spend some time observing, or you can hire someone who already has a proven track record of participation in the community. 36 | 37 | ## How open source projects are managed 38 | 39 | At first glance, open source projects may look chaotic. People who are completely new to open source software often wonder how a group of random people can throw code together and end up with a stable product used by millions of people. It doesn’t take long to realize that this isn’t how open source software works. Almost every open source project has some structure, and the best projects will have the structure and project governance clearly described on the project website or in the documentation. (GitHub’s guides for contributors have a great overview of project anatomy.) 40 | 41 | While the exact governance model varies widely across projects, there are some commonalities: 42 | 43 | * **Leader:** At a minimum, there should be someone responsible for making final decisions about features, releases, and other activities. In some cases this is a single person – for example, Linus Torvalds is the original author of the Linux kernal and has the final say on anything related to its evolution. In other projects, there may be one or more committees responsible for various aspects of a project, like the Core Technical Committee that governs the Node.js project. 44 | * **Maintainers:** Most leaders delegate some of the decisions to people who are responsible for maintaining specific parts of the project. In large projects, these maintainers may also delegate to people who are responsible for subcomponents of their portion. For example, Linus Torvalds delegates Linux kernel documentation decisions to Jonathan Corbet. 45 | * **Committers:** Some projects also have groups of people who have contributed to the project and are considered reliable and responsible enough to be allowed to commit directly to all or some parts of the project, rather than having to submit to a maintainer for review. Contributions from committers are still subject to review by maintainers or project leaders and may be reverted if there are any concerns. 46 | * **Contributors:** Many people contribute to open source projects with code, documentation and other enhancements. These contributions are usually subject to a review from an experienced committer and/or maintainer before they are included. 47 | * **Users:** Arguably the group most important to an open source project’s growth and development. Users give the project a purpose and help it evolve. These valuable members of the community can provide feedback about features, bug reports and more. 48 | 49 | Community can make or break an open source project. Having a strong, vibrant, and diverse open source community is important to a project’s success. All of the people in the roles listed above are part of this community, along with people filling other critical roles in the project for documentation, marketing, user support, and so much more. 50 | 51 | ## How contributions work 52 | 53 | The contribution process varies depending on the open source project. For example: 54 | 55 | * Projects have different guidelines with information about coding style, language, formatting, bug/ticket numbers, release timing, and more. 56 | * Some projects require signed contributor agreements, while others have signed-off-by or other processes. 57 | * Projects may require patches to be posted to the mailing list, but others will ask for pull requests. 58 | 59 | These are just a few ways that the contribution style might differ, so it’s important to start by reading the documentation about how to contribute. Many projects will include this documentation as a CONTRIBUTING or README file in the home directory of the code repository. Otherwise, you may need to dig into the documentation or community section of the website to find it. It’s also a good idea to read some of the other documentation, community guidelines, and code of conduct if they are available to make sure that you understand exactly what behavior is expected within a particular project. 60 | 61 | If you are a first-time contributor to a project, you might consider finding a mentor or an experienced project member who can review your work and provide you with some feedback as you prepare your first couple of contributions. 62 | 63 | After submitting a contribution using the process described in the documentation, you must remain available to respond to feedback. Common feedback would include questions about how something works or why you chose a particular approach, along with suggestions for improvements or requests for changes. This feedback can be tough sometimes, so it helps to assume that the feedback is in the spirit of making your contribution better. Avoid getting defensive. You may need to go through several rounds of resubmission and additional feedback before your code is accepted, and in some cases it may be rejected. There are many valid reasons why something might not be accepted, so don’t take it personally if your code is rejected. If possible, try to learn more about why your contribution was not accepted to help increase the chances of getting your next contribution included. 64 | 65 | Keep in mind that if your contribution was accepted, you may be expected to maintain it over the long-term. This is especially true for large contributions, new features, or standalone code, like a driver for a specific piece of hardware. For small contributions and bug fixes, it is unlikely that there will be any long-term maintenance expected. 66 | 67 | ## What it means for an organization to contribute 68 | 69 | Over the years, the relationship between some open source projects and the companies or other organizations that use or contribute to those projects has been a bit rocky. Organizations are often accustomed to forming business relationships in ways that don’t usually work for open source projects, so some organizations struggle to understand how to contribute productively. 70 | 71 | Another challenge is that an organization can seem self-serving or troublesome if its needs aren’t aligned with the needs of the open source project. This can cause an open source community to become suspicious of the motives behind an organization’s contributions. In the past, some organizations have tried to make huge contributions that weren’t aligned with the goals of the project, and in certain projects, this history may make it harder for the community to trust organizations. 72 | 73 | However, there are also many success stories. One is the Linux kernel, where organizations contribute in meaningful ways. The most common and easiest way for an organization to contribute to an open source project is to pay employees who have a significant amount of time devoted to participation in open source projects. In order for this to be successful, those employees need to understand the contribution processes and norms within that project to increase the chances that their contributions will be accepted. If your organization is new to a project or new to open source, consider hiring someone who has already contributed and is known within the open source project you want to contribute to; they can provide guidance on contributing successfully. Experienced contributors might be willing to mentor your employees as they pursue an open source career path. (See our guide on Recruiting Open Source Developers.) 74 | 75 | ![](https://www.linuxfoundation.org/wp-content/uploads/2017/08/Kubernetes-contributors-pie-chart.png) 76 | 77 | Most projects offer other ways for organizations to participate, but these are likely to vary by project. Open source projects and the foundations that support them often need resources that organizations can provide, including infrastructure, funding, marketing, legal services, and much more. Many projects allow companies to sponsor or join a project more formally by contributing funding and/or people in exchange for some advisory role in the project or enhanced visibility. 78 | 79 | For example, the Node.js Foundation Board of Directors consists of representatives from corporate members, a representative of the Technical Steering Committee, and representatives elected by the individual membership class. The corporate members comprising a portion of the board pay anywhere from $5,000 for a small organization to $250,000. While each project has a slightly different approach to sponsorship or membership, funding an open source project helps cover expenses and fund its continued success. 80 | 81 | ## How to be a good corporate citizen when participating in an open source project 82 | 83 | If there is an underlying theme for this guide and for open source in general, it’s that every project is different. Every time you join an open source project, you’ll need to spend some time finding your way around and learning how it works. 84 | 85 | For organizations participating in an open source project, each employee will need to go through this learning process for each project they participate in. Here are a few things that can help you get started off on the right foot. 86 | 87 | * **Join the community.** Each community has slightly different participation modes and channels. Read the documentation to find out about the community, and join the key communication channels, which may include mailing lists, forums, IRC, Slack, bug trackers, source code repositories, and more. 88 | * **Lurk first.** After you've joined the community, spend a significant amount of time lurking and reading the archives to soak up the culture before you start contributing. You’ll want to understand the norms and expectations of this community before you participate. The more time you spend reading and listening, the more likely it is that your first contribution will be well received. 89 | * **Understand the governance.** Read the documentation or website sections about project governance and leadership before contributing. You’ll want to know who makes decisions about different types of contributions, and how. 90 | * **Start small.** Tackle a simple bug or documentation fix to start. It will be easier to learn the process and correct mistakes on a small contribution that isn’t critical to your organization’s needs. Make your mistakes on small and less significant contributions as you work up to the more complex contributions that your organization needs. 91 | 92 | Now that your organization has figured out how to make those first small contributions, you’ll need to build on those contributions to begin making larger contributions and having a bigger impact in the project. 93 | 94 | * **Build relationships at events.** Relationships on a personal and organizational level are an important aspect of participating in an open source community. One of the best ways to build lasting relationships with other project members is by attending events. There is nothing quite like meeting someone in person to better understand them as a human being on the other side of their email address or online handle. These events attract a varied mix of people, from project leaders and passionate users to organizations that support projects through sponsorships, booths, and demos. Most of these events would not be possible without financial support from sponsoring organizations that allow us to get together and learn from each other while helping to achieve the goals of the project. 95 | * **Include the community early and often.** Some organizations make the mistake of developing big chunks of code in house and then dumping them into the open source project, which is almost never seen as a positive way to engage with the community. The reality is that open source projects can be complex, and what seems like an obvious change might have far reaching side effects in other parts of the project. Any significant change is likely to require some community discussion before it moves to implementation to make sure that there are no side effects and that the solution is aligned with the broader goals for the project. While you discuss it with the community, it can help to focus on the problem, rather than a specific solution, before you invest too much time in the creation of a body of code. (See Jon Corbet’s guide on [How to Participate in the Linux Kernel Community](https://www.linux.com/publications/how-participate-linux-community).) 96 | * **Contribute upstream.** This refers to the practice of sending any changes you make to an open source project back to the original maintainers for inclusion into an upcoming release of the software. If your organization is new to open source, you may need to spend some time educating your employees about the importance of upstreaming contributions. In some cases, people may think it will be easier to do a quick and dirty patch to get something working in your infrastructure and not bother with cleaning it up and going through the process of getting it accepted into the upstream project. 97 | 98 | However, over the long-term, the quick patch that needs to be tested, updated and reapplied during every upgrade cycle is almost always going to take more time and effort than upstreaming it. This behavior can also be perceived as selfish within the community, since others might also benefit from your fixes, so it could also harm your organization’s reputation in open source communities. 99 | 100 | ### Best Practices to Contribute Code Upstream 101 | 102 | #### Internal to your organization 103 | 104 | 1. Decide to upstream for the right reasons. 105 | 2. Design and implement code with upstreaming in mind. 106 | 3. Adopt an “upstream first” policy. Submit patches upstream first, and consume in your own products downstream. 107 | 4. Keep your developers involved in the open source project, even if it is just a soft involvement. 108 | 109 | #### Externally/toward the project 110 | 111 | 1. Ensure that your contributions are useful to others. 112 | 2. Follow proper coding style. 113 | 3. Work within the submission processes of the project. 114 | 4. Provide documentation and explanation around your contributions. 115 | 5. Listen to feedback and act upon it. 116 | 6. Be patient and continue to rework the code until acceptance. 117 | 118 | One of the most challenging things for organizations is understanding how influence is earned within open source projects. Just because your organization is a big deal, doesn’t mean that you should expect to be treated like one without earning the respect of the open source community. Influence comes from participation. Some of the people contributing to an open source project will eventually earn positions of greater influence and leadership over time after they prove that they are reliable and responsible. 119 | 120 | You should also expect some conflict and be ready to handle it professionally. The review process can get quite heated as people disagree with decisions, approaches or styles of contributions. It’s important to remain calm and professional while making sure that the feedback stays focused on the contribution rather than becoming personal. Keep in mind that your participation in an open source project is public and could remain on the internet forever, and one heated discussion that gets out of hand can come back to haunt you as an organization or an individual at a later date. Because all of this participation is very public, offering some training about handling difficult people and resolving conflict for your employees might be a good idea. 121 | 122 | ## How to create your open source contribution strategy 123 | 124 | Having a deliberate and thoughtful open source contribution strategy not only helps guide your employees when participating in open source projects, but it can also help justify this participation to senior management within your organization. It’s important to start by looking at your organization’s overall business goals to figure out how your open source efforts fit into your broader strategies. (See our guide on Creating an Open Source Business Strategy.) By clearly tying your open source contribution strategy to the organization’s strategic efforts, you can show senior management why the work is important and help your employees understand the impact of their contributions. 125 | 126 | > “Support from leadership and acknowledgement that open source is a business critical part of your strategy is so important. You should really understand the company’s objectives and how to enable them in your open source strategy.” [Nithya Ruff](https://twitter.com/nithyaruff) – Senior Director, Open Source Practice at Comcast 127 | 128 | Once you've developed some goals and strategies that are aligned with the business goals, you’ll need to develop an implementation plan. These questions will help you think about some of the things that might need to be addressed in your plan: 129 | 130 | * **Why are these contributions important?** It’s easy to jump in and start talking about all of the great things you plan to do, so don’t forget to include compelling arguments for why this work is important and strategic to the organization. 131 | * **Which open source projects do we use within the organization?** Take some time to assess which open source projects are already in use across the entire organization to determine which ones are strategic to your business. A few places you might want to focus your assessment: critical business infrastructure (operations), development and deployment tools that impact your ability to release products, and software that is important for customer-facing products or services. 132 | * **Which projects should we target for contribution?** Most organizations use many open source projects, so it’s important to make sure that your plan focuses on just the most important ones. Just because a project isn’t on the target list doesn’t mean that people can’t contribute to that project; it just means that it isn’t a critical focus for your organization. If an open source project is critical to your business and has the potential to cause significant downtime or disruption to your ability to serve your customers, it’s probably a good candidate for contributions. 133 | * **What are the contributions we are already making?** In some cases, you might already have people making changes to open source projects. They may be creating patches that are used internally, or they could already be contributing those patches back to the upstream project to avoid maintaining them. Spend some time talking to your internal teams to find potential contributions that you can build on while assessing whether or not you already have people on staff who might have the skills and interest to contribute. 134 | * **Do we already have the relevant expertise, or do we need to hire for it?** As discussed previously in this guide, it’s important to find people who have both the skills to create the contribution along with the people skills to work with the community to have the contribution accepted. If you already have people contributing to some of these projects, you might be able to use existing staff. If not, you should consider hiring someone who is already making successful contributions to the project. As with any plan, you need to make sure that you have the resources and hiring budget required for it to be a success. 135 | * **What funding do we need for project sponsorships/corporate memberships?** Look at the governance models for the projects you've selected to determine whether there is an option for corporate membership or sponsorship for the project or the foundation responsible for it. This provides funding to help the project be successful, and in some cases, it can help your organization get more involved in an advisory role or provide some influence into the project. In addition to funding projects directly, consider sponsoring related conferences. These can be great for getting the word out about your work and for meeting people who you might want to recruit. 136 | * **How should we promote our open source efforts?** Depending on your organization, marketing or promoting your open source contributions can be tricky. Therefore, it’s important to include this in your implementation plan to make sure that everyone knows how you discuss your contributions in public. Sponsorships and giving talks at the project’s conference or other events can be a good way to promote the work that you are doing and recruit contributors. In particular, don’t overlook your participation in local user groups where you have employees. Sponsoring those local groups and sending contributors to give talks can be a great way to recruit local people who are passionate about particular open source projects. 137 | * **What contribution guidelines or processes do we need?** These guidelines and processes should be less about rules and regulations and more about helping people be successful in making contributions to open source projects. It can help if people have guidelines and checklists to make sure that they have everything they need to make a successful contribution without running into licensing or confidentiality issues. Especially for new contributors, it can also help to have an internal review process available as a safe place to get feedback before making a contribution. 138 | * **What kinds of training must we provide?** Training on best practices for making contributions, along with some general training about open source licenses, governance, and norms associated with participation in open source communities, can be very useful. Training on conflict resolution, dealing with difficult people, and other people skills can also help avoid issues later. To scale your efforts over time, include in your training plan some programming that provides experienced open source contributors as mentors for new contributors. 139 | * **How will we determine whether the plan is successful**? Every plan should include success criteria and a plan for measuring whether you achieved your goals. This should come directly out of your strategies to make sure that you are tracking those activities that are the most important for your organization, rather than the ones that are the easiest to measure. The open source [GrimoireLab](http://grimoirelab.github.io/) project is a good place to start if you need measurement and metrics tools. (See our guide on How to Measure Open Source Program Success.) 140 | * **Do we need an open source office to manage all of these efforts?** Having an open source program office or dedicated staff who are responsible for implementing the plan can help you navigate this terrain. At a minimum, you’ll want to have someone responsible putting processes and training in place, providing licensing guidance, answering questions from senior management or contributors, and communicating updates throughout the organization. (See our guide on Creating an Open Source Program Office.) 141 | 142 | 143 | ## 11 Tips for Mastering Open Source Contributions 144 | 145 | How to build a healthy environment for open source contributions in your organization: 146 | 147 | 1. Establish a policy and process to guide open source contributions 148 | 2. Set up a team to oversee approvals for all open source contributions 149 | 3. Focus contributions in the areas that will enable your technologies 150 | 4. Provide the needed IT infrastructure and tooling for contributors 151 | 5. Offer training to your staff on contribution best practices 152 | 6. Track contributions, measure impact, improve, and communicate 153 | 7. Establish a mentorship program to train less experienced developers 154 | 8. Provide contribution guidelines, how-tos, do’s and don’ts 155 | 9. Make open source legal support accessible to developers 156 | 10. Hire from the open source communities you value the most 157 | 11. Always follow the community processes and practices specific to each project 158 | 159 | ## Final Words 160 | 161 | Open source projects are here to stay, and they play a critical role in the ability for most organizations to deliver products and services to customers. If your organization wants to influence the open source projects that drive your success, you need to participate. Having a solid contribution strategy and implementation plan puts you on the path towards being a good corporate open source citizen. Good luck! 162 | 163 | ## Acknowledgements 164 | 165 | Contributors: 166 | 167 | ![](https://www.linuxfoundation.org/wp-content/uploads/2017/08/stormy_thumb.png) 168 | Stormy Peters 169 | Senior Manager, Community Leads 170 | Red Hat 171 | 172 | ![](https://www.linuxfoundation.org/wp-content/uploads/2017/08/Nithya_thumb.png) 173 | Nithya Ruff 174 | Senior Director, Open Source Practice 175 | Comcast 176 | 177 | *These resources were created in partnership with the TODO (Talk Openly, Develop Openly) Group – the professional open source program networking group at The Linux Foundation. A special thanks goes out to the open source program managers who contributed their time and knowledge to making these comprehensive guides. Participating companies include Autodesk, Comcast, Dropbox, Facebook, Google, Intel, Microsoft, Netflix, Oath (Yahoo + AOL), Red Hat, Salesforce, Samsung and VMware. To learn more, visit: [todogroup.org](http://todogroup.org/)* 178 | -------------------------------------------------------------------------------- /shutting-down-an-open-source-project.md: -------------------------------------------------------------------------------- 1 | # Shutting Down an Open Source Project 2 | 3 | This Open Source Guide is designed to offer advice about how your enterprise and your development team can plan for the day when you are ready to end or move away from an unneeded open source project. By shutting down the project gracefully or by transitioning it to others who can continue the work, your enterprise can responsibly oversee the life cycle of the effort. In this way, you can also set proper expectations for users, ensure that long-term project code dependencies are supported, and preserve your company’s reputation within the open source community as a responsible participant. 4 | 5 | This guide will help you decide when a project is no longer useful, understand how to disengage from a project, and determine what to do about its code, repositories, websites, wikis, and other project assets as you head in a new direction. 6 | 7 | ## Lifecycle planning for your open source project 8 | 9 | As software developers start to envision and develop new and needed business-critical open source projects, they should also incorporate clear and specific plans for each project’s complete life cycle, from its birth to its eventual demise. Such planning should also be conducted as part of a company’s overall open source strategy, incorporating all of the projects it oversees. 10 | 11 | These efforts could mean planning for a future shuttering of a project, a transfer of its operations to another interested group of users, or a corporate pull-out from the initiative. Such end-of-life planning is part of the responsibility that enterprises have for projects, their users, and for the open source community that sustains it all. These plans are necessary to allow such transitions to be conducted gracefully for other users if a project is ended or transferred. 12 | 13 | ### Why life cycle planning is important 14 | 15 | Planning for the potential end of an open source project isn’t unique. Similar life cycle planning is done for proprietary software initiatives, IT systems hardware deployments, and a wide range of other business decisions. For an open source initiative, project life cycle planning could include the traditional life cycle evaluations, such as an outline of the project’s scope and vision and estimates for its growth, as well as open source-specific categories like planning for community building and early user adoption and incorporating user feedback and contributions. 16 | 17 | It’s natural for any project to undergo development slowdowns or for user adoption to peak and then decline. Even highly successful open source projects may eventually stop being useful to their creators or users as business plans change or new technologies and innovations replace them. Thus, an exit plan is critical to ensure a smooth transition. 18 | 19 | ## What does a dead open source project look like? 20 | 21 | If the steady flow of contributions or commits to your open source project has fallen off, that doesn’t necessarily mean a project is dead. It may simply mean that the project is mature, has achieved its development goals, and is serving its users without requiring much upkeep or updating, which could be a good thing. 22 | 23 | On the other hand, if the number of people adopting the project and using the code has declined significantly, that could be a sign that interest is waning and the project may be dying. Other relevant metrics can include the level of project activity in general and whether users are posting inquiries and joining online discussions about the code. 24 | 25 | ### Trouble signs to watch for 26 | 27 | A dead or dying project can also be indicated by problems, such as unresolved differences about the direction of development or through lost energy from formerly involved contributors, who may have moved on to other projects that better capture their interest. An obvious sign is a decline in the project that coincides with members of your team or the community asking questions about whether it should continue, be ended, or left outright. Another indicator is that the code is no longer being patched or updated by the community to resolve vulnerabilities. 28 | 29 | > “If you don’t have anybody asking questions, if nobody’s making contributions, if there doesn’t seem to be any new adoptions, nobody seems to be adding dependencies, and if you're not seeing any other signs the people are using it, that’s a potential big warning sign. It may all be fine, but it’s worth checking to see if the project is dying.” – Dr. David A. Wheeler, open source expert and lead for two projects with The Linux Foundation’s [Core Infrastructure Initiative](https://www.coreinfrastructure.org/) (CII) 30 | 31 | These signs can be tricky to gauge even with hard data, since your code often may be accessed indirectly through package managers for other applications, rather than via direct downloads. This can make it hard to know exactly how many users you have and can accurately track as a project goes through its life cycle. 32 | 33 | ## Why plan for the end of a project before you even launch it? 34 | 35 | As you plan your open source project, related decisions about how you might someday end or transition the project are a critical part of the project’s life cycle. 36 | 37 | Why is that? Because pulling out of a project without a plan to protect its community and users can substantially harm an organization’s reputation within the open source community and the project itself. If you manage an open source software project, remember that others depend on it and that their continued use of it depends in part on your management and administrative efforts. Certainly your company can choose to change a project’s direction or status, but part of your responsibility is to clearly, quickly, and openly communicate such changes to a project’s users so they can plan for their own needs. It would be irresponsible to close a project and take down its code without communicating those intentions to users. 38 | 39 | ### Protect your company’s reputation 40 | 41 | Leaving other users in a lurch is not something you want to do. In the world of open source, this issue should not be taken lightly. That doesn’t mean your potential exit plans need to be made in detail even before you get the project underway, but frequent, open communication will help assure users that you will not drop a project without adequate notice and that you will work to prevent users from being left hanging. In addition, by building, developing, and promoting code that is easily forkable, your project can offer flexible transfer capabilities to others if you should decide to end your own involvement in the project. Although you need not announce a full disengagement procedure in your life cycle plans, you can still let users know that you intend to close or transition the project smoothly and responsibly. 42 | 43 | ### Seek a diverse contributor base 44 | 45 | Having a diverse group of code contributors is important to help your project grow by bringing in new ideas, deeper problem-solving capabilities, and more developer eyes on the code. It’s also helpful later if you decide to end or leave your project. With a diverse community involved in the effort, you could have have interested community members who potentially want to maintain it, broadening your options for future transition. If you do decide to leave a project, you would likely prefer to hand it off to other people who care about and will continue it, rather than announce its demise. 46 | 47 | These early steps lay the groundwork for project success by establishing a level of trust that will allow a healthy ecosystem and commercial dependencies to be built around your project. 48 | 49 | > “When you're starting your project, you're trying to get people to trust you and allay their fears about joining the project and using your code. Later, if you say, ‘Hey, this project’s going to go away soon,’ that is not going to help with trust. Instead, you should say you're going to do your best to make it work out if it will ever be ended, and that you promise not to just drop users. Tell them you’ll let them know what is happening at each step. Give them time to transition, and work on ways to help with the transition. That can be very helpful.” – Dr. David A. Wheeler, open source expert and lead for two projects with The Linux Foundation’s [Core Infrastructure Initiative](https://www.coreinfrastructure.org/) (CII) 50 | 51 | ## Deciding when to end, transfer or pull out of a project 52 | 53 | Whatever the reason, there may come to decide whether an open source project should be ended or transferred to another entity or whether your enterprise should end its participation in the project. It could be because your business goals have changed and that the project no longer corresponds with your new direction. Or, maybe it’s because a key person or team that headed the effort leaves the company, or that project performance metrics such as participation, updates, and usage are declining drastically based on your latest user data. It’s also possible that disagreements have arisen among community members about the future of the project and it looks like changes may be needed. 54 | 55 | ### Disagreements can influence new project directions 56 | 57 | If disagreements have arisen about the project inside the community – whether about its scope, technical matters, licensing or other issues – then you might consider splitting the project to allow interested parties to pursue what’s important to them. A similar quandary helped inspire developer Linus Torvalds to create Linux back in 1991. Torvalds had been experimenting with Minix, a small UNIX-like operating system kernel developed by Andrew S. Tanenbaum to teach college students about coding. Torvalds created Linux after he decided Minix had a radically different scope and vision, leaving him to create his own separate operating system. 58 | 59 | The scope of projects can certainly change over time and be readjusted as needed, but if it the project is simply no longer needed, then it can be a candidate for dissolution or transfer. Projects can even be repurposed to either find a way to make your existing users happy or to incorporate a functionality that needs new users. Ultimately, however, if you have software and nobody needs it, then the project is probably finished. Even if it’s the best software in the world, if nobody needs that capability, then nobody cares. 60 | 61 | > “That definitely does happen in different ways. We could stop using the project and its code because we just moved on to other things, or maybe the people who are maintaining it are now working on different things or have even left Facebook. Maybe nobody’s there supporting it and we're also not using it in our own apps. Some projects are contained enough that they're basically done being used.” – Christine Abernathy, Open Source Team Developer Advocate at Facebook 62 | 63 | ### Examples from the user trenches 64 | 65 | For business users, a wide range of factors affect decisions on whether open source projects should be ended. At software maker Autodesk, where some 190 open source projects are homegrown and in use, declining participation in a project’s development is seen as a clear indicator of code that might be past its prime, which can lead to placing a formerly thriving project into “maintenance mode.” Under that designation, the code is no longer actively maintained and if users have questions they may or may not be answered. In such a case, community members of the project can still use it, but no community support is provided. 66 | 67 | Similar usage indicators, including patch and maintenance requests, are monitored at Facebook, where some 400 open source projects have been homegrown so far, to periodically review the fates of ongoing projects. And at Capital One, where about 20 open source projects have been started in-house and are in use, projects are regularly transferred to other organizations or shut down depending on the needs of the company. 68 | 69 | ## How to end an open source project 70 | 71 | Whatever you do to end or transfer an open source project, perhaps the most important move you can make is to be candid with users at every step. Being open about your intentions helps establish trust for future work with all potential developer communities. 72 | 73 | Once you've decided to make the move, you must determine whether to end it, transfer it to another organization, or just pull out and end your direct involvement. 74 | 75 | ### How transfers can be helpful 76 | 77 | By transferring the project to another organization that wants to continue to maintain it, you can then directly assist in the transition of the project’s data and other resources. This approach can help reduce the worry and risks of the existing community and its users. If the project has used common or standard interfaces, it will likely be easier to extract and move embedded data or replace it with another similar component if needed. That won’t always work, of course, because clearly some open source projects are unique. However, providing and using standardized interfaces early in the project life cycle can help make these transition efforts easier. 78 | 79 | > “The best practice is to just be upfront and clear with the state of your projects. If you're no longer supporting a project, or you're in the process of winding it down, make that painfully obvious to anybody that would stumble across your code. You want them to see it’s no longer being maintained so new users don’t start using it and have this unwritten expectation that it is out there and that you are sponsoring this project and developing it.'” – Jared Smith, Open Source Community Manager at Capital One 80 | 81 | ### Make needed updates when transferring projects 82 | 83 | Transferring a project has the added benefit of continuing to make the code available to other users, long after it was first created and nurtured by its original development community. Of course, more than just code will be affected. There’s also the documentation, Contributor License Agreements (CLAs), the project repository, wikis, websites to transfer, as well as some potential support infrastructure which will need to be reviewed and updated. Transfers can be done through an actual transfer procedure or by forwarding the project domains and other resources to a new user group. 84 | 85 | In lieu of transferral, the project can be moved to a new host home and accessed by sending community members to a referral site where it is continued, rather than completely disengaging from it. 86 | 87 | > “It doesn’t happen all the time, but in the past with one of our projects we moved it over to a different company. We don’t have any hard and fast rules about doing this. Typically, we’ll just move it to a different organization. When it comes to moving within groups, we sort of shop around internally and find out whether it is still being used by someone. With our open source projects, we strive toward internal adoption. So, it might be used by an entirely different team. If they are willing to maintain it, then we move it to a different team, and that’s very easy. That just means changing a label somewhere where it says who’s the owner.” – Christine Abernathy, Open Source Team Developer Advocate at Facebook 88 | 89 | ### Killing a project outright 90 | 91 | Some organizations may simply want to kill an outdated project and retire its efforts for a myriad of reasons, from legal concerns to competitive pressures. The direction your enterprise ultimately takes is up to you. In this case, the code doesn’t need to be removed but can instead be archived, or made “read-only,” so it may still be used by others to fork it into new projects without your involvement. It can also be moved to an archiving site where it can be stored for users. 92 | 93 | It’s important to always remember that just because your company doesn’t care about the code anymore it doesn’t mean that the existing community doesn’t care. It behooves you, then, to remind them as you proceed that they can fork the code and create their own uses for it without you. This also wouldn’t be a bad time to remind users who depend upon the open source code in your projects that they would be wise to mirror and save the code on their own for projects that are very important to them. Code can disappear over time and a good backup or mirror can be critical for users. 94 | 95 | To make whichever option you choose work efficiently, a step-by-step disengagement plan is a good idea to keep it all organized. That means clear and early communications with users who are likely to care as well as a sufficient timeline that gives affected users time to finish their work and move to an alternate platform if needed. How much time will be enough for users? It depends. Start with at least six months, or it could be longer. The key is to set reasonable expectations and communicate your plans very clearly and quite often. 96 | 97 | If your enterprise transfers the project to another group, the users should be kept up to date on what is being done to protect their interests as well. 98 | 99 | ### Work toward a smooth transition 100 | 101 | When a workable partner is secured, then approach your project disengagement like you would handle any product that is being discontinued. Decide what, if any, involvement your organization will have with the project going forward in terms of developer time and then work closely with the new entity to prepare for a smooth transition. Be sure to set expectations that the actual transfer could take months to accomplish, and then turn the project over officially to the new owners when all the needed steps are completed. 102 | 103 | A potential problem that could crop up, though, is if the group which is interested in taking over your old project is not one you favor to operate it into the future. This can happen, and you will have to come up with a plan for action in such a case. How do you deal with this? Well, if you're so attached to your code that you are considering not transferring it to a group that is not exactly in line with your corporate or philosophical directions, then maybe it’s not the right time to end the project. If you care about it that much, perhaps there’s a reason that you shouldn’t be leaving this project. 104 | 105 | ### The importance of clear communications 106 | 107 | Clearly communicating the new direction of the transferred, ended, or rebranded project will continue to be your responsibility even after the transition. Be sure to openly advise developers and community members about the status of the project with its new operators and give them clear details about how the project is now being maintained if they care to continue to use it. Don’t forget to update your project website, social media channels, and other connected community assets so participants know where to find the moved project and can continue to make their contributions and use the code. 108 | 109 | Remember to communicate all this information to downstream organizations and users as well. This includes companies, non-profits, and others that are using your code, and who may not be aware of the demise or transfer of the project because they're not directly involved in the development cycle. You should make efforts to advise them of what is happening through your websites, social media channels, and other outlets, especially if the project is well-known and has had a substantial following. 110 | 111 | > “The biggest thing is to communicate the changes and tell the community of the plans ASAP. Don’t leave the users wondering if the project is still being maintained. For the most part, good code lives on, in my opinion, so if you've got a project that has good code, I would rather not ever take something down from GitHub but set the expectations at, ‘Hey, this project is no longer being actively maintained.’” – Guy Martin, Director of Open at Autodesk 112 | 113 | ### Provide updates through project repositories 114 | 115 | Another important place to post information about project changes is the project’s repository itself on GitHub or related destinations. There you can place detailed notes explaining what’s happening, including readme files to help get the messages to participants. 116 | 117 | As the project moves on, it’s time to officially transfer the assets, if necessary, to its new operators. If you are bringing in new administrators while maintaining the actual assets within your existing company, you can keep the copyrights on the affected code and let them use it with the open source licenses of their choice. 118 | 119 | To keep the project repositories well organized, you might consider setting up a designated area where you can store and make available all transitioned open source projects that your company no longer supports (e.g., https://github.com/twitter-archive). In this way, the projects are still available for users to get code, and potential users can also still find readme files explaining the status of the projects. This designated section of the repository can provide clarity for users and help them understand the difference between active and retired projects, while also ensuring that enterprises can properly showcase their latest live open source projects in their active repositories. 120 | 121 | ### Archiving tips 122 | 123 | Several steps are involved in archiving a project. For example, moving it to a read-only status helps make it clear, without having to change any URLs, that the project is now archived and no longer open to regular updates in its previous form. 124 | 125 | Also important is to provide users with a clear alternative plan for their projects, including how to get and fork the code for their ongoing uses. As part of that responsibility, you should provide users with a way to contact you so they can have their fork listed and made available to other interested users. Some companies provide this assistance, while other choose not to do so. 126 | 127 | Once a repository is archived, you cannot add or remove collaborators or teams, and issues become read-only. To make changes in an archived repository, you must unarchive the repository first. See the GitHub documentation for more details: [https://help.github.com/articles/about-archiving-repositories/](https://help.github.com/articles/about-archiving-repositories/) 128 | 129 | ### Infrastructure updates when shuttering projects 130 | 131 | Ending a project can also affect your project’s infrastructure and support, which must be judged on a case-by-case basis, depending on how your project was set up. Some projects use and maintain only a small set of code, so there might not be much to do. If it is all code and it’s posted on your repository, then you're probably done and need not take additional steps to transfer or secure it. 132 | 133 | Other projects, however, may require significant effort to shutter them using various backend tools to do the work. These may include services that may have been shared for many purposes, such as a test infrastructure. Although that test infrastructure has been used for the project previously, you may want to remove it before transferring the code so you can use the tool to test other work later. It may be hard to disentangle, but it can be done if desired. 134 | 135 | > “Companies really **need to do** a better job of succession planning in open source. Just throwing something out there without proper planning and getting people from outside the company to become contributors and then expecting that it’s going to be that way forever is a challenge. You need to prepare that members of the community, whether they're from your company or from other places, are going to come in and follow somewhat of a life cycle and eventually, people become elders or retired from a community, and you need to have succession planning for that.” – Guy Martin, Director of Open at Autodesk 136 | 137 | ### Have a tough skin 138 | 139 | There may also be some negative public comments and reactions posted about your actions, including unhappy users or “trolls” who disparage your move as abandoning users. Remember, however, most users are aware that priorities change over time and that enterprises might eventually have to stop some open source projects as their work matures. Every company must do this sometimes, so don’t take the comments too personally. 140 | 141 | ## Final thoughts 142 | 143 | Shuttering, transferring, or leaving an open source project is inevitably a step your enterprise will choose to take at some point, but it need not be a debilitating task. With proper planning, clear and widespread communications and the step-by-step completion of legal and procedural tasks, transitioning an open source project can be accomplished satisfactorily for all involved. 144 | 145 | By developing and including simple plans to shutter an open source project even as you begin planning a fledgling project’s first steps, you will ensure a healthy life cycle management plan. These plans will help your open source projects run as efficiently and successfully as possible from their lofty starts to their eventual quieter endings. 146 | 147 | ## Acknowledgements 148 | 149 | Contributors to this guide: 150 | 151 | * [Christine Abernathy](https://twitter.com/abernathyca), Open Source Team Developer Advocate at Facebook 152 | * [Chris Aniszczyk](https://twitter.com/cra), CTO of CNCF (former head of open source at Twitter) 153 | * [Guy Martin](https://twitter.com/guyma), Director of Open at Autodesk 154 | * Jared Smith, Open Source Community Manager at Capital One 155 | * [Dr. David A. Wheeler](https://www.dwheeler.com/), open source expert and lead for two projects with The Linux Foundation’s Core Infrastructure Initiative (CII) 156 | 157 | *These resources were created in partnership with the TODO (Talk Openly, Develop Openly) Group – the professional open source program networking group at The Linux Foundation. A special thanks goes out to the open source program managers who contributed their time and knowledge to making these comprehensive guides. Participating companies include Autodesk, Comcast, Dropbox, Facebook, Google, Intel, Microsoft, Netflix, Oath (Yahoo + AOL), Red Hat, Salesforce, Samsung and VMware. To learn more, visit: [todogroup.org](http://todogroup.org/)* 158 | -------------------------------------------------------------------------------- /using-open-source.md: -------------------------------------------------------------------------------- 1 | # Using Open Source Code 2 | 3 | One of the most important responsibilities of an open source program office is ensuring that your organization meets its legal obligations when integrating open source code with proprietary and third-party source code in your commercial products. 4 | 5 | You need to establish guidelines on how developers can use open source code, and detailed processes to track where open source code is coming from, how it’s licensed, and where it ultimately ends up. This guide gets you started with a baseline compliance program for using, releasing, and distributing open source code. 6 | 7 | **Contents** 8 | 9 | 1. [Why track and review code](#why-track-and-review-code) 10 | 2. [Compliance roles and responsibilities](#compliance-roles-and-responsibilities) 11 | 3. [A simple policy for using open source code](#a-simple-policy-for-using-open-source-code) 12 | 4. [Five-stage code review process](#5-stage-code-review-process) 13 | 5. [What to do after v1.0](#what-to-do-after-v10) 14 | 6. [Sample open source usage request form](#open-source-usage-request-form) 15 | 7. [Final words](#final-words) 16 | 8. [Architecture diagram template](#architecture-diagram-template) 17 | 18 | ## Why track and review code? 19 | 20 | Simply stated, if your company isn’t tracking how and where its developers use open source code, you're at risk of non compliance with applicable open source licenses – this can be an expensive path to go through both in terms of legal fees and engineering time spent to correct the error. Ignoring your open source legal obligations also has repercussions for your company’s reputation in the open source community. 21 | 22 | An open source program office helps centralize policies and decision-making around open source consumption, distribution, and release, tracks code provenance and use, and ensures the organization doesn’t run afoul of its compliance obligations. 23 | 24 | Ideally, your open source program includes a complete compliance program, developed with the help of your legal counsel. In this guide, we’ll cover one important aspect of your compliance program: your policy and processes for using, releasing, and distributing open source code. 25 | 26 | > “A well-designed open source compliance process should simultaneously ensure compliance with the terms of open source licenses and also help companies protect their own intellectual property and that of third-party suppliers from unintended disclosure and/or other consequences.” – [Ibrahim Haddad](https://twitter.com/ibrahimatlinux), Vice President of R&D and Head of the Open Source Group at Samsung Research America 27 | 28 | There are several benefits companies can experience from maintaining an open source compliance program: 29 | 30 | * **Gain a technical advantage.** Since compliant software portfolios are easier to service, test, upgrade, and maintain. 31 | * **Identify crucial pieces of open source code.** You’ll discover what code is in use across multiple products and parts of your organization, and/or are highly strategic and beneficial to your open source strategy. 32 | * **Demonstrate the costs and risks associated with using open source components.** This is easier to see when code goes through multiple rounds of review. 33 | * **Build community trust.** In the event of a compliance challenge, such a program can demonstrate an ongoing pattern of acting in good faith. 34 | * **Prepare for a possible acquisition, sale, or new product or service release.** This is a less common ways benefit, but compliance assurance is a mandatory practice before the completion of such transactions. 35 | * **Build credibility in the supply chain.** You can improve compliance across your software supply chain, dealing with OEMs and downstream vendors. 36 | 37 | ## Compliance roles and responsibilities 38 | 39 | Within your open source program you’ll want to create a designated open source compliance team that’s tasked with ensuring open source compliance. 40 | 41 | The core team, often called the auditing team or the Open Source Review Board (OSRB), consists of representatives from engineering and product teams, one or more legal counsel, and the Compliance Officer (who is typically the open source program manager). 42 | 43 | Other individuals across multiple departments also contribute on an ongoing basis to your open source compliance efforts: documentation, supply chain, corporate development, IT, localization and the Open Source Executive Committee (OSEC) which oversees the overall open source strategy. But unlike the core team, members of the extended team are only working on compliance on a part-time basis, based on tasks they receive from the OSRB. 44 | 45 | The OSRB is in charge of creating an open source compliance strategy and a set of processes that determine how a company will implement these rules on a daily basis. The strategy establishes what must be done to ensure compliance and offers a governing set of principles for how employees interact with open source software. It includes a formal process for the approval, acquisition, and use of open source, and a method for releasing software that contains open source or that’s licensed under an open source license. 46 | 47 | ## A simple policy for using open source code 48 | 49 | The usage policy is an essential component of any compliance program. This set of rules is included in your open source strategy document (you have one, right?) and made available to everyone for easy reference.The usage policy is an essential component of any compliance program. This set of rules is included in your open source strategy document (you have one, right?) and made available to everyone for easy reference. 50 | 51 | The usage policy ensures that any software (proprietary, third-party, or open source) that makes its way into the product base has been audited, reviewed, and approved. It also ensures that your company has a plan to fulfill the license obligations resulting from using the various software components, before your products make it to customers. 52 | 53 | There is no need to make a lengthy or complicated document. A good open source usage policy includes six simple rules: 54 | 55 | * Engineers must receive approval from the OSRB before integrating any open source code in a product. 56 | * Software received from third parties must be audited to identify any open source code included, which ensures license obligations can be fulfilled before a product ships. 57 | * All software must be audited and reviewed, including all proprietary software components. 58 | * Products must fulfill open source licensing obligations prior to customer receipt. 59 | * Approval for using a given open source component in one product is not approval for another deployment, even if the open source component is the same. 60 | * All changed components must go through the approval process. 61 | 62 | ## 5-stage code review process 63 | 64 | Once you have a policy in place, you must plan and create a process that makes it easy to apply the policy. Your job is to grease the wheels for developer use of open source and contribution to open source projects. 65 | 66 | > “If your code review process is overly burdensome, you’ll slow innovation or provide a good excuse for developers to circumvent the process completely.” – [Ibrahim Haddad](https://twitter.com/ibrahimatlinux), Vice President of R&D and Head of the Open Source Group at Samsung Research America 67 | 68 | The process begins by scanning the source code of the software package in question, then moves on to identifying and resolving any discovered issues, performing legal and architectural reviews, and making a decision regarding the usage approval. 69 | 70 | The diagram described below illustrates a simplistic view of a compliance usage process. In reality, the process is much more iterative in nature. Keep in mind that these phases are for illustration purposes and may need to be modified depending on your company’s own needs and open source program configuration. 71 | 72 | Let’s walk through each stage in the process. 73 | 74 | ### Stage 1: Source Code Scan 75 | 76 | In the source code scanning phase, all the source code is scanned using a specialized software tools (there are many commercial vendors that offer such tools in addition to a couple open source alternatives). 77 | 78 | This phase typically kicks off when an engineer submits an online usage form. (See the link to the sample usage form and rules for using it, below.) The form includes all the information about the open source component in question, and specifies the location of the source code in the source code repository system. 79 | 80 | The form submission automatically creates a compliance ticket in a system such as JIRA or Bugzilla and a source code scanning request will be sent to the designated auditing staff. 81 | 82 | Periodic full platform scans should also take place every few weeks to ensure that no open source software component has been integrated into the platform without a corresponding form. If any was found, then a JIRA ticket is automatically issued and assigned to the auditing staff. 83 | 84 | Some of the factors that can trigger a source code scan include: 85 | 86 | * An incoming usage form, usually filled out by engineering staff. 87 | * A periodically scheduled full platform scan. Such scans are very useful for uncovering open source code that snuck into your software platform without a usage form. 88 | * Changes in a previously approved software component. In many cases, engineers start evaluating and testing with a certain version of an OSS component, and later adopt that component when a new version is available. 89 | * Source code is received from a third-party software provider who may or may not have disclosed open source. 90 | * Source code is downloaded from the web with an unknown author and/or license, which may or may not have incorporated open source code. 91 | * A new proprietary software component enters the build system where engineering may or may not have borrowed open source code and used it in a proprietary software component. 92 | 93 | After the code is scanned, the scanning tool produces a report that provides information on: 94 | 95 | * Known software components in use, also known as the software Bill of Materials (BoM) 96 | * Licenses in effect, license texts, and summary of obligations 97 | * License conflicts to be verified by legal 98 | * File inventory 99 | * Identified files 100 | * Dependencies 101 | * Code matches 102 | * Files pending identification 103 | * Source code matches pending identification 104 | 105 | #### Note on Downloaded Open Source Packages 106 | 107 | It is vital to archive open source packages downloaded from the web in their original form. These packages will be used in a later stage (prior to distribution) to verify and track any changes introduced to the source code by computing the difference between the original package and the modified package. 108 | 109 | If a third-party software provider uses open source, the product team integrating that code into the product must submit an open source usage form describing the open source to be used. If the third-party software provider only provides binaries, not source code, then the product team and/or the software supplier manager who manages the relationship with the third-party software provider must obtain a confirmation (for instance, a scan report) that there is no open source in the provided software. 110 | 111 | ### Stage 2: Identification and Resolution 112 | 113 | In the identification and resolution phase, the auditing team inspects and resolves each file or snippet flagged by the scanning tool. 114 | 115 | For example, the scanning tool’s report can flag issues such as conflicting and incompatible licenses. If there are no issues, then the compliance office will move the compliance ticket forward to the legal review phase. 116 | 117 | If there are issues to be resolved, then the compliance officer creates subtasks within the compliance tickets and assigns them to the appropriate engineers to be resolved. In some cases, a code rework is needed; in other cases it may simply be a matter of clarification. The sub-tasks should include a description of the issue, a proposed solution to be implemented by engineering, and a specific timeline for completion. 118 | 119 | The compliance officer may simply close the subtasks once all issues are resolved and pass the ticket along for legal review. Or they might first order a re-scan of the source code and generate a new scan report confirming that earlier issues do not exist anymore. Once they're satisfied that all issues are resolved, the compliance officer forwards the compliance ticket to a representative from the legal department for review and approval. 120 | 121 | In preparation for legal review, you should attach all licensing information related to the open source software to the compliance ticket, such as COPYING, README, LICENSE files, etc. 122 | 123 | ### Stage 3: Legal Review 124 | 125 | In the legal review phase, the legal counsel (typically a member of the open source review board, or OSRB) reviews reports generated by the scanning tool, the license information of the software component, and any comments left in the compliance ticket by engineers and members of the auditing team. 126 | 127 | When a compliance ticket reaches the legal review phase, it already contains: 128 | 129 | * A source code scan report and confirmation that all the issues identified in the scanning phase have been resolved. 130 | * Copies of the license information attached to the ticket: typically, the compliance officer attaches the README, COPYING, and AUTHORS files available in the source code packages to the compliance ticket. Other than the license information, which for OSS components is usually available in a COPYING or a LICENSE file, you need to also capture copyright and attribution notices as well. This information will provide appropriate attributions in your product documentation. 131 | * Feedback from the compliance officer regarding the compliance ticket (concerns, additional questions, etc.). 132 | * Feedback from the engineering representative on the auditing team or from the engineer (package owner) who follows/maintains this package internally. 133 | 134 | The goal of this phase is to produce a legal opinion of compliance, and a decision on the incoming and outgoing license(s) for the software component in question. The incoming and outgoing licenses are in the plural form because in some cases, a software component can include source code available under different licenses. There are three possible outcomes at this stage: 135 | 136 | #### No issues with compliance 137 | 138 | If there are no issues with the licensing, the legal counsel would then decide on the incoming and outgoing licenses of the software component and forward the compliance ticket one step further in the process into the compliance architectural phase. 139 | 140 | The incoming license is the license under which you received the software package. The outgoing license is the license under which you are licensing the software package. In some cases, when the incoming license is a permissive license that allows relicensing (e.g., BSD), companies will relicense that software under their own proprietary license. A more complex example would be a software component that includes proprietary source code, source code licensed under License-A, source code that is available under License-B, and source code available under License-C.During legal review, the legal counsel will need to decide on the incoming and outgoing license(s): 141 | 142 | Incoming licenses= Proprietary License + License A + License B + License C 143 | Outgoing license(s) = ? 144 | 145 | #### Issues with compliance 146 | 147 | If a licensing issue is found, such as mixed source code with incompatible licenses, the legal counsel will flag these issues and reassign the compliance ticket in JIRA to engineering to rework the code. 148 | 149 | For example, legal review may uncover that closely held intellectual property has been combined with an open source code package. Legal counsel will flag this and re-assign the compliance ticket to engineering to remove the proprietary source code from the open source component. In the event that engineering insists on keeping the proprietary source code in the open source component, the open source executive committee (OSEC) will have to release the proprietary source code under an open source license. 150 | 151 | #### Unclear issues with compliance 152 | 153 | In some cases, if the licensing information is not clear or if it is not available, the legal counsel or engineering staff members contacts the project maintainer or the open source developer to clarify the ambiguities and to confirm under which license that specific software component is licensed. 154 | 155 | ### Stage 4: Architecture Review 156 | 157 | In the architecture review, the compliance officer and an engineering representative on the auditing team or open source review board perform an analysis of the interaction between the open source, proprietary, and third-party code. This is accomplished by examining an architectural diagram (see an example, below) that identifies: 158 | 159 | * Open source components (used “as is” or modified) 160 | * Proprietary components 161 | * Components originating from third-party software providers 162 | * Component dependencies 163 | * Communication protocols 164 | * Other open source packages that the specific software component interacts with or depends on, especially if it is governed by a different open source license. 165 | 166 | The result of the architecture review is an analysis of the licensing obligations that may extend from open source to proprietary or third-party software components (and across open source components as well). 167 | 168 | If the compliance officer discovers any issues, such as a proprietary software component linking to a GPL licensed component, the compliance officer forwards the compliance ticket to engineering for resolution. If there are no issues, then the compliance officer moves the ticket to the final stage in the approval process. 169 | 170 | ### Stage 5: Final Review 171 | 172 | The final review is usually a face-to-face meeting of the auditing team or open source review board (OSRB) during which the team approves or rejects the usage of the software component. 173 | 174 | The team bases its decision on the complete compliance record of the software component, which includes the following: 175 | 176 | * A source code scan report generated by the scanning tool. 177 | * The list of discovered issues, information on how they were resolved, and who verified that these issues were successfully resolved. 178 | * Architectural diagrams and information on how this software component interacts with other software components. 179 | * Legal opinion on compliance, and decision on incoming and outgoing licenses. 180 | * Dynamic and static linkage analysis, if applicable in an embedded environment (C/C++). 181 | 182 | In most cases, if a software component reaches the final review, it will be approved unless a condition has presented itself (such as the software component is no longer in use). Once approved, the compliance officer will prepare the list of license obligations for the approved software component and pass it to appropriate departments for fulfillment. This can include: 183 | 184 | * Updating the software inventory to reflect that the specific OSS software component version x is approved for usage in product y, version z. 185 | * Issuing a ticket to the documentation team to update end user notices in the product documentation, to reflect that open source is being used in the product or service. 186 | * Triggering the distribution process before the product ships. 187 | 188 | The compliance officer tracks all open tickets and ensures their completion by the time the product ships or service launches. 189 | 190 | For a more detailed usage process and possible scenarios, see our ebook [Open Source Compliance in the Enterprise](https://www.linuxfoundation.org/publications/open-source-compliance-enterprise/). 191 | 192 | ## What to do after v1.0 193 | 194 | Initial compliance, also called baseline compliance, happens when development starts, and continues until the release of the first version of the product. The compliance team identifies all open source code included in the software baseline, and drives all of the source components through the five-stage approval process outlined above. 195 | 196 | > “It’s important to remember that open source compliance doesn’t stop with version 1.0.” – [Ibrahim Haddad](https://twitter.com/ibrahimatlinux), Vice President of R&D and Head of the Open Source Group at Samsung Research America 197 | 198 | You will also need to develop an incremental compliance process to check in on the source code once the product ships. This process starts when development begins on a new branch that includes additional features and/or bug fixes. 199 | 200 | Incremental compliance is the process by which compliance is maintained when product features are added to the baseline version 1.0. Incremental compliance requires a comparatively smaller effort as opposed to the efforts involved in establishing baseline compliance. But several challenges can arise. You must correctly identify the source code that changed between version 1.0 and version 1.1, and verify compliance on the delta between the releases: 201 | 202 | * New software components may have been introduced. 203 | * Existing software components may have been retired. 204 | * Existing software components may have been upgraded to a newer version. 205 | * The license on a software component may have changed between versions. 206 | * Existing software components may have code changes involving bug fixes or changes to functionality and architecture. 207 | 208 | The obvious question is: How can we keep track of all of these changes? The answer is simple: a bill of material difference tool (BOM diff tool). Given the BOM for product v1.1 and the BOM for v1.0, we compute the delta and the output of the tool is the following: 209 | 210 | * Names of new software components added in v1.1 211 | * Names of updated software components 212 | * Names of retired software components 213 | 214 | With this information in hand, achieving incremental compliance becomes a relatively easy task: 215 | 216 | * Enter new software components into the five-phase usage approval process. 217 | * Compute a line-by-line diff of the source code in changed software components, and decide if you want to scan the source code again or rely on the previous scan. 218 | * Update the software registry by removing the software components that are not used anymore. 219 | 220 | The diagram described below provides an overview of the incremental compliance process. The BOM file for each product release is stored on the build server. The BOM diff tool takes two BOM files as input, each corresponding to a different product release, and computes the delta to produce a list of changes as previously discussed. 221 | 222 | At this point, the compliance officer will create new compliance tickets for all new software components in the release, update compliance tickets where source code has changed and possibly re-pass them through the process, and finally update the software registry to remove retired software components from the approved list. 223 | 224 | ### Open source usage request form 225 | 226 | Completing the open source usage request form is an important step when developers bring open source software into your company, and should be taken very seriously. 227 | 228 | Developers fill out the online form requesting approval to use a given open source component. The form comprises several questions that will provide necessary information for the auditing team or open source review board, allowing it to approve or disapprove the usage of the proposed open source component. 229 | 230 | The table in the sample form available [here](https://github.com/todogroup/policies/blob/master/linuxfoundation/lf_compliance_approval.pdf) highlights the information requested in an open source usage request form. Usually, these values are chosen from a pull-down menu to make the data entry efficient. 231 | 232 | There are several rules governing the OSRB usage form, for instance: 233 | 234 | * The form applies only to the usage of open source in a specific product and in a specific context. It is not a general approval of the open source component for all use cases in all products. 235 | * The form is the basis of audit activity and provides information the review team needs to verify if the implementation is consistent with the usage plan expressed in the form, and with the audit and architectural review results. 236 | * The form must be updated and re-submitted whenever the usage plans for that specific open source component changes. 237 | * The auditing team or review board must approve the form before engineering integrates the open source into the product build. 238 | * The open source executive committee must approve the usage of any open source package where licensing terms require granting a patent license or patent non-assertion. 239 | 240 | ## Final words 241 | 242 | Open source compliance is an essential part of the software development process. If you use open source software in your product(s) and you do not have a solid compliance program, then you should consider this guide as a call to action. 243 | 244 | At its core, open source compliance consists of a set of actions that control the intake and distribution of open source used in commercial products. The result of compliance due diligence is an identification of all open source used in the product (components and snippets) and a plan to meet the license obligations. For a detailed guide to open source compliance download our free ebook, [Open Source Compliance in the Enterprise](https://www.linuxfoundation.org/publications/open-source-compliance-enterprise/) by Ibrahim Haddad. 245 | 246 | ## Architecture diagram template 247 | 248 | An architectural diagram, used in the architecture review phase of the open source review process, illustrates the interactions between the various software components in an example platform. An example template architectural diagram, available [here](https://www.linuxfoundation.org/wp-content/uploads/2017/09/OpenSourceGuideGraphics_V2_G6.png), shows the following: 249 | 250 | * Module dependencies 251 | * Proprietary components 252 | * Open source components (modified versus as-is) 253 | * Dynamic versus static linking 254 | * Kernel space versus user space 255 | * Shared header files 256 | * Communication protocols 257 | * Other open source components that the software component in question interacts or depends on, especially if it is governed by a different open source license 258 | 259 | ## Acknowledgements 260 | 261 | Contributors: 262 | 263 | **![](https://www.linuxfoundation.org/wp-content/uploads/2017/09/thumb_ibrahim.png) 264 | Ibrahim Haddad** 265 | VP of R&D and Head of the Open Source Group 266 | Samsung Research America 267 | 268 | *These resources were created in partnership with the TODO (Talk Openly, Develop Openly) Group – the professional open source program networking group at The Linux Foundation. A special thanks goes out to the open source program managers who contributed their time and knowledge to making these comprehensive guides. Participating companies include Autodesk, Comcast, Dropbox, Facebook, Google, Intel, Microsoft, Netflix, Oath (Yahoo + AOL), Red Hat, Salesforce, Samsung and VMware. To learn more, visit: [todogroup.org](http://todogroup.org/)* 269 | --------------------------------------------------------------------------------