├── .gitignore ├── CONTRIBUTING.md ├── LICENSE ├── Makefile ├── README.md └── src ├── EPUB ├── appendix.xhtml ├── challenges.xhtml ├── copyright.xhtml ├── cover.xhtml ├── current-system.xhtml ├── history.xhtml ├── images │ ├── code-commits.png │ ├── cover.png │ ├── ford-foundation.png │ └── git-subversion-jobs.png ├── nav.xhtml ├── opportunities.xhtml ├── package.opf ├── preface.xhtml ├── style.css ├── sustaining.xhtml └── title.xhtml ├── META-INF └── container.xml └── mimetype /.gitignore: -------------------------------------------------------------------------------- 1 | roads-and-bridges.epub 2 | roads-and-bridges.mobi 3 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing 2 | 3 | This ebook was adapted from the original Google Doc provided to me by Nadia 4 | Eghbal, so my desire is leave the text exactly intact. If you have 5 | contributions that relate to formatting or EPUB specific aspects of this 6 | project, please open a pull request and let's discuss. 7 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution 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 4.0 International Public License 58 | 59 | By exercising the Licensed Rights (defined below), You accept and agree 60 | to be bound by the terms and conditions of this Creative Commons 61 | Attribution 4.0 International Public License ("Public License"). To the 62 | extent this Public License may be interpreted as a contract, You are 63 | granted the Licensed Rights in consideration of Your acceptance of 64 | these terms and conditions, and the Licensor grants You such rights in 65 | consideration of benefits the Licensor receives from making the 66 | Licensed Material available under these terms and conditions. 67 | 68 | 69 | Section 1 -- Definitions. 70 | 71 | a. Adapted Material means material subject to Copyright and Similar 72 | Rights that is derived from or based upon the Licensed Material 73 | and in which the Licensed Material is translated, altered, 74 | arranged, transformed, or otherwise modified in a manner requiring 75 | permission under the Copyright and Similar Rights held by the 76 | Licensor. For purposes of this Public License, where the Licensed 77 | Material is a musical work, performance, or sound recording, 78 | Adapted Material is always produced where the Licensed Material is 79 | synched in timed relation with a moving image. 80 | 81 | b. Adapter's License means the license You apply to Your Copyright 82 | and Similar Rights in Your contributions to Adapted Material in 83 | accordance with the terms and conditions of this Public License. 84 | 85 | c. Copyright and Similar Rights means copyright and/or similar rights 86 | closely related to copyright including, without limitation, 87 | performance, broadcast, sound recording, and Sui Generis Database 88 | Rights, without regard to how the rights are labeled or 89 | categorized. For purposes of this Public License, the rights 90 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 91 | Rights. 92 | 93 | d. Effective Technological Measures means those measures that, in the 94 | absence of proper authority, may not be circumvented under laws 95 | fulfilling obligations under Article 11 of the WIPO Copyright 96 | Treaty adopted on December 20, 1996, and/or similar international 97 | agreements. 98 | 99 | e. Exceptions and Limitations means fair use, fair dealing, and/or 100 | any other exception or limitation to Copyright and Similar Rights 101 | that applies to Your use of the Licensed Material. 102 | 103 | f. Licensed Material means the artistic or literary work, database, 104 | or other material to which the Licensor applied this Public 105 | License. 106 | 107 | g. Licensed Rights means the rights granted to You subject to the 108 | terms and conditions of this Public License, which are limited to 109 | all Copyright and Similar Rights that apply to Your use of the 110 | Licensed Material and that the Licensor has authority to license. 111 | 112 | h. Licensor means the individual(s) or entity(ies) granting rights 113 | under this Public License. 114 | 115 | i. Share means to provide material to the public by any means or 116 | process that requires permission under the Licensed Rights, such 117 | as reproduction, public display, public performance, distribution, 118 | dissemination, communication, or importation, and to make material 119 | available to the public including in ways that members of the 120 | public may access the material from a place and at a time 121 | individually chosen by them. 122 | 123 | j. Sui Generis Database Rights means rights other than copyright 124 | resulting from Directive 96/9/EC of the European Parliament and of 125 | the Council of 11 March 1996 on the legal protection of databases, 126 | as amended and/or succeeded, as well as other essentially 127 | equivalent rights anywhere in the world. 128 | 129 | k. You means the individual or entity exercising the Licensed Rights 130 | under this Public License. Your has a corresponding meaning. 131 | 132 | 133 | Section 2 -- Scope. 134 | 135 | a. License grant. 136 | 137 | 1. Subject to the terms and conditions of this Public License, 138 | the Licensor hereby grants You a worldwide, royalty-free, 139 | non-sublicensable, non-exclusive, irrevocable license to 140 | exercise the Licensed Rights in the Licensed Material to: 141 | 142 | a. reproduce and Share the Licensed Material, in whole or 143 | in part; and 144 | 145 | b. produce, reproduce, and Share Adapted Material. 146 | 147 | 2. Exceptions and Limitations. For the avoidance of doubt, where 148 | Exceptions and Limitations apply to Your use, this Public 149 | License does not apply, and You do not need to comply with 150 | its terms and conditions. 151 | 152 | 3. Term. The term of this Public License is specified in Section 153 | 6(a). 154 | 155 | 4. Media and formats; technical modifications allowed. The 156 | Licensor authorizes You to exercise the Licensed Rights in 157 | all media and formats whether now known or hereafter created, 158 | and to make technical modifications necessary to do so. The 159 | Licensor waives and/or agrees not to assert any right or 160 | authority to forbid You from making technical modifications 161 | necessary to exercise the Licensed Rights, including 162 | technical modifications necessary to circumvent Effective 163 | Technological Measures. For purposes of this Public License, 164 | simply making modifications authorized by this Section 2(a) 165 | (4) never produces Adapted Material. 166 | 167 | 5. Downstream recipients. 168 | 169 | a. Offer from the Licensor -- Licensed Material. Every 170 | recipient of the Licensed Material automatically 171 | receives an offer from the Licensor to exercise the 172 | Licensed Rights under the terms and conditions of this 173 | Public License. 174 | 175 | b. No downstream restrictions. You may not offer or impose 176 | any additional or different terms or conditions on, or 177 | apply any Effective Technological Measures to, the 178 | Licensed Material if doing so restricts exercise of the 179 | Licensed Rights by any recipient of the Licensed 180 | Material. 181 | 182 | 6. No endorsement. Nothing in this Public License constitutes or 183 | may be construed as permission to assert or imply that You 184 | are, or that Your use of the Licensed Material is, connected 185 | with, or sponsored, endorsed, or granted official status by, 186 | the Licensor or others designated to receive attribution as 187 | provided in Section 3(a)(1)(A)(i). 188 | 189 | b. Other rights. 190 | 191 | 1. Moral rights, such as the right of integrity, are not 192 | licensed under this Public License, nor are publicity, 193 | privacy, and/or other similar personality rights; however, to 194 | the extent possible, the Licensor waives and/or agrees not to 195 | assert any such rights held by the Licensor to the limited 196 | extent necessary to allow You to exercise the Licensed 197 | Rights, but not otherwise. 198 | 199 | 2. Patent and trademark rights are not licensed under this 200 | Public License. 201 | 202 | 3. To the extent possible, the Licensor waives any right to 203 | collect royalties from You for the exercise of the Licensed 204 | Rights, whether directly or through a collecting society 205 | under any voluntary or waivable statutory or compulsory 206 | licensing scheme. In all other cases the Licensor expressly 207 | reserves any right to collect such royalties. 208 | 209 | 210 | Section 3 -- License Conditions. 211 | 212 | Your exercise of the Licensed Rights is expressly made subject to the 213 | following conditions. 214 | 215 | a. Attribution. 216 | 217 | 1. If You Share the Licensed Material (including in modified 218 | form), You must: 219 | 220 | a. retain the following if it is supplied by the Licensor 221 | with the Licensed Material: 222 | 223 | i. identification of the creator(s) of the Licensed 224 | Material and any others designated to receive 225 | attribution, in any reasonable manner requested by 226 | the Licensor (including by pseudonym if 227 | designated); 228 | 229 | ii. a copyright notice; 230 | 231 | iii. a notice that refers to this Public License; 232 | 233 | iv. a notice that refers to the disclaimer of 234 | warranties; 235 | 236 | v. a URI or hyperlink to the Licensed Material to the 237 | extent reasonably practicable; 238 | 239 | b. indicate if You modified the Licensed Material and 240 | retain an indication of any previous modifications; and 241 | 242 | c. indicate the Licensed Material is licensed under this 243 | Public License, and include the text of, or the URI or 244 | hyperlink to, this Public License. 245 | 246 | 2. You may satisfy the conditions in Section 3(a)(1) in any 247 | reasonable manner based on the medium, means, and context in 248 | which You Share the Licensed Material. For example, it may be 249 | reasonable to satisfy the conditions by providing a URI or 250 | hyperlink to a resource that includes the required 251 | information. 252 | 253 | 3. If requested by the Licensor, You must remove any of the 254 | information required by Section 3(a)(1)(A) to the extent 255 | reasonably practicable. 256 | 257 | 4. If You Share Adapted Material You produce, the Adapter's 258 | License You apply must not prevent recipients of the Adapted 259 | Material from complying with this Public License. 260 | 261 | 262 | Section 4 -- Sui Generis Database Rights. 263 | 264 | Where the Licensed Rights include Sui Generis Database Rights that 265 | apply to Your use of the Licensed Material: 266 | 267 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 268 | to extract, reuse, reproduce, and Share all or a substantial 269 | portion of the contents of the database; 270 | 271 | b. if You include all or a substantial portion of the database 272 | contents in a database in which You have Sui Generis Database 273 | Rights, then the database in which You have Sui Generis Database 274 | Rights (but not its individual contents) is Adapted Material; and 275 | 276 | c. You must comply with the conditions in Section 3(a) if You Share 277 | all or a substantial portion of the contents of the database. 278 | 279 | For the avoidance of doubt, this Section 4 supplements and does not 280 | replace Your obligations under this Public License where the Licensed 281 | Rights include other Copyright and Similar Rights. 282 | 283 | 284 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 285 | 286 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 287 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 288 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 289 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 290 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 291 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 292 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 293 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 294 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 295 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 296 | 297 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 298 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 299 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 300 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 301 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 302 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 303 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 304 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 305 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 306 | 307 | c. The disclaimer of warranties and limitation of liability provided 308 | above shall be interpreted in a manner that, to the extent 309 | possible, most closely approximates an absolute disclaimer and 310 | waiver of all liability. 311 | 312 | 313 | Section 6 -- Term and Termination. 314 | 315 | a. This Public License applies for the term of the Copyright and 316 | Similar Rights licensed here. However, if You fail to comply with 317 | this Public License, then Your rights under this Public License 318 | terminate automatically. 319 | 320 | b. Where Your right to use the Licensed Material has terminated under 321 | Section 6(a), it reinstates: 322 | 323 | 1. automatically as of the date the violation is cured, provided 324 | it is cured within 30 days of Your discovery of the 325 | violation; or 326 | 327 | 2. upon express reinstatement by the Licensor. 328 | 329 | For the avoidance of doubt, this Section 6(b) does not affect any 330 | right the Licensor may have to seek remedies for Your violations 331 | of this Public License. 332 | 333 | c. For the avoidance of doubt, the Licensor may also offer the 334 | Licensed Material under separate terms or conditions or stop 335 | distributing the Licensed Material at any time; however, doing so 336 | will not terminate this Public License. 337 | 338 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 339 | License. 340 | 341 | 342 | Section 7 -- Other Terms and Conditions. 343 | 344 | a. The Licensor shall not be bound by any additional or different 345 | terms or conditions communicated by You unless expressly agreed. 346 | 347 | b. Any arrangements, understandings, or agreements regarding the 348 | Licensed Material not stated herein are separate from and 349 | independent of the terms and conditions of this Public License. 350 | 351 | 352 | Section 8 -- Interpretation. 353 | 354 | a. For the avoidance of doubt, this Public License does not, and 355 | shall not be interpreted to, reduce, limit, restrict, or impose 356 | conditions on any use of the Licensed Material that could lawfully 357 | be made without permission under this Public License. 358 | 359 | b. To the extent possible, if any provision of this Public License is 360 | deemed unenforceable, it shall be automatically reformed to the 361 | minimum extent necessary to make it enforceable. If the provision 362 | cannot be reformed, it shall be severed from this Public License 363 | without affecting the enforceability of the remaining terms and 364 | conditions. 365 | 366 | c. No term or condition of this Public License will be waived and no 367 | failure to comply consented to unless expressly agreed to by the 368 | Licensor. 369 | 370 | d. Nothing in this Public License constitutes or may be interpreted 371 | as a limitation upon, or waiver of, any privileges and immunities 372 | that apply to the Licensor or You, including from the legal 373 | processes of any jurisdiction or authority. 374 | 375 | 376 | ======================================================================= 377 | 378 | Creative Commons is not a party to its public 379 | licenses. Notwithstanding, Creative Commons may elect to apply one of 380 | its public licenses to material it publishes and in those instances 381 | will be considered the “Licensor.” The text of the Creative Commons 382 | public licenses is dedicated to the public domain under the CC0 Public 383 | Domain Dedication. Except for the limited purpose of indicating that 384 | material is shared under a Creative Commons public license or as 385 | otherwise permitted by the Creative Commons policies published at 386 | creativecommons.org/policies, Creative Commons does not authorize the 387 | use of the trademark "Creative Commons" or any other trademark or logo 388 | of Creative Commons without its prior written consent including, 389 | without limitation, in connection with any unauthorized modifications 390 | to any of its public licenses or any other arrangements, 391 | understandings, or agreements concerning use of licensed material. For 392 | the avoidance of doubt, this paragraph does not form part of the 393 | public licenses. 394 | 395 | Creative Commons may be contacted at creativecommons.org. 396 | 397 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | NAME=roads-and-bridges 2 | EPUB=${NAME}.epub 3 | MOBI=${NAME}.mobi 4 | 5 | ALL: clean ${EPUB} 6 | 7 | ${EPUB}: 8 | zip -Xj0 ${EPUB} src/mimetype 9 | cd src; zip -Xur9D ../${EPUB} * 10 | 11 | ${MOBI}: ${EPUB} 12 | ebook-convert ${EPUB} ${MOBI} 13 | 14 | test: 15 | epubcheck -mode exp src 16 | 17 | tidy: 18 | tidy -q -m --indent yes --indent-spaces 2 --tidy-mark no -w 120 `ls src/EPUB/*.xhtml | grep -v nav.xhtml` 19 | 20 | clean: 21 | rm -f ${EPUB} ${MOBI} 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Roads and Bridges 2 | 3 | This repository contains an EPUB adaptation of the paper [Roads and Bridges][], 4 | written by Nadia Eghbal (@nayafia) and published by the Ford Foundation. 5 | 6 | [Roads and Bridges]: http://www.fordfoundation.org/library/reports-and-studies/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure 7 | -------------------------------------------------------------------------------- /src/EPUB/challenges.xhtml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Roads and Bridges 7 | 8 | 9 | 10 | 11 | 12 |

13 | Challenges Facing Digital Infrastructure 14 |

15 |
16 |

17 | Open source’s complicated relationship with money 18 |

19 |

20 | Money has been a taboo topic for open source projects since the early days of the free software movement, which 21 | arose in direct response to the practice of commercial, proprietary software. 22 |

23 |

24 | In the context of the free software movement, the aversion to money is certainly understandable. Money is what 25 | commercialized software in the 1980s, and it took decades to reverse this mentality and promote the benefits of 26 | building software that is free to use, distribute, and modify. Although we take free software for granted 27 | today, in the 1980s it was truly a counterculture and revolutionary mindset. 28 |

29 |

30 | Yet even within open source communities, there is a pervasive belief that money has a corrupting influence on 31 | open source. It is indeed remarkable how much has been created entirely through labors of love. These days, 32 | software development is considered a lucrative field, with coding schools luring prospective students with the 33 | promise of making a six-figure entry-level salary. By contrast, there is something pure and admirable about 34 | creating a software project simply for the joy of it. 35 |

36 |

37 | On a more practical level, open source projects traditionally arise from a real and identifiable need. Someone 38 | decides that a project could be done better, so they fork the project, make improvements, then release it for 39 | consumption. Pragmatism is core to open source’s culture, as evidenced by its strategic break from the free 40 | software movement in the late 1990s. Some open source contributors fear, perhaps justifiably, that money will 41 | introduce bloat into the system, with developers creating new projects simply to get funding, rather than 42 | because the solution is needed. 43 |

44 |

45 | David Heinemeier Hansson (also known as DHH), who created the popular software framework Ruby on Rails, warned 46 | in 2013 against mixing open source with money: 47 |

48 |
49 |

50 | Open source has been such an incredible force for quality and community exactly because it's not been defined 51 | in market terms. In market terms, most open source projects should never have had a chance. 52 |

53 |

54 | Take Ruby on Rails. [...] That's a monumental achievement of humanity! Thousands, collaborating for a decade, 55 | to produce an astoundingly accomplished framework and ecosystem available to anyone at the cost of zero. Take 56 | a second to ponder the magnitude of that success. Not just for Rails, of course, but for many other, and 57 | larger, open source projects out there with an even longer lineage and success. 58 |

59 |

60 | It's against this fantastic success of social norms that we should be extraordinary [sic] careful before we 61 | let market norms corrupt the ecosystem.[72] 62 |

63 |
64 |

65 | Structurally, open source’s greatest advantage — its penchant for democracy — is also its weakness. Many open 66 | source projects are nothing more than a public code repository t o which a group of people contribute 67 | regularly: the equivalent of an unofficial social club on a college campus. There is no legal structure and 68 | there are no clear owners or leaders. “Maintainers,” or the primary contributors, often emerge de facto, 69 | based on who authored the project or put in significant time or effort. Even then, however, some projects are 70 | reluctant to introduce hierarchy by clearly favoring one contributor over another. 71 |

72 |

73 | In April of 2008, Jeff Atwood, an aforementioned prominent .NET developer, announced he was donating $5,000 74 | towards an open source project, ScrewTurn Wiki. ScrewTurn Wiki is a wiki project developed by Dario Solara, 75 | another .NET developer, and maintained by volunteers. Atwood told Dario that the grant would be “no strings 76 | attached;” Solara could use the money as he saw fit towards the project. 77 |

78 |

79 | Several months later, Atwood followed up with Solara to ask how he decided to spend the donation. Solara 80 | replied that the grant money was still untouched. It’s not easy to use it….What would you suggest? 81 | Atwood wrote that he was crushingly disappointed by the response. [73] 83 |

84 |

85 | The decentralized nature of open source has made it what it is: crowdsourced software that anyone can build, 86 | share and contribute to. But when it comes to discussing organizational needs or sustainability, it can be 87 | difficult to make authoritative decisions. 88 |

89 |

90 | These transitions to long-term sustainability can be drawn out and painful. One of the more prominent examples 91 | is the Linux kernel, an open source project used in many operating systems worldwide, including Android and 92 | Chrome OS. It was created in 1991 by computer science student Linus Torvalds. 93 |

94 |

95 | As the Linux kernel grew in popularity, Linus was reluctant to discuss how to scale development of the project, 96 | preferring to manage everything himself. Project maintainers grew restless and even angry at Torvalds, sparking 97 | “really big fights,” according to Torvalds. The disputes peaked in 2002 with discussions of a potential schism. 98 |

99 |

100 | Torvalds attributed the internal conflict to a lack of organization, rather than to any technical issues : 101 |

102 |
103 |

104 | We had really big fights back in 2002 or so where I was dropping patches left and right, and things really 105 | weren't working. It was very painful for everybody, and very much for me, too. Nobody really likes criticism, 106 | and there was a lot of flaming going around—and because it wasn't a strictly technical problem, you couldn't 107 | point to a patch and say, hey, look, that patch improves timings by 15% or anything like that: there 108 | was no technical solution. The solution ended up being better tools, and a work flow [sic] that allowed much 109 | more distributed management. [74] 110 |

111 |
112 |

113 | The Linux Foundation was created in 2007 to help protect and maintain Linux and its associated projects. 114 | Torvalds does not run the Linux Foundation himself, preferring instead to receive a steady salary as a “Linux 115 | Fellow” and work on his projects as an engineer. 116 |

117 |

118 | While open source software is admirably rooted in a culture of volunteerism and collaboration relatively 119 | untouched by extrinsic motives, the reality is that our economy and society, from multimillion dollar companies 120 | to government websites, depends on open source. 121 |

122 |

123 | Overall, this is probably a positive development for society. It means that software is no longer strictly 124 | relegated to private, proprietary development, as it ha d been for decades. The fact that the United States 125 | government, or a social network website with billions of users, incorporates community-built software, paints 126 | an optimistic future for democracy. 127 |

128 |

129 | In addition, many projects function well on a community basis if they are on the extremes of size : that is, 130 | either small projects that do not require significant maintenance (as in the example of Arash Payan and 131 | Appirater), or very large projects that have found significant corporate support (as in the example of Linux). 132 |

133 |

134 | However, many projects are trapped somewhere in the middle: large enough to require significant maintenance, 135 | but not quite so large that corporations are clamoring to offer support. These are the stories that go 136 | unnoticed and untold. From both sides, these maintainers are told they are the problem: S mall project 137 | maintainers think mid-sized maintainers should just learn to cope, and large project maintainers think if the 138 | project were “good enough,” institutional support would have already come to them. 139 |

140 |

141 | There are also political concerns around financial support that make it harder to find a reliable source of 142 | funding. A single company may not want to sponsor development work that also benefits their competitor, who 143 | paid nothing. A private benefactor may want special privileges that threaten the neutrality of a project. (For 144 | example, for security-related projects, privileged disclosure of vulnerabilities — paying for special knowledge 145 | about security vulnerabilities instead of exposing those vulnerabilities to the public — is a controversial 146 | request.) And governments may have political reasons to sponsor the development of a particular project, or ask 147 | for special favors such as “backdoors” (a secret way of bypassing security authentication), even if that 148 | project is used internationally. 149 |

150 |

151 | The recent legal disputes between the FBI and Apple help underscore the tension between technology and 152 | government, even beyond open source projects. The FBI has repeatedly, through court orders, requested Apple’s 153 | assistance in unlocking iPhones to help resolve criminal investigations. Apple has repeatedly denied these 154 | requests. In February 2016, the FBI requested Apple’s assistance in unlocking the iPhone belonging to one of 155 | the shooters in a recent terrorist attack in San Bernardino, California. Apple again denied the request, 156 | posting a public customer letter on its website, which stated that: 157 |

158 |
159 |

160 | While we believe the FBI’s intentions are good, it would be wrong for the government to force us to build a 161 | backdoor into our products. And ultimately, we fear that this demand would undermine the very freedoms and 162 | liberty our government is meant to protect.[75] 164 |

165 |
166 |

167 | In March 2016, the FBI found a third party to help it unlock the iPhone and dropped the legal case. 168 |

169 |

170 | One of open source’s greatest strengths is that the code is considered a public good, and many projects take 171 | governance seriously. It is personally important to many project maintainers that no individual party control 172 | something that the public uses and benefits from. However, this commitment to neutrality can come at a price, 173 | when many resources available to software developers today (such as venture capital or corporate donations) are 174 | based on expectations of influence or financial return. 175 |

176 |

177 | Open source software is being created and used at a rate never seen before. Many open source projects are 178 | experiencing a difficult transition from selfless creative pursuit to critical public infrastructure. These 179 | increasing dependencies mean we have a shared responsibility to ensure that these projects find the support 180 | they need. 181 |

182 |
183 |
184 |

185 | Why digital infrastructure support problems are accelerating 186 |

187 |

188 | Open source is quickly becoming a standard for digital infrastructure projects, and in software development 189 | overall, due to the benefits cited earlier in this paper. Black Duck, a company that helps clients manage open 190 | source software, runs an annual survey that asks companies about their open source use. (This survey is one of 191 | the few open source data projects in existence.) According to their 2015 survey, 78% of the 1,300 companies 192 | surveyed said their software created for customers was built on open source, nearly double that of 2010. 193 | [76] 194 |

195 |

196 | Open source has seen massive growth in popularity in the last five years, not just because of the obvious 197 | benefits to developer and consumer, but also due to new tools that make it easier to collaborate on software. 198 | In order to understand why digital infrastructure faces growing support problems, we must understand how open 199 | source software development is proliferating. 200 |

201 |

202 | GitHub as a standardized place to collaborate on code 203 |

204 |

205 | The role of GitHub in bringing open source to a mainstream audience cannot be overemphasized. Although open 206 | source has existed for over thirty years, until 2008, contributing to an open source project was not so easy. A 207 | developer would have to figure out who the maintainer was, find a way to contact them, and propose changes 208 | using whichever format that project maintainer preferred (for example, a mailing list or message board). GitHub 209 | standardized these methods of communication: maintainers are transparently listed on a project’s page, and 210 | discussion of proposed changes takes place on the GitHub platform. 211 |

212 |

213 | GitHub created vocabulary that is now standard among open source contributors, such as the “pull request” 214 | (where a developer submits changes to a project for review) and repurposing the term “fork” (historically, 215 | creating a copy of a project and modifying it into a new project). Prior to GitHub, forking a project meant 216 | there were irreconcilable differences over the direction a project should take. Forking was considered a 217 | serious move: if a group of developers forked a project, it meant the project was splitting into ideological 218 | factions. Forking was also used to develop a new project that might have a markedly different purpose from the 219 | original project. 220 |

221 |

222 | This type of “project fork” still exists today, but GitHub decided to use the term “fork” to encourage more 223 | activity on their platform. A GitHub fork, unlike a project fork, means temporarily copying a project, making 224 | changes, and usually merging it back into the project. F orking as an everyday practice on GitHub’s platform 225 | has added a positive, lightweight connotation to the term: a sign of taking one person’s idea and making it 226 | better. 227 |

228 |

229 | GitHub also helped standardize the use of a version control system called Git. Version control systems keep 230 | track of everybody’s work on a particular piece of code. For example, if Developer 1 and Developer 2 are fixing 231 | different parts of the same code at the same time, logging each change in a version control system ensures 232 | their changes don’t conflict with one another. 233 |

234 |

235 | There are several options for version control systems, including Apache Subversion and Concurrent Versions 236 | System (CVS). Git used to be a fairly unknown version control system. In 2010, Subversion was used in 60% of 237 | software projects, whereas Git was used in just 11%. [77] 239 |

240 |

241 | Linus Torvalds, the developer behind Linux, designed Git in 2005 as a better and faster way to manage multiple 242 | contributions from many people. Git was markedly different from earlier version control systems and therefore 243 | not so easy to pick up, but its decentralized workflow solved a real problem for developers. 244 |

245 |

246 | GitHub provided an intuitive user interface for open source projects that used Git, thus making it easier for 247 | developers to learn. The more developers used GitHub, the more they wanted to keep using Git. Today, in 2016, 248 | Git is used in 38% of software projects, w hile Subversion ’s share has drop ped to 47%. [78] Although Subversion is still the most popular version 250 | control system today, it s use is declining. 251 |

252 |

253 | The widespread adoption of Git makes it much easier for a developer to join any open source project on GitHub, 254 | because the method of making changes, and communicating those changes, is the same across projects. Learning 255 | how to contribute to one project gives someone the ability to contribute to hundreds of others. This was not 256 | the case before GitHub, where different version control systems were used for different projects. 257 |

258 |
259 | Graph of job postings for git versus subversion 261 |
262 | Job postings requiring knowledge of Git vs. Subversion.[79] 264 |
265 |
266 |

267 | Finally, GitHub provided a place for developers to talk to each other in a public setting for social reasons, 268 | not just code collaboration. GitHub has become a de facto community of sorts for developers, who use it to 269 | communicate with each other and show off their work. Developers now have an opportunity to demonstrate their 270 | leadership and portfolio of work in a way they could not before. 271 |

272 |

273 | GitHub’s usage reflects its meteoric rise. In 2011, there were only 2 million repositories. [80] Today, GitHub has 14 million users and over 35 million 275 | repositories. [81] (Note that this includes 276 | forked repositories; the unique repository count is probably closer to 17 million.) GitHub’s Brian Doll noted 277 | that the first million repositories took nearly 4 years to create; getting from nine to ten million took just 278 | 48 days. [82] 279 |

280 |

281 | By contrast, SourceForge, the most popular platform for hosting open source code before GitHub, had 150,000 282 | projects in 2008. An estimated 18,000 of those projects were active. [83] 284 |

285 |

286 | Stack Overflow as a standardized place to get help with code 287 |

288 |

289 | Another important tool is Stack Overflow, a popular Q&A website for programmers, also created in 2008 by 290 | Jeff Atwood, the aforementioned programmer and blogger, and Joe l Spolsky. As of April 2014, Stack Overflow had 291 | over 4 million registered users and over 11 million questions answered (note that one does not need to be 292 | registered to view questions or their answers).[84] Stack Overflow has become a de facto support platform for developers to ask 294 | questions about coding, find answers to specific code problems, or just get advice on the best way to build a 295 | certain piece of software. It can be thought of as crowdsourced “customer support” for developers around the 296 | world. While Stack Overflow is not a place to write live code, it is a critical collaboration tool for the 297 | individual developer, making it easier to solve problems and code more efficiently. This means any one 298 | individual developer is capable of achieving more in a shorter period of time, increasing overall output. Stack 299 | Overflow has also helped people learn new coding concepts (or even get started with coding itself), making 300 | coding easier and more accessible to all. 301 |

302 |

303 | Macro trends in a rapidly changing landscape 304 |

305 |

306 | The outsized popularity of open source has led to significant changes in how today’s developer talks, thinks 307 | about, and collaborates on software. 308 |

309 |

310 | Firstly, licensing expectations and requirements have changed to reflect a world that embraces open source as 311 | the standard, not the exception: a triumph over the proprietary world of the 1980s. Both GitHub and Stack 312 | Overflow’s policies reflect this. 313 |

314 |

315 | From the beginning, Stack Overflow used a Creative Commons license called CC-BY-SA for all content posted to 316 | the website. This license was limiting, however, because it required that users provide attribution when using 317 | others’ code, as well as distribute contributions under the same license. [85] While many ignored or were not aware of this license, it made it difficult for 319 | developers under stricter constraints (such as in a corporate environment) to use Stack Overflow. If they 320 | posted a question asking for help with their code, and a stranger fixed it, legally, they would have had to 321 | attribute the code to that person. 322 |

323 |

324 | As a result, Stack Overflow announced an intent to move all new code contributions to the MIT License, which is 325 | an open source license with fewer restrictions. [86] As of April 2016, they are still actively discussing and soliciting feedback from 327 | the community on the best way to implement more permissiveness. [87] This move is a nod to both Stack Overflow’s popularity and the proliferation of 329 | open source at large. That a developer working at a big software company could legally include a complete 330 | stranger’s code in a product they charge for is an accomplishment for open source, indeed. 331 |

332 |

333 | GitHub, by contrast, initially avoided providing default licensing for projects posted to its platform, perhaps 334 | fearing it would slow user adoption and growth. [88] Projects posted to GitHub, then, grant the right to view and fork the project, but 336 | are otherwise protected under copyright, unless the developer specifies an open source license. 337 |

338 |

339 | In 2013, facing public concerns, GitHub finally decided to take a stronger stance on licensing, including the 340 | creation and promotion of a microsite, choosealicense.com, to help users pick a license for their project. They 341 | also now encourage their users to choose a license from a list of options when creating a new repository. 342 | [89] 343 |

344 |

345 | What’s interesting, however, is that many developers were either not aware that their “open source” projects 346 | were not legally protected, or didn’t care. An informal 2013 study by the Software Freedom Law Center of 1.6 347 | million GitHub repositories revealed that only 15% had specified a license. [90] Granted, not all repositories on GitHub are code: many 349 | “projects” are notes, wikis, or other forms of content, so the situation is likely less dire than it seems. 350 | However, the low percentage of license d projects suggests that users are not internally motivated to protect 351 | even content-based projects that might be used or shared elsewhere. 352 |

353 |

354 | This lack of interest in licensing led James Governor, cofounder of developer analyst firm Red Monk, to observe 355 | in 2012 that younger devs today are about POSS - Post open source software. Fuck the license and governance, 356 | just commit to Github.[91] In other words, 357 | defaulting to open information is so culturally obvious today that developers don’t see themselves as doing 358 | something differently anymore, the way the political free software rebels did in the 1980s. This shift in 359 | values, while inspiring on a macro level, could lead to legal complications for individuals as their projects 360 | grow in popularity or are used for commercial purposes. 361 |

362 |

363 | But by making it so easy and standardized to collaborate on code together, open source is also grappling with a 364 | perverse set of externalities. 365 |

366 |

367 | Open source made coding easier and more accessible to the world. This increased accessibility, in turn, has 368 | created a new class of developers who are less experienced, but who know how to utilize others’ prefabricated 369 | components to build what they need. 370 |

371 |

372 | In 2012, Jeff Atwood, the cofounder of Stack Overflow, wrote a tongue-in-cheek blog post called Please Don’t Learn How to Code, lamenting the trendiness of coding bootcamps and schools. While 374 | Atwood commended the desire of nontechnical people to understand code on a conceptual level, he warned against 375 | assuming that adding naive, novice, not-even-sure-they-like-this-whole-programming-thing coders to the 376 | workforce is a net positive for the world. [92] 378 |

379 |

380 | Under these circumstances, the open source development model looks different than it did before. Prior to 381 | GitHub’s rise, because there were fewer open source projects, developers were a smaller but on the whole more 382 | experienced group, and those who used shared code were likely also the people contributing back. 383 |

384 |

385 | Today, the hypergrowth of coding literacy means many inexperienced developers are flooding the market. These 386 | newer developers borrow shared code to write what they need, but they are less capable of making substantial 387 | contributions back to those projects. Many are also accustomed to thinking of themselves as “users” of open 388 | source projects, rather than members of a community. Because open source tools are more standardized and easy 389 | to use, it’s much easier these days for someone to pop into a GitHub forum and make a rude comment or demanding 390 | request, which burdens and exasperates project maintainers. 391 |

392 |

393 | These changing demographics have also led to a much more fragmented system of software, with many developers 394 | releasing new projects and creating a confusing web of dependencies. Drew Hamlett, who calls himself a 395 | “recovering magpie developer,” wrote a popular post in January 2016 called “The Sad State of Web Development,” 396 | about how web development has changed, referring specifically to the Node.js ecosystem: 397 |

398 |
399 |

400 | The people who have stayed in the Node community have undoubtedly created the most over engineered eco system 401 | [sic] that has ever appeared. No one can create a library that does anything. Every project that creeps up is 402 | even more ambitious than the next….No one will build something that actually does anything. I just don’t 403 | understand. The only thing I can think, is people are just constantly re writing Node.js apps over and 404 | over.[93] 405 |

406 |
407 |

408 | There are so many projects being written and released today that it is simply not feasible for each one to grow 409 | a large, sustainable community with regular contributors who passionately discuss changes over extensive 410 | mailing list discussions. Instead, many projects will be maintained by just one or two people. But demand for 411 | those projects by users might still outpace the work that is required to maintain it. 412 |

413 |

414 | GitHub made it easy to create and contribute to new projects. This was a blessing for the open source 415 | ecosystem, because projects develop more rapidly, but it can be a curse to any one project maintainer, with 416 | more people easily reporting issues and requesting new features, without actually contributing back themselves. 417 | These shallow interactions only create more work for the maintainers, who are expected to address a growing 418 | volume of requests. 419 |

420 |

421 | It would not be unreasonable to suggest that a “post-open source” world carries implications not just for 422 | licensing, as James Governor originally intended with his comment, but for the process of development itself. 423 |

424 |

425 | Noah Kantrowitz, a longtime Python developer and member of the Python Software Foundation, summarized this 426 | shift in a widely cited blog post: 427 |

428 |
429 |

430 | In the early days of the open source movement there were relatively few projects and in general most people 431 | using a project were also contributing back to it in some way. Both of these have changed by likely 432 | uncountable orders of magnitude. 433 |

434 |

435 | [...] As we have moved to more and more niche tools, it becomes harder to justify the time investment to 436 | become a contributor. ‘Scratching your own itch’ is still a powerful motivator, but that alone is difficult 437 | to build an ecosystem on. 438 |

439 |

440 | The other problem is the growing imbalance between producers and consumers. In the past, these were roughly 441 | in balance. Everyone put time and effort in to the Commons and everyone reaped the benefits. These days, very 442 | few people put in that effort and the vast majority simply benefit from those that do. This imbalance has 443 | become so ingrained that for a company to re-pay (in either time or money) even a small fraction of the value 444 | they derive from the Commons is almost unthinkable.[94] 446 |

447 |
448 |

449 | This is not to say that big open source projects with strong contributor communities do not exist anymore. ( 450 | Node.js, which will be discussed later in this paper, is an example of a project that has achieved this 451 | status.) It is that in addition to these successes, there is a new class of projects today that is underserved 452 | by open source’s current norms and expectations, and that the behavior deriving from these new norms has 453 | affected even longer - running, bigger projects. 454 |

455 |

456 | Hynek Schlawack, a Python Software Foundation fellow and contributor to Python infrastructure projects, frets 457 | about a future with a wider demand base but only a handful of keystone contributors: 458 |

459 |
460 |

461 | What frustrates me most is that we have an all-time high of Python developers and an all-time low on high 462 | quality contributions.[...] As soon as pivotal developers like Armin Ronacher slow down their churn, the 463 | whole community feels it immediately. The moment Paul Kehrer stops working on PyCA we’re screwed. If Hawkowl 464 | stops porting, Twisted will never be on Python 3 and git. 465 |

466 |

467 | So we’re bleeding due to people who cause more work than they provide. [...] Right now everyone is 468 | benefitting from what has been built but due to lack of funding and contributions it’s deteriorating. I find 469 | that worrying, because Python might be super popular right now but once the consequences hit us, the 470 | opportunists will leave as fast as they arrived.[95] 472 |

473 |
474 |

475 | Open source has only been popular among mainstream developers for perhaps five years; its long-term 476 | sustainability is rarely discussed, or even acknowledged, by the broader software community. With the explosion 477 | of new developers using, but not giving back to, shared code, we are building palaces on top of crumbling 478 | infrastructure. 479 |

480 |
481 |
482 |

483 | The hidden costs of ignoring infrastructure 484 |

485 |

486 | As we’ve seen, digital infrastructure is a critical part of today’s world. Our society is built on software, 487 | and that software is increasingly built on infrastructure that uses open source methodology. By not taking 488 | steps to understand and support our digital infrastructure, what is at risk? 489 |

490 |

491 | The dangers of not investing back into digital infrastructure can be divided into two categories: direct and 492 | indirect costs. 493 |

494 |
495 |

496 | Direct costs include unspotted bugs and security vulnerabilities that could be exploited for 497 | malicious intent or lead to unexpected breaks in software functionality. These costs are acutely felt and 498 | cause problems that need to be immediately addressed. 499 |

500 |

501 | Indirect costs include things like loss of qualified labor and slower growth and innovation. 502 | While they are not immediately obvious, they represent uncaptured social value. 503 |

504 |
505 |

506 | Bugs, security vulnerabilities, and interruptions in service 507 |

508 |

509 | The introduction to this report profiled the security bug Heartbleed, which was discovered in April 2014 in a 510 | software library called OpenSSL. Heartbleed, because it was so widespread and affected so many major websites, 511 | drew significant public attention to the security vulnerabilities in software. 512 |

513 |

514 | In September 2014, another major security vulnerability was found in a key tool called Bash. Bash is included 515 | in popular operating systems like Linux and Mac OS, and as a result, is installed on more than 70% of the 516 | machines connected to the Internet. [96] The set 517 | of security bugs, dubbed “Shellshock,” could be exploited to allow someone unauthorized access to a computer 518 | system. The vulnerabilities had gone undetected for at least a decade. Bash was originally authored by a 519 | developer named Brian Fox in 1987, but since 1992 has been maintained by a single developer, Chet Ramey. He 520 | works as a senior technology architect at Case Western University in Ohio. 521 |

522 |

523 | Another project, OpenSSH, provides a free suite of security-related programs with widespread use across the 524 | web. Developers have discovered multiple security vulnerabilities in its code that have been subsequently 525 | addressed and fixed, including one in July 2015 that could allow attackers to bypass limits on password login 526 | attempts, and one in January 2016 that could leak private security keys. [97] [98] 528 |

529 |

530 | Part of the problem is that many open source projects are legacy tools, built once by a passionate developer or 531 | group of developers, who then lacked resources to manage their project’s success. Over time, contributions 532 | decline as others get bored and move on, but the project is still in active use, leaving one or two people to 533 | figure out how to keep it alive. 534 |

535 |

536 | Another growing issue in today’s software world, with so many new and inexperienced developers, is that 537 | security concepts are not taught or prioritized. New developers simply want to write code that works; they 538 | don’t know how to make software secure, or they mistakenly assume that the public code they use in their 539 | software has been audited for security. Even best practices around safely disclosing or managing 540 | vulnerabilities are not commonly taught or understood. Security only becomes an issue once a developer’s code 541 | has become compromised. 542 |

543 |

544 | Christopher Allen coauthored the first version of the Transport Layer Security (TLS) protocol, whose subsequent 545 | versions became a security standard used almost universally online, including by websites like Google, Facebook 546 | and YouTube. Although today it is a standard, of its origins, Christopher writes: 547 |

548 |
549 |

550 | As the co-author of TLS I would not have predicted 15 years later that over half of the Internet would be 551 | using an implementation of TLS maintained by a 1/4 time engineer. This lack of support led to the infamous 552 | Heartbleed bug. I tell my cryptocurrency colleagues this story today to warn them that their leading edge 553 | crypto today may be “boring” in a decade and suffer the same fate as it will no longer be exciting and their 554 | future hard work may be compromised.[99] 555 |

556 |
557 |

558 | Finally, the stability of our software potentially relies upon the good faith and cooperation of hundreds of 559 | developers, which introduces significant risk. The fragility of our digital infrastructure was recently 560 | demonstrated by a developer named Azer Koçulu. 561 |

562 |

563 | Azer, a Node.js developer, hosted a number of libraries on a package manager platform called npm. After a 564 | conflict with npm over trademark rights on one of his projects, Azer, frustrated with the outcome, decided to 565 | remove everything he had ever published to npm. [100] One of those libraries, left-pad, was referenced in hundreds of other software 567 | projects. Although it was just a few lines of code, by removing the left-pad project, Azer broke countless 568 | other software developers’ processes. Azer’s decision caused so many issues that npm made the unprecedented 569 | decision to republish his library, against Azer’s will, in order to restore functionality to the rest of the 570 | ecosystem. [101] Npm also revised its policies 571 | to make it harder for developers to remove their libraries without warning, recognizing how individual actions 572 | could negatively affect so many others. [102] 573 |

574 |

575 | Software not getting the necessary maintenance it needs 576 |

577 |

578 | Building digital infrastructure in a haphazard fashion means that all software gets built more slowly and 579 | inefficiently. One example of this can be found in the history of Python infrastructure. 580 |

581 |

582 | An important infrastructure project for Python developers is called Setuptools. Setuptools provides a set of 583 | tools that make writing Python easier and more standardized. 584 |

585 |

586 | Setuptools was written by a developer named PJ Eby in 2004. Over the next four years, Setuptools saw widespread 587 | adoption. However, Setuptools was difficult to implement and use, and Eby was largely unreceptive to outside 588 | contributions and fixes, wanting to maintain —as its original author— final say over Setuptools. In 2008, a 589 | group of developers, led by Tarek Ziade, decided to fork the project to force Eby to make improvements. They 590 | called the new project Distribute. 591 |

592 |

593 | In 2013, these projects were once again merged under Setuptools. The multi - year rift, however, underscored 594 | both the dubious state of Python’s infrastructure tools, and the difficulty of making improvements —in part 595 | because there was nobody dedicated and willing to address the community’s problems. 596 |

597 |

598 | Python tools began to improve once the working group Python Packaging Authority (PyPA) was formed to focus 599 | specifically on setting better standards for packaging. One developer, Donald Stufft, made Python packaging 600 | tools his primary focus and was hired by HP (now under HPE) in May 2015 to continue his work. (His story will 601 | be discussed later in this report.) [103] 602 |

603 |

604 | Another example involves RubyGems.org, a website that most Ruby developers use to host their Ruby libraries. 605 | Ruby has been used to build major websites including Twitter, AirBnB, YellowPages, and GitHub itself. 606 |

607 |

608 | In 2013, a security flaw in RubyGems.org was discovered, but went unfixed for several days, because 609 | RubyGems.org was maintained entirely by volunteers. The volunteers planned to address it that weekend, but in 610 | the meantime someone else discovered the flaw and hacked the RubyGems.org server. Following the hack, the 611 | servers had to be rebuilt from scratch. Several volunteers took time off work, and some even took personal 612 | vacation days, in order to get RubyGems.org up and running again as soon as possible. Because RubyGems.org is a 613 | critical piece of Ruby infrastructure, the security issue affected many developers and companies in turn. 614 |

615 |

616 | The incident highlighted how pure volunteer labor limited the amount of security and reliability that could be 617 | provided to important software infrastructure. Dozens of developers “volunteered” during the incident, since 618 | the problem affected their regular jobs. Unfortunately, none of them had the previous experience needed to be 619 | helpful, and none of them continued to offer to help once the servers were repaired. In 2015, an organization 620 | called Ruby Together was formed to help pay pay for maintenance and development of Ruby’s infrastructure, 621 | including RubyGems.org, using company sponsorships. [104] 623 |

624 |

625 | Loss of qualified labor 626 |

627 |

628 | Like any community of volunteers, burnout is common among open source contributors, who find themselves 629 | fielding requests, from both individual users and companies , for work without compensation. 630 |

631 |

632 | Many developers have stories about getting requests from companies for free work. Daniel Roy Greenfeld, a 633 | Python and Django developer, wrote: 634 |

635 |
636 |

637 | I personally get regular demands for unpaid work (Discussions about payment for work always stall) by healthy 638 | high profit companies large and small for [my projects]. If I don't respond in a timely fashion, if I'm not 639 | willing to accept a crappy pull request, I/we get labeled a jerk. There is nothing like having core 640 | Python/PyPA maintainers working for Redhat [sic] demanding unpaid work while criticizing what they consider 641 | your project's shortcomings to ruin your day and diminish your belief in open source.[105] 643 |

644 |
645 |

646 | (Red Hat is a multinational software company with annual revenue exceeding $2B which sells open source software 647 | solutions to enterprise customers. [106] 648 | Because of the nature of their business, Red Hat employees use and contribute to many open source projects; in 649 | some ways, Red Hat has become the business poster child of open source. The company’s financial success will be 650 | discussed later in this report.) 651 |

652 |

653 | Read the Docs, the aforementioned documentation hosting service, explicitly states on its website that they do 654 | not support custom company installations and private support. [107] One of the maintainers, Eric Holscher, went as far as to comment, Pretty sure 656 | there is very little value in Read the Docs being open source, as private users never contribute back, only ask 657 | for free support. [108] 658 |

659 |

660 | Marquess, the OpenSSL contributor, made a tongue-in-cheek remark to these repeated requests in his post about 661 | funding: 662 |

663 |
664 |

665 | I’m looking at you, Fortune 1000 companies. The ones who include OpenSSL in your 666 | firewall/appliance/cloud/financial/security products that you sell for profit, and/or who use it to secure 667 | your internal infrastructure and communications. The ones who don’t have to fund an in-house team of 668 | programmers to wrangle crypto code, and who then nag us for free consulting services when you can’t figure 669 | out how to use it. The ones who have never lifted a finger to contribute to the open source community that 670 | gave you this gift. You know who you are.[109] 672 |

673 |
674 |

675 | Some developers choose to stop maintaining their projects because they no longer have the time to dedicate to 676 | it, and hope that somebody else picks up where they left off. Meanwhile, companies, governments and individuals 677 | depend on these libraries for their continued use, unaware of the underlying situation. 678 |

679 |

680 | David Michael Ross, an engineering manager at a web agency, wrote of his experience: 681 |

682 |
683 |

684 | That's the big thing for me. [...] It's knowing you did something for free, out of love, and there's an 685 | endless stream out people going more! more! and getting angry when you won't accommodate their edge 686 | case. 687 |

688 |

689 | I had my phone number on one of my personal sites so friends could get in touch with me. Took it down after a 690 | week because people would call me in the middle of the day for plugin support, even though there's a forum 691 | for support. There's nothing inherently wrong with that, it just wears you down. Makes you afraid to check 692 | email or answer the phone.[110] 693 |

694 |
695 |

696 | Ryan Bigg, who writes documentation for the software framework Ruby on Rails, announced in November 2015 that 697 | he was quitting all open source work, explaining: 698 |

699 |
700 |

701 | I do not have the time or energy to invest in open source any more. I am not being paid at all to do any open 702 | source work, and so the work that I do there is time that I could be spending doing "life stuff," or writing. 703 | It is not fair to expect me to do even more work outside of my regular work, and then not get fairly 704 | compensated (time or money) for it. It's also a great recipe for burnout and making me just generally 705 | grumpy.[111] 706 |

707 |
708 |

709 | Loss of qualified labor also does not just refer to open source contributors who quit, but those who never join 710 | in the first place. 711 |

712 |

713 | T here are very few statistics on the demographics of open source contributors, which is telling in itself. A 714 | recent analysis of GitHub found that just 5.4% of open source contributors were women, compared to roughly 15 715 | to 20% of technical roles at software companies overall. [112] 717 |

718 |

719 | One reason why open source contributors are strikingly more homogenous than the technology sector at large is 720 | that they need time and money to make significant contributions in the first place. These constraints prevent 721 | otherwise qualified contributors from entering the space. 722 |

723 |

724 | David MacIver, creator of Hypothesis, a Python library for testing software applications, explains why he was 725 | able to spend so much time on the project: 726 |

727 |
728 |

729 | I could only do this because I had the time and money to do so. I had the time to do so because I was being 730 | obsessive, had no dependents, and didn’t have a job. I could only not have a job because of the money. I only 731 | had the money because I spent the latter half of last year with double the salary I was used to, half the 732 | living expenses I was used to, and too borderline depressed to spend it on anything interesting. These are 733 | not reasonable requirements. [...] Can you produce quality software in less time than that, working only in 734 | your free time? I doubt it.[113] 735 |

736 |
737 |

738 | Cory Benfield, a core Python developer, writes: 739 |

740 |
741 |

742 | Generally speaking, people who aren’t cisgender, heterosexual, white, middle-class, English-speaking men are 743 | less able to tolerate the increased financial risk of not having a steady job. This means that those 744 | individuals really need a steady pay cheque to contribute most effectively. And we *need* those contributors: 745 | diverse teams make better things than homogeneous teams.[114] 747 |

748 |
749 |

750 | Charlotte Spencer, a contributor to software framework Hoodie and database PouchDB, echoes these sentiments: 751 |

752 |
753 |

754 | All my contributions are purely volunteered. I don't make any money, though I would absolutely like to. I 755 | have asked veteran open sourcerers if they are paid and they say they are not, which discouraged me from 756 | pursuing anything (if they aren't paid, why would I be?). I use most of my free time to do it, which I'm 757 | trying to do less of as it was taking up my life.[115] 759 |

760 |
761 |

762 | Jessica Lord, a developer, actively contributed to open source while working at Code for America, a nonprofit 763 | organization that supports technology in the public sector. An urban planner by education, she stresses that 764 | she had no computer science degree, no real production programing [sic] experience but a GitHub 765 | portfolio.[116] Her regular contributions 766 | drew the attention of GitHub itself, where she now works today. 767 |

768 |

769 | However, Jessica points out that she was able to contribute to open source under a “privileged” set of 770 | circumstances: she took a pay cut to work at Code for America, burned through her savings, worked “nearly 771 | constantly” on open source projects, and had a community of support. 772 |

773 |

774 | Of lack of diversity in open source, Jessica writes: 775 |

776 |
777 |

778 | The value of common knowledge cannot be overestimated. We must to do better. We need all the ideas from all 779 | the people. That's what we should be aiming for. 780 |

781 |

782 | We need an open source for everyone. Not just for the privileged and not even just for the 783 | developers.[117] 784 |

785 |
786 |

787 | Jessica’s last point also underlines how enabling more diverse perspectives in open source can help sustain 788 | open source itself. From a functional perspective, the vast majority of open source contributors are 789 | developers, but plenty of other roles are needed to sustain larger projects, including writing, project 790 | management, and outreach. Open source projects are not dissimilar from other types of organizations, including 791 | startups, where administration, marketing, design, and other roles are needed to support an organization’s raw 792 | output. It is partially because open source culture is so heavily weighted to developers that sustainability is 793 | rarely discussed or acted upon. 794 |

795 |

796 | Finally, the homogeneity of open source contributors impacts diversity efforts in technology at large, because 797 | it is so closely tied to hiring. As previously mentioned, many employers use open source contributions, 798 | including GitHub profiles, to discover potential new hires or to check a candidate’s qualifications. Employers 799 | who rely heavily upon evidence of open source contributions are drawing from an extremely narrow pool of 800 | candidates. 801 |

802 |

803 | Ashe Dryden, in an influential essay called The Ethics of Unpaid Labor and the OSS 804 | Community, explained: 805 |

806 |
807 |

808 | Deciding that someone is a good programmer based solely on their publicly available code excludes far more 809 | than marginalized people. It also excludes anyone who can't release their code publicly because of licensing 810 | or security reasons. This also includes a large number of freelancers and contractors who are unable to 811 | publicly claim that they worked on a project for legal reasons (NDAs, for instance). In an industry where we 812 | are struggling to find enough talent, why are we artificially limiting the talent pool?[118] 814 |

815 |
816 |

817 | How can we mitigate or avoid some of these costs associated with participating in the building of digital 818 | infrastructure today? First, let’s look at how infrastructure projects are currently supported. 819 |

820 |
821 | 822 | 823 | -------------------------------------------------------------------------------- /src/EPUB/copyright.xhtml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Roads and Bridges 7 | 8 | 9 | 10 | 11 | 12 | 28 | 29 | 30 | -------------------------------------------------------------------------------- /src/EPUB/cover.xhtml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Roads and Bridges 7 | 8 | 9 | 10 | 11 | 12 | Roads and Bridges 13 | 14 | 15 | -------------------------------------------------------------------------------- /src/EPUB/current-system.xhtml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Roads and Bridges 7 | 8 | 9 | 10 | 11 | 12 |

13 | How The Current System Works 14 |

15 |
16 |

17 | What is digital infrastructure, and how does it get built? 18 |

19 |

20 | Earlier in this report, we compared building software to constructing a building. Those public software 21 | components are what collectively form our digital infrastructure. To understand this concept, consider how 22 | physical infrastructure works. 23 |

24 |

25 | Everybody relies upon a number of physical infrastructure projects to facilitate our day-to-day lives. Turning 26 | our lights on, driving to work, washing dishes: we may not often think about where our water, roads or 27 | electricity come from, but we have physical infrastructure to thank. Private and public partners work together 28 | to build and maintain our transportation, sewage, water, electric, and communication systems. 29 |

30 |

31 | Similarly, although we do not often see or think about the apps and software we use on a daily basis, all of 32 | them rely upon free and public code to function. Together, in an increasingly digital society, these open 33 | source projects make up our digital infrastructure. 34 |

35 |

36 | However, there are several major differences between physical and digital infrastructure, which affect how the 37 | latter is built and sustained. In particular, there are differences in cost, maintenance, and 38 | governance. 39 |

40 |

41 | Digital infrastructure is faster and cheaper to build. 42 |

43 |

44 | Building p hysical infrastructure is notoriously expensive. These projects are physically large in scale and 45 | can take months or years to complete. 46 |

47 |

48 | The United States federal government spent $96 billion on infrastructure projects in 2014, and state and local 49 | governments spent a combined $320 billion in the same year. Slightly less than half (43 percent) of that spend 50 | ing went towards new construction; the remainder was spent on operations and upkeep of existing infrastructure. 51 | [34] 52 |

53 |

54 | Proposing and funding new physical infrastructure projects can be an extended political process. Transportation 55 | funding has been a contentious topic in the United States for the past decade, where the federal government 56 | faces a $16 billion shortfall for transportation funding. [35] U.S. Congress recently passed the first multi-year transportation bill in a decade, 58 | setting aside $305B for highways, after years of political obstacles that prevented funding infrastructure from 59 | being funded more than two years at a time. [36] 60 |

61 |

62 | Even after a new infrastructure project has been earmarked and funded, it can take years to complete, fraught 63 | with uncertainties and unforeseen obstacles. The Central Artery/Tunnel project in Boston, Massachusetts, also 64 | known as the Big Dig, took nine years from planning to initial construction. Its projected cost was $2.8 65 | billion, with a scheduled completion date for 1998. In reality, the project ended up costing $14.6 billion and 66 | was not completed until 2007, making it the most expensive highway project in the United States. [37] 68 |

69 |

70 | By contrast, digital infrastructure does not have any of the costs associated with building physical 71 | infrastructure, such as zoning a location or purchasing materials. This makes it easy for anyone to propose a 72 | new idea and get started in very little time. 73 |

74 |

75 | MySQL, the second most popular database in the world [38] and part of a critical collection of tools that helped launch the first tech boom, 77 | was published by its authors, Michael Widenius and David Axmark, in May 1995. It took less than two years to 78 | develop. [39] 79 |

80 |

81 | Ruby, a programming language, took less than three years from its initial conception in February 1993 to public 82 | release in December 1995. Its author, computer scientist Yukihiro Matsumoto, decided to create the language 83 | after a conversation with his colleagues. [40] 84 |

85 |

86 | Digital infrastructure changes frequently. 87 |

88 |

89 | Because digital infrastructure is so cheap to build, the barriers to entry are lower, and software tools change 90 | more frequently. 91 |

92 |

93 | Physical infrastructure is built to last, which is partially why these projects take so long to plan, fund , 94 | and build. The London Underground, London’s public rapid transit system, was built in 1863; the underground 95 | tunnels dug for the subway system are still in use today. [41] The Brooklyn Bridge, which connects the boroughs of Brooklyn and Manhattan in New 97 | York City, was completed in 1883 and did not undergo any major renovations until 2010, over one hundred years 98 | later. 99 |

100 |

101 | Digital infrastructure not only requires frequent maintenance and upkeep to be compatible with other software 102 | components, but its usage and adoption changes frequently as well. A bridge built in the middle of New York 103 | City will have fairly consistent and guaranteed usage, commensurate with the rise or decline of the city’s 104 | population. But a programming language or framework could be extremely popular for several years, then fall out 105 | of favor when something faster, more efficient, or simply trendier comes along. 106 |

107 |

108 | For example, the graph below shows activity by source code developers using several different programming 109 | languages. The language C, one of the most fundamental and widely used languages, has dropped in market share 110 | as newer languages have entered the market. Python and JavaScript, two currently popular languages, are seeing 111 | a moderate rise over time. And Go, which was developed in 2007, has seen more activity in recent years. 112 | [42] 113 |

114 |
115 | Graph of monthly code commits 116 |
117 |

118 | Tim Hwang, who runs the Bay Area Infrastructure Observatory, which organizes group visits to physical 119 | infrastructure sites, remarked on the difference in a 2015 interview with California Sunday 120 | Magazine: 121 |

122 |
123 |

124 | A lot of [our] members work in tech, either on the web or on software. As a result, they work on things that 125 | don’t last very long. Their approach is, ‘We just hacked it, and we pushed it out live,’ or ‘We just released 126 | it, and we can work out bugs later.’ A lot of infrastructure is built for 100 years. You can’t have bugs. If 127 | you do, the building will fall down. You can’t iterate it. It’s a practice that exists outside of the 128 | members’ day-to-day experience.[43] 129 |

130 |
131 |

132 | Because digital infrastructure changes so frequently, however, older projects have a harder time finding 133 | contributors, because many developers prefer to work on new and exciting projects. This phenomenon has been 134 | referred to as “magpie developer” syndrome, where developers are attracted to “new and shiny” things, instead 135 | of the technology that works best for them and their users. [44] 137 |

138 |

139 | Digital infrastructure does not have a central organization to determine what gets built or used. 140 |

141 |

142 | Finally, perhaps the most striking difference between digital and physical infrastructure, and one of the 143 | biggest challenges to its sustainability, is that there is no organizing body to determine what gets built or 144 | used in digital infrastructure. 145 |

146 |

147 | Transportation, sewage and water projects are generally owned and managed by the government, whether federal, 148 | state or local. Communication and electric projects tend to be managed by private companies. In both 149 | situations, infrastructure projects are funded by a mix of private and public actors, either from the federal 150 | budget, private company financing, or metered user fees. 151 |

152 |

153 | In a stable, developed country, we rarely think about whether or how a road gets built or a building has 154 | electricity. Even for projects that are privately owned or funded, the federal government has a vested interest 155 | in guaranteeing that physical infrastructure gets built and maintained. 156 |

157 |

158 | Digital infrastructure projects, on the other hand, are conceived of and built from the bottom up. It is akin 159 | to a group of citizens getting together and deciding they want to build a bridge or create their own sewage 160 | system. There is no authoritative body whose formal permission is required to create new digital 161 | infrastructure. 162 |

163 |

164 | The Internet itself does have two major governing bodies that help set standards: the Internet Engineering Task 165 | Force and World Wide Web Consortium. 166 |

167 |

168 | The Internet Engineering Task Force (IETF) helps develop and set voluntary standards for how information gets 169 | passed around the Internet. For example, they are the reason why URLs start with “HTTP”. They are also the 170 | reason why we have IP addresses — unique identifiers assigned to your computer when it is connected to a 171 | network. Originally a working group within the United States government in 1986, the IETF became an 172 | independent, international organization in 1993. [45] The IETF itself is run by volunteers, and there are no membership requirements: 174 | anyone from the public may join simply by declaring him- or herself a member. 175 |

176 |

177 | The World Wide Web Consortium (W3C) helps set standards for the World Wide Web. It was founded by Tim 178 | Berners-Lee in 1994. The W3C tends to focus more exclusively on web pages and documents ( they are, for 179 | example, the reason why web pages use HTML for basic formatting). They maintain the standards around the markup 180 | language HTML and stylesheet formatting language CSS, two basic components of any web page. The W3C’s 181 | membership is slightly more formalized, requiring an application and fee, and its members rang e from 182 | businesses to universities to individuals. 183 |

184 |

185 | The IETF and W3C help manage standards around the most fundamental pieces of the Internet, but the next layer 186 | up —choices about which languages are used to build software, which frameworks to build them with, or which 187 | libraries to include — are entirely self-managed in the public domain. (Certainly, many proprietary software 188 | projects, particularly those with heavy regulation, such as aeronautics or health care, may have requirements 189 | on which tools are used. They may even build proprietary tools for their own use.) 190 |

191 |

192 | With physical infrastructure, if the government builds a new bridge between San Francisco and Oakland, that 193 | bridge will certainly be used. Similarly, when the W3C wants to set a new standard, such as a new version of 194 | HTML, it is formally published and announced. For example, in 2014, the W3C announced HTML5, the first major 195 | revision of HTML since 1997, which had been in development for seven years. 196 |

197 |

198 | By contrast, when a computer scientist wants to create a new programming language, he or she is free to publish 199 | it and it may or may not be adopted. The bar for adoption is even lower for frameworks or libraries: because 200 | they are easier to build, and easier for a user to learn and implement, these tools are iterated more 201 | frequently. 202 |

203 |

204 | More importantly, nobody is forcing or even strongly encouraging anyone to use these projects. Some projects 205 | remain more academic than practical; others are ignored completely. It is difficult to predict what gets used 206 | until others are actually using it. 207 |

208 |

209 | Developers like to point to usefulness as an indicator of whether a new project gets adopted or not. 210 | New projects should make an improvement to an existing project, or solve a chronic problem, in order to be 211 | deemed useful and worthy of adoption. When developers are asked why their project got so popular, many of them 212 | will shrug and simply say, It was the best thing out there. 213 |

214 |

215 | Not unlike technology startups, new digital infrastructure projects rely upon network effects for 216 | adoption. Getting a core group of developers excited, or a software company using the project, helps spread the 217 | word. A catchy name, branding, or website can add to the project’s novelty factor. A developer’s reputation 218 | within their respective community also helps determine whether a new project gets noticed. 219 |

220 |

221 | However, in the end, a new digital infrastructure project can come from just about anywhere, which means each 222 | project is managed and sustained in very different ways. 223 |

224 |
225 |
226 |

227 | How are digital infrastructure projects managed and supported? 228 |

229 |

230 | We’ve established that digital infrastructure is as critical to modern society as physical infrastructure. 231 | Although digital infrastructure is not subject to the high costs and political obstacles of physical 232 | infrastructure, its decentralized nature also makes it harder to pin down. Without a central governing body, 233 | how do open source projects find the support they need? 234 |

235 |

236 | In short, the answer is different for every project. However, there are several places where projects might 237 | originate: within a company, as a new business, or from an individual or community of developers. 238 |

239 |

240 | Within a company 241 |

242 |

243 | Sometimes, the project starts within a company. Here are a few examples that demonstrate the different ways in 244 | which an open source project might be supported by a company’s resources: 245 |

246 | 275 |

276 | The incentives for a company to maintain an open source project are numerous. Opening up a project to the 277 | public can mean less work for the company, which is essentially crowdsourcing improvements. It builds goodwill 278 | and awareness among developers, who might then be incentivized to use other company resources to build things. 279 | Having an active community of developers creates a recruiting pipeline for talent. And sometimes, open sourcing 280 | a project helps a company strengthen their user base and brand, or even drown out competition. The more market 281 | share a company can capture, even through tools it gives away, the more influential it becomes. This is not 282 | dissimilar to the “loss leader” concept of business. 283 |

284 |

285 | Even if a project is created internally, if it is open sourced, that project is free to use or modify according 286 | to the terms of an open source license, and is not considered company intellectual property in the traditional 287 | sense. Many company projects use standard open source licenses that are considered acceptable by the broader 288 | developer community, such as Apache License 2.0 or BSD. However, in some cases, companies add their own 289 | clauses. React, for example, has an additional clause that could potentially cause patent claim conflicts with 290 | React users. [50] As a result, some companies 291 | and individuals are reluctant to use React, and the decision is frequently portrayed as in conflict with open 292 | source principles. 293 |

294 |

295 | As a new business 296 |

297 |

298 | S ome infrastructure projects take a traditional startup path, including venture funding. A couple of examples 299 | are as follows: 300 |

301 | 332 |

333 | The venture funding approach is relatively new, and growing rapidly. Lightspeed Venture Partners found that 334 | from 2010-2015, venture firms invested over $4B in open source companies, a tenfold increase over the five 335 | previous years.[55] 336 |

337 |

338 | Using venture capital to support open source projects has been met with skepticism from developers (and even 339 | some venture capitalists themselves), due to lack of clear business models and questionable revenue to justify 340 | valuations. Steve Klabnik, a maintainer for the language Rust, explains venture capital’s sudden interest in 341 | funding open source: 342 |

343 |
344 |

345 | I’m a VC. I need a large number of companies to exist to make my money….I need costs to be low and profits to 346 | be high. I need a healthy open source ecosystem to make this happen. So what do I do?...VCs are realizing 347 | this story, and are starting to invest in infrastructure. [...] 348 |

349 |

350 | In many ways, the open source stuff is a loss leader, so that you get hooked...and then use it for 351 | everything, even your closed source code. This is a great business strategy, but it also places GitHub at the 352 | center of this new universe. So for similar reasons, a16z needs GitHub to be awesome to bootstrap every open 353 | source ecosystem that will exist into the future….And a16z has the money to “throw away” on something they 354 | won’t get a direct return out of, because they’re smart enough to invest some of their fund in ecosystem 355 | development.[56] 356 |

357 |
358 |

359 | GitHub, created in 2008, is a platform for code, available publicly or privately in an easy-to-read 360 | environment. It hosts many popular open source projects and, most importantly, has become the cultural 361 | epicenter for open source’s explosive growth (to be discussed later in this report). 362 |

363 |

364 | GitHub did not take any venture capital until 2012, four years after its founding. Before then, GitHub was a 365 | profitable company. Since 2012, GitHub has taken $350M in total venture capital funding. [57] Andreessen Horowitz (or “a16z”), the $4B venture capital 367 | firm who provided most of the capital in their first $100M round, stated it was the largest investment they had 368 | ever made at the time. [58] 369 |

370 |

371 | Steve Klabnik’s thesis, in other words, is that venture capital firms who invest in open source infrastructure 372 | promote these platforms as a “loss leader,” even when there is no direct business model or profitability to be 373 | had, because it grows the entire ecosystem. The more resources GitHub has, the more open source thrives. The 374 | more open source thrives, the more startups thrive. If nothing else, venture capital’s interest in open source, 375 | especially given the lack of clear financial return, validates the critical role open source plays in the 376 | broader startup ecosystem. 377 |

378 |

379 | (As an aside, it is important to mention that GitHub, the platform itself, is not an open source project, and 380 | therefore is not an example of venture capital directly funding open source. GitHub is a closed source platform 381 | that hosts open source projects. This is a controversial topic for some open source contributors.) 382 |

383 |

384 | By individuals or a group of individuals 385 |

386 |

387 | Finally, many digital infrastructure projects are developed and maintained entirely by independent developers, 388 | or a community of developers. A few examples are as follows: 389 |

390 | 425 |

426 | As these examples demonstrate, open source projects can come from just about anywhere. This is, generally, 427 | considered to be a good thing. It means that useful projects are more likely to succeed, avoiding both 428 | the vacuous hype associated with startups, and the bureaucracy associated with government. Digital 429 | infrastructure’s decentralized nature also reinforces the open and democratic principles of the Internet, where 430 | anybody could theoretically create the next big project, whether a company or individual. 431 |

432 |

433 | On the other hand, many useful projects will come from independent developers who suddenly find themselves at 434 | the helm of a successful project, facing critical decisions about its future. A 2015 study by the Federal 435 | University of Minas Gerais in Brazil looked at 133 of the most actively used projects hosted on GitHub, across 436 | programming languages, and found that 64%, or nearly two-thirds, relied upon just one or two developers to 437 | survive. [65] Although there may be a long tail 438 | of casual or infrequent contributors, for many projects, the major responsibilities of project management fall 439 | on just a few people . 440 |

441 |

442 | Coordinating international communities of opinionated contributors and managing the expectations of Fortune 500 443 | companies who use your project are challenging tasks for anyone. It is truly impressive how much has already 444 | been accomplished in this manner. These tasks are especially difficult when developers lack clear role models 445 | or institutional support for this work. In interviews for this report, many developers privately lamented that 446 | they have no idea who to ask for help and would “rather just code.” 447 |

448 |

449 | Why do they keep doing it? The remainder of this paper will focus on how and why open source contributors 450 | maintain projects of massive scale and impact, and why it matters to all of us. 451 |

452 |
453 |
454 |

455 | Why do people keep contributing to these projects, when they’re not getting paid for it? 456 |

457 |

458 | Many digital infrastructure projects are maintained by individual contributors or a community of contributors. 459 | In most cases, these contributors are not being paid directly to work on the project. Instead, they contribute 460 | for reasons that are unique to open source communities, including building reputation and a public service 461 | mindset. This section will explore some of those motivations in greater detail. 462 |

463 |

464 | Contributing to open source builds one’s reputation. 465 |

466 |

467 | Building one’s reputation is perhaps the most practical reason why someone would want to contribute to an open 468 | source project. For developers, technical writers, or others, these projects help them prove themselves in 469 | public, giving them a chance to be part of something big and useful. 470 |

471 |

472 | Google runs a program called Google Summer of Code, which provides a summer stipend to student developers to 473 | contribute to popular open source projects. The program works well because the developers are students, new to 474 | the field of computer science, and eager to show off their skills. 475 |

476 |

477 | Developers, in particular, leverage open source contributions to build a portfolio of their work. In addition, 478 | by providing input on popular projects with active communities, a developer has a chance to build his or her 479 | reputation by making him or herself “known.” GitHub, the website previously mentioned, is a popular platform 480 | for collaborating on code. When a developer makes a contribution to a public software project, those 481 | contributions appear in his or her profile. A developer’s GitHub profile can serve as a portfolio for software 482 | companies, but only contributions to public (i.e., open source) projects are visible to anyone. 483 |

484 |

485 | However, reputation-based motivations also come with risks, especially among junior developers. A developer 486 | early in his or her career may contribute to an open source project for the sole purpose of getting hired, then 487 | stop contributing once this goal has been achieved. In addition, developers who are solely interested in 488 | building their portfolio may make lower quality contributions to the project that do not get accepted or even 489 | slow down the development process. Finally, if the purpose of making a public contribution is to build one’s 490 | reputation, a developer will be motivated to only contribute to popular or attractive projects (an extension of 491 | the “magpie developer” phenomenon mentioned earlier), which means that older projects struggle to find new 492 | contributors. 493 |

494 |

495 | The project became unexpectedly popular, and the maintainer feels obligated to support it. 496 |

497 |

498 | A popular open source project can create dependencies for other companies, individuals or organizations. In 499 | other words, the code is being used in live software, written and deployed by other people, that could serve 500 | any number of purposes, whether online shopping or health care. This complex set of dependencies (many of which 501 | are not visible even to the project author, since they do not have clear user data) can make a maintainer feel 502 | ethically obligated to continue supporting it. 503 |

504 |

505 | Arash Payan, the developer of Appirater mentioned in the beginning of this paper, released his project in 2009. 506 | Of his decision to continue maintaining the project, Payan says: 507 |

508 |
509 |

510 | It's not terribly exciting stuff, but there are so many people out there that use (depend, even?) on the 511 | project for their apps, that I feel obligated to be a good steward of it. Personally, I've moved on from iOS, 512 | so maintaining an iOS library isn't exactly my first choice for a side project.[66] 514 |

515 |
516 |

517 | Payan estimates the project only takes roughly 1-2 hours per month to keep up-to-date, so he doesn’t mind the 518 | work. 519 |

520 |

521 | Some projects become unexpectedly popular but take more time to support. Andrey Petrov is an independent 522 | developer who wrote a Python library called urllib3. He released it in 2008 as a significant improvement to the 523 | existing standard library, and it became popular among Python developers. Today, every Python user depends on 524 | it. [67] 525 |

526 |

527 | Andrey made the project open source in hopes that other people would help support its continued development and 528 | upkeep. Andrey is a freelance developer — although he enjoys maintaining urllib3, he can only justify doing so 529 | in his free time, since he is not paid for his work. Cory Benfield, who is employed by Hewlett Packard 530 | Enterprise to help maintain critical Python libraries (which HPE uses and depends on), now works on urllib3 as 531 | part of his job. Cory’s arrangement has reduced some of the burden. 532 |

533 |

534 | The project is a labor of love. 535 |

536 |

537 | Eric Holscher is a creator of Read the Docs, which hosts software documentation. Documentation is the 538 | equivalent of an instruction manual. Just as one might need an instruction manual to figure out how to put a 539 | piece of furniture together, developers need documentation to figure out how to implement a project. Without 540 | proper documentation, it would be difficult for a developer to know how to get started. 541 |

542 |

543 | Read the Docs provides documentation for 18,000 software projects, including enterprise customers, and serves 544 | over 15 million page views per month. [68] 545 | Although they make some money from large business clients, Read the Docs is still mostly funded by donations 546 | from its users. A company called Rackspace sponsors their server costs. 547 |

548 |

549 | Eric and his cofounder, Anthony Johnson, maintain the project, and do not see steady income from it, despite 550 | working on the project full-time. A $48,000 one-time grant from the Mozilla Foundation in December 2015 will 551 | help cover their work for a short time. [69] 552 | They are currently experimenting with an advertising model ( that does not involve tracking their users ) to 553 | reach sustainability. [70] 554 |

555 |

556 | Eric notes that the difficulties lie not just in new development work, but non-coding functions like customer 557 | support, for which one of the maintainers must be on call every weekend in case of an emergency. When Eric 558 | explained why he continues to support the project, he called it a “labor of love”: 559 |

560 |
561 |

562 | Either humans are irrational or they don’t just follow money. Clearly there’s another motivation for me here. 563 | It’s a labor of love. I could close this project tomorrow and be done with it if I wanted to, but I’ve been 564 | doing it for 5 years and I don’t want to see that happen.[71] 566 |

567 |
568 |

569 | Eric is motivated to work on Read the Docs because he sees the tangible value it creates for others. For many 570 | project maintainers, impact is a primary motivator, because they see how their direct efforts positively affect 571 | other people’s lives. In this sense, open source work shares many similarities to the nonprofit sector. Much 572 | like the nonprofit sector, however, this “labor of love” mentality can make it harder for open source 573 | communities to discuss the elephant in the room: how to sustain projects that require more resources and 574 | attention than current contributors can offer. 575 |

576 |
577 | 578 | 579 | -------------------------------------------------------------------------------- /src/EPUB/history.xhtml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Roads and Bridges 7 | 8 | 9 | 10 | 11 | 12 |

13 | History and Background of Digital Infrastructure 14 |

15 |
16 |

17 | How software gets built 18 |

19 |

20 | Every website or mobile app we use, no matter how simple, is made up of many smaller components, just as a 21 | building is made up of bricks and concrete. 22 |

23 |

24 | For example, imagine you want to post a photo to Facebook. You open your Facebook mobile app, which triggers 25 | Facebook’s software to show your news feed. 26 |

27 |

28 | You upload a photo from your phone, add a comment, then hit “submit.” Another part of Facebook’s software, 29 | responsible for storing data, remembers who you are and posts the photo to your profile. 30 |

31 |

32 | Finally, a third part of Facebook’s software takes the information that you typed into your phone and shows it 33 | to all your friends around the world. 34 |

35 |

36 | Although these interactions take place on Facebook, Facebook did not actually build all the pieces necessary to 37 | make it possible for you to post to their app. Instead, they use free, public code, made available on the 38 | Internet by volunteers for anybody to use. Facebook does not publicly list the projects they use, but another 39 | company they own, Instagram, lists and thanks some of these projects on their homepage and mobile app. 40 | [10] 41 |

42 |

43 | Using public code is more efficient for a company like Facebook than building every piece themselves. Building 44 | software is like constructing a building. A construction company wouldn’t build its hammers and drills from 45 | scratch, or source and chop all of the lumber themselves. Instead, it buys the tools from a hardware store, and 46 | the lumber from a third-party supplier, to make the job go faster. 47 |

48 |

49 | Thanks to permissive licenses, companies like Facebook or Instagram are not obligated to pay for this code , 50 | but are free to profit handsomely from it. This is not unlike a trucking company (Instagram) using a highway 51 | (public code) to transport goods for commercial purposes (Instagram’s app). 52 |

53 |

54 | Mike Krieger, one of Instagram’s cofounders, emphasized this point in 2013, encouraging other founders to 55 | borrow instead of building whenever possible. There are hundreds of fantastic [tools]...that can save you 56 | time and let you focus on actually building out your product. [11] 58 |

59 |

60 | Some tools that a software company uses are: 61 |

62 | 107 |

108 | Some of these tools, such as servers and databases, cost money, especially as companies scale. This makes them 109 | easier to monetize. For example, Heroku, a cloud-based platform that offers server and database support, offers 110 | basic services for free, but charges for higher levels of data or traffic. Heroku powers many major websites, 111 | including Toyota and Macy’s, and was acquired by Salesforce.com in 2010 for $212M. [12] 113 |

114 |

115 | Other types of developer tools, such as frameworks, many libraries, and programming languages, are harder to 116 | charge for, and are often built and maintained by volunteers. 117 |

118 |

119 | Because these types of tools look more like information goods than services that can be turned on or off, 120 | charging for them would severely limit their adoption. As a result, anyone—whether a billion-dollar company or 121 | a teenage coder—can use these components to build their own software for free. 122 |

123 |

124 | For example, one of the libraries that Instagram uses, according to its homepage, is Appirater. Appirater is a 125 | library that makes it easy to remind iPhone users to rate a mobile app. It was created in 2009 by Arash Payan, 126 | a freelance developer based in Los Angeles. Payan does not make any income from the project. 127 |

128 |

129 | It is the equivalent of lumberyards, concrete plants and hardware stores donating their raw materials to a 130 | construction company, then continuing to support the company’s needs. 131 |

132 |
133 |
134 |

135 | How not charging for software transformed society 136 |

137 |

138 | An expected first reaction is: Why did these developers make their software free? Why not just charge for 139 | it? 140 |

141 |

142 | The reasons for public software lie in its rich political and social history. But first, let’s examine a hard 143 | truth: our society wouldn’t be where it is today if developers hadn’t made it free. 144 |

145 |

146 | Free software makes it exponentially cheaper and easier to build software. 147 |

148 |

149 | Uber, a transportation service, recently announced that some developers had built a way to request cars through 150 | Slack, a team collaboration app, instead of using Uber’s own mobile app. The project was completed in 48 hours 151 | by a team of developers at App Academy, a coding school. 152 |

153 |

154 | Uber noted that the team was able to get the project done quickly because they implemented open libraries 155 | such as rails, geocoder, and unicorn [sic] to speed up development and build on a solid 156 | foundation.[13] 157 |

158 |

159 | In other words, the amount of coding that the team had to do themselves was greatly reduced because they were 160 | able to use free libraries built by others. 161 |

162 |

163 | Ruby Geocoder, for example, is a library built in 2010 and maintained by a freelance developer named Alex 164 | Reisner. Geocoder makes it easy for an application to look up street addresses and geographic coordinates. 165 | [14] 166 |

167 |

168 | Unicorn is a server, built in 2009, which is maintained by a team of seven contributors listed on its website 169 | and headed by a developer named Eric Wong. [15] 170 |

171 |

172 | It’s easier than ever to build new software, because there are more prefabricated pieces of code to draw from. 173 | To return again to the construction metaphor instead of constructing every piece of a building from scratch, 174 | one can simply buy a prefabricated framework, foundation and walls, then put them together like Legos. 175 |

176 |

177 | As a result, new developers are minted every day, even if they themselves don’t necessarily know how to build 178 | the tools from scratch. The Bureau of Labor Statistics expects the number of employed software developers to 179 | rise 22% from 2012 to 2022—much faster than average, compared to other occupations. [16] 181 |

182 |

183 | Free software is directly responsible for today’s current startup renaissance. 184 |

185 |

186 | The cost of starting a company has dropped dramatically since the first dotcom boom in the late 1990s. Venture 187 | capitalist and former entrepreneur Mark Suster reflected on his experience in a 2011 blog post: 188 |

189 |
190 |

191 | When I built my first company starting in 1999 it cost $2.5 million in infrastructure just to get started and 192 | another $2.5 million in team costs to code, launch, manage, market & sell our software. […] 193 |

194 |

195 | The first major change in our industry was imperceptible to us as an industry. It was driven by the 196 | introduction of open-source software, most notably what was called the LAMP stack. Linux (instead of UNIX), 197 | Apache (web server software), MySQL (instead of Oracle) and PHP. Of course there were variants – we preferred 198 | PostGres to MySQL and many people used other programming languages than PHP. 199 |

200 |

201 | Open source became a movement – a mentality. Suddenly infrastructure software was nearly free. We paid 10% of 202 | the normal costs for the software and that money was for software support. A 90% disruption in cost spawns 203 | innovation – believe me. [17] 204 |

205 |
206 |

207 | The availability of free software components today (as well as cheaper hosting and cloud services, like Amazon 208 | Web Services and Heroku) means that a technology startup no longer requires millions of dollars to get off the 209 | ground. Entrepreneurs can conceivably release a product and find a market without spending a single dollar, 210 | then raise money from venture capitalists only after they’ve shown strong signs of demand. 211 |

212 |

213 | Alan Schaaf, the founder of Imgur, a popular image-sharing site and one of the top 50 most-trafficked sites in 214 | the world, famously said that the only money he ever spent to start the company was seven dollars to purchase 215 | the domain name. Imgur was profitable, and Schaaf did not take any outside money for 5 years before raising $40 216 | million from VC firm Andreessen Horowitz in 2014. [18] 218 |

219 |

220 | Venture capitalists and other institutional investors, in turn, have started writing smaller checks to 221 | companies, giving rise to new subsets of investing, including: 222 |

223 | 242 |

243 | $10M can fund a hundred companies today, compared to one or two in the 1990s. 244 |

245 |

246 | Free software made it easier for people of all demographics to learn to code, making technology accessible to 247 | the world. 248 |

249 |

250 | If you wanted to learn how to code at home today, you might start by learning Ruby on Rails. Rails is a popular 251 | software framework and Ruby is a programming language. Anyone with Internet access can install these tools on 252 | any computer for free. Because they are free, they are also very popular, which means there is plenty of 253 | information online to help you get started, from formal tutorials to question-and-answer forums. This means 254 | that learning how to code is as accessible as teaching oneself to read and write English or French. 255 |

256 |

257 | By comparison, software frameworks and languages that were not open source required paying for access, using 258 | specific operating systems or other tools, and agreeing to licensing constraints that could affect patents for 259 | any software built using the framework. Today, it is difficult to find examples of frameworks and languages 260 | that are not open source. One of the most famous examples of a proprietary software framework is .NET, 261 | developed and released in 2002. In 2014, Microsoft announced that they were releasing a version of .NET as an 262 | open source project, called .NET Core. 263 |

264 |

265 | Audrey Eschright, a software developer, wrote about how open source software helped her learn to code as a 266 | teenager in the late 1990s: 267 |

268 |
269 |

270 | I wanted to learn to program but I didn’t have money. Not the college student version of not having money—my 271 | family situation was low-income, but also highly chaotic….This is going to seem strange to anyone [today], 272 | but at the time there were basically two options for someone who wanted to write real software: you could use 273 | a PC with Windows and pay extra for Microsoft’s development tools, or you could have access to a Unix system 274 | and use gcc….So my goal became to get access to accounts on Unix systems so I could learn how to write code 275 | and do cool stuff. [19] 276 |

277 |
278 |

279 | Jeff Atwood, a longtime .NET developer, described his decision to use Ruby for a new software project, 280 | Discourse, in 2013: 281 |

282 |
283 |

284 | Getting up and running with a Microsoft stack is just plain too hard for a developer in, say, Argentina, or 285 | Nepal, or Bulgaria. Open source operating systems, languages, and tool chains are the great equalizer, the 286 | basis for the next great generation of programmers all over the world who are going to help us change the 287 | world. [20] 288 |

289 |
290 |

291 | With the explosion of startups have come a number of initiatives to teach people to code, whether they are 292 | children, teenagers, underserved minorities, women or career switchers. Some examples include Women Who Code, 293 | Django Girls, Black Girls Code, One Month and Dev Bootcamp. 294 |

295 |

296 | Some of these organizations are free, while others charge tuition. All of them rely upon free software to teach 297 | their students. For example, Django Girls has taught over 2,000 women to code, in 49 countries around the 298 | world. [21] Although the organization did not 299 | develop Django themselves, they are able to use Django, which students download and use for free, in their 300 | curriculum 301 |

302 |

303 | Dev Bootcamp teaches career switchers to code, preparing everyone from English teachers to military veterans to 304 | become professional software developers. The program costs $12-14,000. Dev Bootcamp teaches Ruby, JavaScript, 305 | Ruby on Rails and SQL, among other components. All of these components are free for students to download and 306 | use, and Dev Bootcamp does not have to pay to use these materials. Dev Bootcamp was recently acquired by Kaplan 307 | for an undisclosed sum in 2014. [22] 308 |

309 |

310 | If such critical pieces of software were not free, people from all walks of life would not be able to take part 311 | in today’s technology renaissance. There are still numerous social and economic barriers that prevent many more 312 | from participating, as well as costs associated with physical equipment like laptops and an Internet 313 | connection, but the programming tools themselves do not cost money. 314 |

315 |
316 |
317 |

318 | A brief history of free and public software and the people who made it 319 |

320 |

321 | Now that we’ve covered how making software free benefits society, let’s look at how the software itself came 322 | about. 323 |

324 |

325 | Although we’ve used the term “free software” to refer to software that does not cost any money to its users, 326 | the term “free software” is actually a highly contextualized term that refers specifically to the software’s 327 | license properties. Free software advocates emphasize that “free” refers to a political freedom rather than the 328 | price, and sometimes use the Spanish word libre (meaning freedom, as opposed to gratis, 329 | the Spanish word for free price) to clarify the distinction. 330 |

331 |

332 | In the 1970s, when computers were still a nascent technology, programmers had to build their own computers and 333 | write custom software themselves. Software was not yet standardized and was not considered to be a monetizable 334 | product. 335 |

336 |

337 | In 1981, IBM introduced the “IBM PC,” or “Personal Computer,” bringing hardware to a mass market. Within a 338 | couple of years, custom computer setups fell away as everybody adopted the IBM standard. IBM became the 339 | dominant computer within a highly fractured personal computer market, capturing over half of market share by 340 | 1986. [23] 341 |

342 |

343 | Along with standardized hardware, then, came an opportunity for standardized software. Suddenly everyone wanted 344 | to turn software into a business. IBM hired a then-unknown company called Microsoft to write the operating 345 | system for its new PC. That operating system, MS-DOS, was released in 1981. Other companies began to follow 346 | suit, offering software under commercial licenses. These licenses prevented the user from copying, modifying or 347 | redistributing the software. 348 |

349 |

350 | Proprietary software still exists today: for example, Adobe Photoshop, Microsoft Windows, or GoToMeeting. While 351 | proprietary software can be profitable for the company that builds and licenses the product, its restrictions 352 | also limit its scope and distribution. Any changes to the software’s design or implementation have to originate 353 | from the company itself. And proprietary software is expensive, often costing hundreds of dollars and 354 | permitting the designated purchaser to use only that copy. 355 |

356 |

357 | Understandably, some computer scientists felt concerned about the closed and proprietary direction that 358 | software was taking, believing that it undermined the true potential of software. Richard Stallman, a 359 | programmer at the MIT Artificial Intelligence Laboratory, felt particularly strongly about the need for 360 | software to be free and modifiable. 361 |

362 |

363 | Over the next couple of years, as several of his colleagues began working on proprietary software projects, 364 | Stallman felt he could not ignore the situation any longer. In 1983, he launched GNU, a free operating system, 365 | and in doing so sparked what came to be known as the “free software movement,” which galvanized a group of 366 | people who believed that software could have a greater reach and benefit to society if it were made freely 367 | available. Stallman later founded the Free Software Foundation in 1985 to support GNU and other free software 368 | efforts. 369 |

370 |

371 | The Free Software Foundation defines free software as software that gives the user the 372 | freedom to share, study and modify it.[24] 373 | GNU defines four freedoms associated with such software: 374 |

375 |
    376 |
  1. 377 |

    378 | Freedom 0: The freedom to run the program as you wish, for any purpose. 379 |

    380 |
    2. 381 |
  2. 382 |

    383 | Freedom 1: The freedom to study how the program works, and change it so it does your 384 | computing as you wish. 385 |

    386 |
    3. 387 |
  3. 388 |

    389 | Freedom 2: The freedom to redistribute copies so you can help your neighbor. 390 |

    391 |
    4. 392 |
  4. 393 |

    394 | Freedom 3: The freedom to distribute copies of your modified versions to others. By doing 395 | this you can give the whole community a chance to benefit from your changes.[25] 397 |

    398 |
    5. 399 |
400 |

401 | The free software movement was, and continues to be, deeply rooted in social advocacy. In 1998, when Netscape 402 | released the source code for its popular browser, the conversation began to shift from politics to technology. 403 |

404 |

405 | Some technologists believed that focusing on the practical benefits of free software would help bring its 406 | message to a wider audience. For example, they pointed out that free software was cheaper to build and could 407 | lead to superior software, because the public can find bugs and contribute fixes. This type of pragmatism was 408 | distinct from the moral obligation that Stallman and his supporters believed they had to promote free software. 409 |

410 |

411 | These technologists gathered in Palo Alto for a strategy session. Christine Peterson, a nanotechnologist in 412 | attendance, suggested the term “open source.” [26] Shortly after, two attendees, Bruce Perens and Eric Raymond, created the Open 414 | Source Initiative. 415 |

416 |

417 | Software whose source code is publicly available is called “open source.” It is analogous to being able to open 418 | up the hood of a car and see what's inside, instead of having the engine sealed off from view. Open source 419 | licenses always include a provision that allows the public to use, modify, and redistribute the code. In this 420 | sense, there is no legal difference between free software and open source licenses. Indeed, some people have 421 | called open source a “marketing campaign” for free software. 422 |

423 |

424 | However, the most important distinction is the differing culture s that each movement created. The open source 425 | software movement broke away from the social and political associations with free software by instead focusing 426 | on the practical benefits of software development and encouraging wider creative and business applications. As 427 | Stallman himself wrote, Open source is a development methodology; free software is a social movement. 428 | [27] 429 |

430 |

431 | Although “free software” and “open source software” are often discussed together, they are politically 432 | distinct, the former being more closely associated with ethics and the latter with pragmatism. (The remainder 433 | of this paper will use the term “open source” to emphasize the critical role it plays in software 434 | infrastructure.) 435 |

436 |

437 | Open source created space for growing distinctions and styles of software development, free from ethical 438 | complexities. One organization might release its source code to the public, but only accept changes from a 439 | couple of contributors. Another organization might require that the code is developed in public and accept 440 | changes from anyone, so that more people could take part in the process. In 1997, Raymond wrote an influential 441 | essay called The Cathedral and the Bazaar (later published as a book in 1999) which explored these 442 | styles. 443 |

444 |

445 | Today, open source has become a popular software practice for many reasons, in terms of both efficiency and 446 | cost. It’s also how much of digital infrastructure gets built. We’ve discussed how making this software more 447 | freely available has benefitted all of society, but open source has benefits for its creators, as well. 448 |

449 |

450 | Open source is cheaper to build. 451 |

452 |

453 | Before open source software existed, technology firms treated software like any other paid product: a team of 454 | employees built new software internally, then sold it to the public. While this meant software had a clear 455 | business model, it also came with increased development costs. Proprietary software requires a full-time paid 456 | team to support its development, including developers, designers, marketers, and lawyers. It’s far cheaper to 457 | simply crowdsource software, built and maintained by a community of volunteer developers. 458 |

459 |

460 | Open source is easier to distribute. 461 |

462 |

463 | People are more likely to adopt software that is free to use and modify than software that cost s hundreds of 464 | dollars to license and was developed in a black box. Not only will developers want to use it for free, but they 465 | might be inclined to tell their friends to use it as well, amplifying the effects of its distribution. 466 |

467 |

468 | Open source is flexible to customize. 469 |

470 |

471 | Open source software is free to copy and modify for one’s own purposes, with various levels of permissiveness. 472 | This means that if a developer wants to make improvements to a piece of software, he or she can copy the 473 | project and change it. (This practice is called “forking.”) 474 |

475 |

476 | Many popular projects started as a modification of an existing piece of software, including 477 | WordPress (content management system that powers 23% of the world’s websites [28] ), PostgreSQL (one of the world’s most 479 | popular and fast-growing databases [29] ), 480 | Ubuntu (operating system used by 10% of the world’s websites [30] ), and Firefox (one of the most popular web browsers in the world 482 | [31] ). 483 |

484 |

485 | WordPress began as an offshoot of an existing blogging project, b2 (also known as cafelog). Two software 486 | developers, Matt Mullenweg and Mike Little, decided they wanted a better version of b2 and subsequently forked 487 | the project. Mullenweg decided to fork b2, rather than another project called TextPattern, because b2’s 488 | licenses were more permissive. His original thought process from 2003 is described below: 489 |

490 |
491 |

492 | What to do? Well, TextPattern looks like everything I could ever want, but it doesn’t look like it’s going to 493 | be licensed under something politically I could agree with. Fortunately, b2/cafelog is GPL [GNU General 494 | Public License, a free software license], which means that I could use the existing codebase to create a 495 | fork.[...] 496 |

497 |

498 | The work would never be lost, as if I fell of [sic] the face of the planet a year from now, whatever code I 499 | made would be free to the world, and if someone else wanted to pick it up they could.[32] 501 |

502 |
503 |

504 | If software were developed in a closed, proprietary environment, developers would have no ability to change 505 | that software, unless they worked at the company. If they tried to build their own improved version to imitate 506 | the original, they might face intellectual property concerns. With open source software, the developer can 507 | simply change the software him- or herself and release it to the public, as Mullenweg did. Open source 508 | software, then, enables rapid proliferation of ideas. 509 |

510 |

511 | Open source gives employees more bargaining power. 512 |

513 |

514 | Software takes time to learn, whether it’s a new programming language or framework. If every company used a 515 | proprietary set of tools, developers would be less inclined to change jobs, because their technical skills only 516 | apply to that one place of employment. They would have to be retrained in a new technology at their next place 517 | of employment. [33] 518 |

519 |

520 | When companies use open source technology, a developer has a reusable set of skills, which leads to more 521 | freedom to work wherever he or she prefers. For example, multiple companies might use the same Ruby programming 522 | language in their software. In addition, if the company’s product itself is open source, the output belongs to 523 | the developer as much as it does the company. The developer can take their work with them if they choose to 524 | leave the company (versus, for example, being constrained by a non-disclosure agreement, if the code were 525 | proprietary). All of these benefits give the employee more agency than he or she would have had with 526 | proprietary software. Many companies today advertise their use of open source software as a recruiting tactic, 527 | because it favors the developer. 528 |

529 |

530 | Open source has the potential to be more stable and secure. 531 |

532 |

533 | Theoretically, when a software project has many active contributors and a thriving community, the code should 534 | be less vulnerable to security flaws and disruptions in service. That’s because more people would ideally be 535 | reviewing the code, looking for bugs and fixing any problems that they see. By contrast, in a proprietary 536 | software environment, the only people who would see the code would be the team of people developing it. Instead 537 | of, say, 20 employees looking at the code at Oracle, a popular open source project could have 2,000 volunteers 538 | reviewing the code for vulnerabilities. (Note that this belief does not always match reality, and has created 539 | the opposite problem: people mistakenly believing that more people are reviewing open source software than 540 | actually are, when in reality nobody is taking responsibility. This will be discussed in a later section.) 541 |

542 |

543 | Open source software clearly has a number of benefits. How do these projects collectively fit into a broader 544 | ecosystem? 545 |

546 |
547 | 548 | 549 | -------------------------------------------------------------------------------- /src/EPUB/images/code-commits.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/willnorris/roads-and-bridges/dc154ffeabdd9ebd50d8a41f795586df4eb39915/src/EPUB/images/code-commits.png -------------------------------------------------------------------------------- /src/EPUB/images/cover.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/willnorris/roads-and-bridges/dc154ffeabdd9ebd50d8a41f795586df4eb39915/src/EPUB/images/cover.png -------------------------------------------------------------------------------- /src/EPUB/images/ford-foundation.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/willnorris/roads-and-bridges/dc154ffeabdd9ebd50d8a41f795586df4eb39915/src/EPUB/images/ford-foundation.png -------------------------------------------------------------------------------- /src/EPUB/images/git-subversion-jobs.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/willnorris/roads-and-bridges/dc154ffeabdd9ebd50d8a41f795586df4eb39915/src/EPUB/images/git-subversion-jobs.png -------------------------------------------------------------------------------- /src/EPUB/nav.xhtml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Roads and Bridges 7 | 8 | 9 | 10 | 11 | 12 |

13 | Table of Contents 14 |

15 | 117 | 118 | 119 | -------------------------------------------------------------------------------- /src/EPUB/opportunities.xhtml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Roads and Bridges 7 | 8 | 9 | 10 | 11 | 12 |

13 | Opportunities Ahead 14 |

15 |
16 |

17 | Developing effective support strategies 18 |

19 |

20 | Although there is growing interest in efforts to support digital infrastructure, current initiatives are still 21 | new, ad hoc or provide only partial support (such as fiscal sponsorship). 22 |

23 |

24 | Developing effective support strategies requires a nuanced understanding of the open source culture that 25 | characterizes so much of our digital infrastructure, as well as recognizing that much has changed in the past 26 | five years, including the very definition of “open source” itself. 27 |

28 |

29 | Money alone will not fix a struggling infrastructure project, because open source thrives on human rather than 30 | financial resources. There are many ways to grow human resources, such as distributing the workload among more 31 | contributors or encouraging companies to make open source part of their employees’ work. An effective support 32 | strategy must include multiple ways to generate time and resources besides directly financing development. It 33 | must start from the principle that the open source approach is not inherently flawed, but rather 34 | under-resourced. 35 |

36 |

37 | Supporting infrastructure requires embracing the concept of stewardship rather than control. As we’ve seen, 38 | digital infrastructure doesn’t look like physical infrastructure. It is distributed across multiple actors and 39 | organizations, with projects of many shapes and sizes, and it is hard to predict which projects will be 40 | successful or who will contribute to them in the long term. 41 |

42 |

43 | With this in mind, here are some suggested design principles for effective support strategies: 44 |

45 |
    46 |
  1. 47 |

    48 | Embrace, rather than fight against, decentralization. Open source is meant to be 49 | distributed; that’s part of what makes it so impactful. Leverage the community-driven approach as a 50 | strength rather than centralizing authority. 51 |

    52 |
    2. 53 |
  2. 54 |

    55 | Work closely with existing software communities. Software communities are active, 56 | tight-knit, and vocal. Treat them as an asset rather than making decisions behind closed doors. Prominent 57 | community voices are canaries in the coal mine when something needs attending to. 58 |

    59 |
    3. 60 |
  3. 61 |

    62 | Consider a holistic approach to project support. Projects need more than just code or 63 | money, and sometimes, they need neither. Long-term support is more about creating time than it is about 64 | money. Code reviews, technical documentation, code testing, community advocacy, and evangelism are all 65 | important resources. 66 |

    67 |
    4. 68 |
  4. 69 |

    70 | Help project maintainers plan ahead. Current efforts to support digital infrastructure 71 | tend to be reactive and ad hoc. In addition to existing projects, there may be new projects that need to be 72 | supported and built. For existing projects, maintainers will benefit greatly from being able to plan for 73 | the next three to five years, not just six months to a year. 74 |

    75 |
    5. 76 |
  5. 77 |

    78 | Recognize opportunities, not just risks. Modern open source support is not just about 79 | preventing worst-case scenarios (for example, security breaches), but rather empowering more people to 80 | build more things. This concept is a hallmark of today’s open source culture and also helps build a legacy 81 | of support. Consider how you can include more people from different backgrounds, skill sets, and abilities 82 | in your strategy, rather than limiting work to benefitting existing participants. 83 |

    84 |
    6. 85 |
86 |

87 | David Heinemeier Hansson, the creator of Ruby on Rails, compared open source to a coral reef: 88 |

89 |
90 |

91 | It's more sensitive than you think, and it's [hard] to underestimate the beauty that's unwittingly at stake. 92 | Please tread with care.[192] 93 |

94 |
95 |
96 |
97 |

98 | Priming the landscape 99 |

100 |

101 | It is too early to say what long-term institutional support should look like from a programmatic perspective, 102 | but there are several critical areas of work that would help us get there. 103 |

104 |

105 | The following suggestions fall into three areas: 106 |

107 | 126 |

127 | Building awareness and educating key stakeholders 128 |

129 |

130 | As discussed in this report, many key stakeholders—including those from startups, government, and venture 131 | capital—mistakenly believe that public software “just works” and does not require additional support. In order 132 | to adequately support our digital infrastructure ecosystem, these populations must first be made aware of the 133 | problem. Digital infrastructure needs advocates, unhampered by political or commercial constraints, who can 134 | understand and communicate the needs of digital infrastructure. 135 |

136 |

137 | Treating digital infrastructure as a necessary public good could also help direct investment into building 138 | better systems from scratch. For example, in the United States, the interstate highway system and the public 139 | library system were intentionally designed as public resources. Both had champions (President Dwight Eisenhower 140 | and philanthropist Andrew Carnegie, respectively), who built a case for the social and financial benefit that 141 | would result from these projects. A national highway system not only connected us as people, making it easier 142 | to get from place to place, but brought financial prosperity to all corners of the country, due to commercial 143 | use of highways to transport goods. Andrew Carnegie’s free public libraries used an “open stack” instead of a 144 | “closed stack” system, enabling people to browse and find information themselves, instead of requesting it from 145 | a librarian. This practice helped democratize information and empower people to educate themselves. 146 |

147 |

148 | Better education and awareness could also extend to governments, some of which have made digital infrastructure 149 | legally difficult to support, and who may not be as familiar with the cultural norms and history of open 150 | source. In the United States, the IRS has narrow definitions of what it considers to be charitable work, and 151 | because open source is not well understood, its positive impact on society goes unnoticed. This makes it 152 | difficult to institutionalize bigger projects under a foundation or trade association . 153 |

154 |

155 | Measuring the usage and impact of digital infrastructure 156 |

157 |

158 | The impact of digital infrastructure is still very difficult to measure. Usage metrics are either highly 159 | inaccurate or simply unavailable. This is not an easy problem to solve for. But without data about which tools 160 | are used, and how much we rely upon them, it is hard to paint a clear picture of what is underfunded. 161 |

162 |

163 | With better metrics, we could describe the economic impact of digital infrastructure, identify critical 164 | projects that are lacking support, and understand dependencies between projects and people. Right now, it is 165 | impossible to say who is using an open source project unless that person or company discloses their usage. Our 166 | information about which projects need better support is mostly anecdotal. 167 |

168 |

169 | Better metrics could also help us identify “keystone contributors” to open source. In conservation biology, a 170 | “keystone species” is a species of animal with a disproportionately large effect on its environment relative to 171 | its abundance. [193] Similarly, a “keystone 172 | contributor” might be a developer who contributes to multiple critical projects, is singlehandedly responsible 173 | for a critical project, or is generally perceived to be influential and trustworthy. Keystone contributors are 174 | critical advocates; empowering them with the resources they need could help improve the system as a whole. 175 | Understanding the relationship between open source communities and keystone contributors could help quickly 176 | identify areas that require further support. 177 |

178 |

179 | There is also little data about the contributors themselves: who contributes to open source, what conditions 180 | allow them to do so, and what types of contributions are made. Women, non-English speakers, and new 181 | contributors to open source are examples of demographics that should be tracked over time, especially to 182 | measure the impact of support programs. 183 |

184 |

185 | The only statistics available about GitHub repositories are the number of people who have starred (similar to a 186 | “like” or “favorite”), watched (meaning they receive updates about the project) or forked a project. These 187 | numbers help provide some metrics for relative popularity, but can also be misleading. Plenty of people could 188 | star a project, for example, because it is conceptually interesting, but not actually use it in their code. 189 |

190 |

191 | Some package managers like npm (which is used for Node.js) track downloads. Debian Popularity Contest tracks 192 | downloads of packages related to the free operating system Debian. Each package manager is limited to a 193 | particular ecosystem, however, and no one package manager can paint a picture of the system at large. Many 194 | projects are not part of a package manager and go untracked. Libraries.io, a website created by Andrew Nesbitt, 195 | is one effort to aggregate data open source projects and provide more data around their usage; it tracks over 196 | 1.3M open source libraries across 32 package managers. [194] 198 |

199 |

200 | Working with projects to modernize workflows 201 |

202 |

203 | Many projects struggle not just due to lack of funding, but because the projects are difficult to contribute 204 | to, or suffer a bottleneck from maintainers, who meticulously review and accept pull requests from the 205 | community. This is particularly true for older projects which may have been built using developer tools, 206 | languages, or workflows that are no longer popular (for example, using an older version control system instead 207 | of Git, whose popularity is growing among developers). 208 |

209 |

210 | There is plenty of work that can be done to make projects easier to contribute to, including migrating them to 211 | newer workflows, cleaning up code, closing unattended pull requests, and setting clear policies for 212 | contribution. 213 |

214 |

215 | Some projects have experimented with making it easier to contribute. For example, developer Felix Geisend ö 216 | rfer has suggested that everybody who submits a change to code should be given commit access, in order to 217 | reduce the bottleneck of a single maintainer reviewing and approving those changes. Felix found that this 218 | approach is a fantastic way to keep projects from going stale as well as turning one-man projects into small 219 | communities. [195] 220 |

221 |

222 | The Node.js contribution policy, which is made available for other Node projects to adopt, emphasizes growing 223 | the number of contributors and empowering them to make their own decisions, instead of treating maintainers as 224 | the final approving authority. Their contribution policy details how to submit and accept pull requests and how 225 | to log bugs and other issues. The Node.js maintainers found that adopting better policies helped them manage 226 | their workload and grow their community into a healthier, active project. [196] 228 |

229 |

230 | There is research to be done that addresses what projects should strive towards in the first place. That is, 231 | what does a “successful” project look like, in terms of financial support and governance models, as well as 232 | balancing the right mix of maintainers, contributors, and users? The answer may vary for different types or 233 | sizes of projects. 234 |

235 |

236 | Encouraging standards across open source projects 237 |

238 |

239 | Although GitHub is becoming a standard platform for code collaboration, many aspects of an open source project 240 | are still not standardized, including the breadth and depth of documentation, licenses, and contributing 241 | guides, as well as code style and formatting. Encouraging the adoption of project standards can make it easier 242 | for maintainers to manage contributions, as well as lowering a contributor’s barrier to participation. 243 |

244 |

245 | One example of a growing standard is a code of conduct, which is a policy detailing expectations for behavior 246 | and communication. Codes of conduct are being adopted among many project communities in recent years, including 247 | Node.js, Django, and Ruby. Although the process of adoption has been hotly debated among some communities, 248 | their proliferation suggests a rising interest in holding communities accountable for their behavior. 249 |

250 |

251 | Expanding the pool of open source contributors 252 |

253 |

254 | As discussed earlier in this report, software is a booming industry, with growing numbers of just new 255 | developers but other skilled talent, and there is work to be done to encourage newcomers to contribute to open 256 | source. Expanding the pool of contributors helps open source projects become more resilient, because more 257 | people are participating in their development. Helping more people contribute to open source also increases 258 | empathy and communication between open source “users” and the projects they depend on. 259 |

260 |

261 | Your First PR is an example of an initiative, developed by programmer Charlotte Spencer, that helps newcomers 262 | make their first contribution to open source. [197] First Timers Only [198] and Make a Pull Request [199] are two other popular examples of resources that introduce newcomers to open 266 | source. Some open source projects also use tags such as “first bug” or “contributor friendly” to flag issues 267 | that are suitable for less experienced contributors to tackle. It would also be valuable to encourage 268 | contributions to open source beyond code, such as writing technical documentation, managing tasks and 269 | workflows, or creating a website for a project. 270 |

271 |

272 | In addition to increasing the percentage of technical talent that contributes to open source, there is an 273 | opportunity to draw from a wider pool of contributors. Making non-English speakers feel welcomed in open source 274 | communities, for example, can help make technology more accessible around the world. And because many 275 | recruiters use open source work as a portfolio when hiring developers, a more diverse open source community can 276 | help build a more inclusive tech talent field overall. 277 |

278 |

279 | Improving relationships between projects and external stakeholders 280 |

281 |

282 | Companies are an inevitable part of the open source ecosystem, and their role is only increasing in importance 283 | as more companies embrace open source software. Making it easier for companies and projects to work with one 284 | another, as well as helping companies understand the needs of project communities, can unlock companies as 285 | patrons of, and advocates for, open source. 286 |

287 |

288 | According to the annual Black Duck open source company survey, only 27% of companies have a formal policy for 289 | employee contributions to open source. [200] 290 | Clarifying whether and how employees may contribute back to open source on company time, and encouraging them 291 | to do so, could go a long way in improving corporate support for open source projects. 292 |

293 |

294 | In 2014, a group of companies formed the TODO Group, to share best practices around corporate participation in 295 | open source. Members include Box, Facebook, Dropbox, Twitter, and Stripe. [201] In March 2016, the TODO Group announced it would be housed by the Linux 297 | Foundation as a collaborative project. [202] 298 |

299 |

300 | Companies can also provide financial support for projects, but sometimes find it difficult to figure out how to 301 | structure their sponsorship. Creating sponsorship budgets for engineering departments or employees, or creating 302 | documents to make it easy for projects to “invoice” companies, could increase financial contributions to open 303 | source. 304 |

305 |

306 | Poul-Henning Kamp, for example, works on an open source project called Varnish, used by one-tenth of the top 307 | websites on the Internet, including Facebook, Twitter, Tumblr, The New York Times, and The Guardian. 308 | [203] To fund his work, he created the Varnish 309 | Moral License to make it easy for companies to sponsor the project. Although in practice the relationship is a 310 | sponsorship, Poul-Henning uses terminology that companies are familiar with, such as “invoices” and “licenses,” 311 | to reduce barriers to participation. [204] 312 |

313 |

314 | Increasing support of diverse skill sets and non-coding functions 315 |

316 |

317 | In the not-too-distant past, software startups were once heavily weighted towards engineering talent. Other 318 | functions, like marketing or design, were considered secondary to code. 319 |

320 |

321 | With the rapid creation and consumerization of software today, that view no longer holds. Startups need to 322 | compete for their customers’ attention. Brand has become one of the most important differentiators. 323 |

324 |

325 | The last five years have seen the rise of the “full stack engineer”: developers who are more generalists than 326 | specialists, able to work on different layers of software complexity, and who might even have some proficiency 327 | with design or product. Software teams collaborate more closely, using agile software development approaches 328 | (where the product is built through frequent iteration between engineering, design, product, and marketing 329 | teams) rather than waterfall approaches (where each team completes their piece of the product before handing it 330 | to the next team). 331 |

332 |

333 | Open source software has seen very few of these changes, despite our increasing reliance on these projects. 334 | Understandably, code is central to an open source project, since in some ways it is the “product” or output. 335 | Less valued are functions such as community, documentation, or evangelism, that are the mark of any healthy, 336 | sustainable organization. As a result, projects become imbalanced. 337 |

338 |

339 | There is plenty of work that could be done to fund and support non-code contributions, in-kind donations (such 340 | as paying for servers), and benefits (such as health insurance). Having this type of support could go a long 341 | way in easing the burden on maintainers. 342 |

343 |
344 |
345 |

346 | The crossroads we face 347 |

348 |

349 | The current state of our digital infrastructure is one of the most poorly understood issues of our time. It is 350 | critical that we understand it. 351 |

352 |

353 | By making a voluntary investment in our underlying infrastructure, developers made it easier for others to 354 | build software. By giving it away for free instead of charging for it, they fueled an information revolution. 355 |

356 |

357 | Developers did not do this for altruistic reasons. They did it because it was the best way to solve their own 358 | problems. The story of open source software is one of the great modern day triumphs of the public good. 359 |

360 |

361 | We are lucky that developers have borne the hidden cost of these investments. But their initial investments 362 | only get us so far. 363 |

364 |

365 | We are merely at the beginning of the story of how software transformed humanity. Marc Andreessen, the 366 | co-founder of Netscape and well-known venture capitalist behind the firm Andreessen Horowitz, observed in 2011 367 | that software is eating the world. [205] Since then, that statement that has become canon for the modern age. 369 |

370 |

371 | Software affects everything we do: not just the frivolous and entertaining, but the mandatory and critical. 372 | OpenSSL, the project described at the beginning of this paper, demonstrates this well. In a phone interview, 373 | Steve Marquess explained that OpenSSL was used not just by consumer websites, but by the government, drones, 374 | satellites, any gadget you hear in the hospital beeping. [206] The Network Time Protocol, maintained by Harlan Stenn, synchronizes the clocks 376 | used by billions of networked devices and affects everything with a timestamp: not just messaging apps or 377 | email, but financial markets, medical records, and chemical processing. 378 |

379 |

380 | And yet, Harlan observes: 381 |

382 |
383 |

384 | There is a need for support for the free public infrastructure. But there's just no revenue stream around 385 | time right now. People scream if their clocks are off by a second. They say, Yes, we need you, but we 386 | can't give you any money. [207] 387 |

388 |
389 |

390 | In the last five years, open source infrastructure has become an essential layer of our social fabric. But much 391 | like startups or technology itself, what worked for the first 30 years of open source’s history won’t work 392 | moving forward. In order to maintain our pace of progress, we need to invest back into the tools that help us 393 | build bigger and better things. 394 |

395 |

396 | Figuring out how to support digital infrastructure may seem daunting, but there are plenty of reasons to see 397 | the road ahead as an opportunity. 398 |

399 |

400 | Firstly, the infrastructure is already there, with clearly demonstrated present value. This report does not 401 | propose to invest in an idea with unknown future value. The enormous social contributions of today’s digital 402 | infrastructure cannot be ignored or argued away, as has happened with other, equally important debates about 403 | data and privacy, net neutrality, or private versus public interests. This makes it easier to shift the 404 | conversation to solutions. 405 |

406 |

407 | Secondly, there are already engaged, thriving open source communities to work with. Many developers identify 408 | with the programming language they use (such as Python or JavaScript), the function they provide (such as data 409 | science or devops), or a prominent project (such as Node.js or Rails). These are strong, vocal, and 410 | enthusiastic communities. 411 |

412 |

413 | The builders of our digital infrastructure are connected to each other, aware of their needs, and technically 414 | talented. They already built our city; we just need to help keep the lights on so they can continue doing what 415 | they do best. 416 |

417 |

418 | Infrastructure, whether physical or digital, is not easy to understand, and its effects are not always visible, 419 | but this should compel us to look more, not less, closely. When a community has spoken so vocally and so often 420 | about its needs, all we need to do is listen. 421 |

422 |
423 | 424 | 425 | -------------------------------------------------------------------------------- /src/EPUB/package.opf: -------------------------------------------------------------------------------- 1 | 2 | 3 | e32029d1-cff0-49f5-b5ff-0326b93cd0b1 4 | en 5 | 6 | Roads and Bridges 7 | main 8 | 1 9 | 10 | The Unseen Labor Behind Our Digital Infrastructure 11 | subtitle 12 | 2 13 | 14 | Nadia Eghbal 15 | aut 16 | 17 | 2016-09-20T21:01:41Z 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | -------------------------------------------------------------------------------- /src/EPUB/preface.xhtml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Roads and Bridges 7 | 8 | 9 | 10 | 11 | 12 |

13 | Preface 14 |

15 |
16 |

17 | Foreword 18 |

19 |

20 | I stumbled upon the problem described in this report on a hunch. Having previously worked in startups, and then 21 | venture capital, I saw the enormous amounts of money being poured into software companies. But as an amateur 22 | software developer, I knew that I had never done any of it alone. I used free and publicly available code (also 23 | known as “open source” code), which I cobbled together and offered up for personal or commercial purposes. 24 | Really, the people behind those projects, whoever they were, had done most of the work. 25 |

26 |

27 | I mulled over this observation for several years, as I watched the explosion of coding “bootcamps” graduating 28 | new software developers left and right, and as I watched startups raise tens of millions of dollars selling 29 | products which I knew, under the hood, were probably more public than proprietary code. Having previously 30 | worked in the nonprofit sector, I immediately thought of public goods and their associated challenges, yet this 31 | vocabulary was strangely absent among my peers in software. 32 |

33 |

34 | After I left my job in venture capital last year, I set off to explore the paradox I couldn’t stop thinking 35 | about: that there were valuable software tools that couldn’t be supported by commercial models, and that they 36 | lacked any form of institutional support. 37 |

38 |

39 | Funnily enough, open source code wasn’t on my original list. I had mistakenly assumed, as had my peers, that 40 | these tools were an example of a particularly well-supported public good in software. When I brought up open 41 | source to friends and mentors, they gently dissuaded me from pursuing the topic, encouraging me instead to find 42 | other examples that actually needed the help. 43 |

44 |

45 | A few open source projects crossed my radar, however, and shattered those assumptions. It turned out that 46 | sustainability challenges were well-known among those who contributed to open source. The more I dug, the more 47 | I found blog posts, articles, and frequent public conversations about the stress and exhaustion felt by those 48 | who maintain open source projects. Everybody knew someone else I should talk to, and before I knew it, I had 49 | collected countless stories on this topic. 50 |

51 |

52 | I realized I had walked into a problem with which the producers (open source contributors) were extremely 53 | familiar, but that the consumers (software companies and other users of open source code) were seemingly 54 | unaware of. That discrepancy made me want to look more closely. 55 |

56 |

57 | In addition, it seemed that open source itself was changing, perhaps even bifurcating. I found myself having 58 | completely different conversations with different generations of open source contributors. They seemed to have 59 | divergent philosophies and values; they may as well not have been using the same terminology. I learned that 60 | open source had seen an explosion of production as well as demand in the past three to five years, thanks to 61 | improvements in developer tools and workflows. Today’s open source contributor looked very different from an 62 | open source contributor ten years ago, much less thirty years ago. And yet these different generations weren’t 63 | talking to each other, making productive conversations about sustainability difficult. 64 |

65 |

66 | A chance conversation with Ethan Zuckerman of the MIT Center for Civic Media gave me an opportunity to share 67 | these findings more widely. I described to Ethan the problem I was seeing, though I didn’t know exactly what it 68 | all meant or the vocabulary I should be using, and he kindly put me in touch with Jenny Toomey of the Ford 69 | Foundation. Jenny suggested I aggregate my findings into a report. In the process, a narrative around our 70 | modern digital society, and the hidden infrastructure that powers it, has emerged. 71 |

72 |

73 | This report would not have happened without Ethan and Jenny taking a chance on a half-baked idea that now, 74 | through the process of writing, has been shaped into something more. I am extremely grateful to both of them 75 | for their intuition. I am additionally grateful to Michael Brennan and Lori McGlinchey for their guidance, 76 | perspective and enthusiasm in the editing process. Finally, and perhaps most importantly, I am indebted to 77 | every person working in open source who made their stories public for people like me to read, and especially 78 | those who took a moment out of their busy schedules to humor me with a conversation or an email. This report is 79 | a collection of their wisdom, not mine. I am particularly grateful for early conversations with Russell 80 | Keith-Magee, Eric Holscher, Jan Lehnardt, Andrey Petrov, and Mikeal Rogers, all of whom continue to inspire me 81 | with their patience and dedication to open source work. Thank you for your kindness. 82 |

83 |
84 |
85 |

86 | Executive Summary 87 |

88 |

89 | Our modern society—everything from hospitals to stock markets to newspapers to social media—runs on software. 90 | But take a closer look, and you’ll find that the tools we use to build software are buckling under demand. 91 |

92 |

93 | Nearly all software today relies on free, public code (called “open source” code), written and maintained by 94 | communities of developers and other talent. Much like roads or bridges, which anyone can walk or drive on, open 95 | source code can be used by anyone—from companies to individuals—to build software. This type of code makes up 96 | the digital infrastructure of our society today. 97 |

98 |

99 | Just like physical infrastructure, digital infrastructure needs regular upkeep and maintenance. In the United 100 | States, over half of government spending on transportation and water infrastructure goes just to maintenance. 101 | [1] But financial support for digital 102 | infrastructure is much harder to come by. Currently, any financial support usually comes through sponsorships, 103 | direct or indirect, from software companies. 104 |

105 |

106 | Maintaining open source code used to be more manageable. Following the personal computer revolution of the 107 | early 1980s, most commercial software was proprietary, not shared. Software tools were built and used 108 | internally by companies, and their products were licensed to customers. Many companies felt that open source 109 | code was too nascent and unreliable for commercial use. In their view, software was meant to be charged for, 110 | not given away for free. 111 |

112 |

113 | Today, everybody uses open source code, including Fortune 500 companies, government, major software companies 114 | and startups. Sharing, rather than building proprietary code, turned out to be cheaper, easier, and more 115 | efficient. This increased demand puts additional strain on those who maintain this infrastructure, yet because 116 | these communities are not highly visible, the rest of the world has been slow to notice. Most of us take 117 | opening a software application for granted, the way we take turning on the lights for granted. We don’t think 118 | about the human capital necessary to make that happen. 119 |

120 |

121 | In the face of unprecedented demand, the costs of not supporting our digital infrastructure are numerous. On 122 | the risk side, there are security breaches and interruptions in service, due to infrastructure maintainers not 123 | being able to provide adequate support. On the opportunity side, we need to maintain and improve these software 124 | tools in order to support today’s startup renaissance, which relies heavily on this infrastructure. 125 | Additionally, open source work builds developers’ portfolios and helps them get hired, but the talent pool is 126 | remarkably less diverse than in tech overall. Expanding the pool of contributors can positively affect who 127 | participates in the tech industry at large. 128 |

129 |

130 | No individual company or organization is incentivized to address the problem alone, because open source code is 131 | a public good. In order to support our digital infrastructure, we must find ways to work together. Current 132 | examples of efforts to support digital infrastructure include the Linux Foundation’s Core Infrastructure 133 | Initiative and Mozilla’s Open Source Support (MOSS) program, as well as numerous software companies in various 134 | capacities. 135 |

136 |

137 | Sustaining our digital infrastructure is a new topic for many, and the challenges are not well understood. In 138 | addition, infrastructure projects are distributed across many people and organizations, defying common 139 | governance models. Many infrastructure projects have no legal entity at all. Any support strategy needs to 140 | accept and work with the decentralized, community-centric qualities of open source code. Increasing awareness 141 | of the problem, making it easier for institutions to contribute time and money, expanding the pool of open 142 | source contributors, and developing best practices and policies across infrastructure projects will all go a 143 | long way in building a healthy and sustainable ecosystem. 144 |

145 |
146 |
147 |

148 | Introduction 149 |

150 |

151 | In 1998, a group of security experts in the UK got together to build a free set of encryption tools for the 152 | Internet. 153 |

154 |

155 | Soon everybody was talking about their project, called OpenSSL. (The developers had used an existing Australian 156 | project, called SSLeay, as their blueprint.) Not only was it comprehensive and decently reliable, but it was 157 | free. Writing cryptography wasn’t easy, and OpenSSL had solved a major pain point for developers worldwide. 158 |

159 |

160 | By 2014, two-thirds of all Web servers were using OpenSSL, enabling websites to securely pass credit card and 161 | other sensitive information over the Internet.[2] 162 |

163 |

164 | Meanwhile, the project continued to be informally managed by a small handful of volunteers. A security 165 | consultant to the U.S. Department of Defense, Steve Marquess, noticed that one contributor, Stephen Henson, was 166 | working full time on OpenSSL. Curious, Marquess asked him what he did for income, and was shocked to learn that 167 | Henson made one-fifth of Marquess’s salary. 168 |

169 |

170 | Marquess had always considered himself to be a strong programmer, but his skills paled in comparison to 171 | Henson’s. Like others, Marquess had mistakenly assumed that someone as talented as Henson would have a 172 | comfortable salary to match. 173 |

174 |

175 | Henson had been working on OpenSSL since 1998. Marquess was newer to the project, joining in the early 2000s, 176 | and had worked with Henson for several years before learning of his income situation. 177 |

178 |

179 | Having worked with the Department of Defense, Marquess saw how critical OpenSSL was, not just to their 180 | software, but to other industries around the world, from enterprise to aeronautics to health care. Until that 181 | moment, he had always assumed, (as had the rest of the world) that the OpenSSL team was large, active, and 182 | well resourced.[3] In reality, OpenSSL wasn’t 183 | even able to support one person’s work. 184 |

185 |

186 | Marquess decided he wanted to help. Although he contributed code occasionally, he realized he could fill a more 187 | critical role on the business side. Marquess started out by arranging small consulting contracts through an 188 | existing nonprofit to help keep OpenSSL alive in its leanest years. 189 |

190 |

191 | As the volume of contracts grew, Marquess created the OpenSSL Software Foundation (OSF) to provide an official 192 | vehicle for revenue. Despite the number of individuals and companies relying on their software, OSF never 193 | received more than $2,000 in donations per year. Gross revenues (which came from consulting and contract work) 194 | never broke $1M, and much of that went toward security-related testing (which could cost hundreds of thousands 195 | of dollars) and server costs. 196 |

197 |

198 | There was enough to pay the salary of one developer, Stephen Henson. That meant that two-thirds of the Web 199 | relied on encryption software maintained by just one full-time employee. 200 |

201 |

202 | The OpenSSL team continued to work in relative obscurity until April 2014, when a Google engineer named Neel 203 | Mehta stumbled upon a major flaw in OpenSSL’s software. Two days later, another engineer at the Finnish company 204 | Codenomicon discovered the same problem. Both of them immediately contacted the OpenSSL team. 205 |

206 |

207 | That bug, nicknamed Heartbleed, had been included in a 2011 update. It had gone unnoticed for years. Heartbleed 208 | could allow any sophisticated hacker to capture secure information being passed to vulnerable web servers, 209 | including passwords, credit card information, and other sensitive data. 210 |

211 |

212 | Joseph Steinberg, a cybersecurity columnist for Forbes, wrote that some might 213 | argue that [Heartbleed] is the worst vulnerability found...since commercial traffic began to flow on the 214 | Internet.[4] 215 |

216 |

217 | Thanks to wide media reporting, much of the nontechnical world became familiar with the security bug, at least 218 | by name. Major services like Instagram, Gmail and Netflix were affected by Heartbleed.[5] Reporters also drew attention to OpenSSL itself, and how 220 | its team had struggled for years to support their work. OpenSSL was a known concern among security experts, but 221 | the team did not have adequate resources or attention to address the issues. 222 |

223 |

224 | Of Heartbleed, Marquess wrote, The mystery is not that a few overworked volunteers missed this bug; the 225 | mystery is why it hasn’t happened more often. 226 |

227 |

228 | People expressed their support by sending donations to the foundation. Although Marquess was grateful for their 229 | enthusiasm, the first round of donations came out to roughly $9,000: not nearly enough to sustain a team. 230 |

231 |

232 | Marquess took to the Internet to make an impassioned public plea for funding: 233 |

234 |
235 |

236 | These guys don’t work on OpenSSL for money. They don’t do it for fame (who outside of geek circles ever heard 237 | of them or OpenSSL until ‘heartbleed’ [sic] hit the news?). They do it out of pride in craftsmanship and the 238 | responsibility for something they believe in. 239 |

240 |

241 | It takes nerves of steel to work for many years on hundreds of thousands of lines of very complex code, with 242 | every line of code you touch visible to the world, knowing that code is used by banks, firewalls, weapons 243 | systems, web sites, smart phones, industry, government, everywhere. Knowing that you’ll be ignored and 244 | unappreciated until something goes wrong. 245 |

246 |

247 | There should be at least a half dozen full time OpenSSL team members, not just one, able to 248 | concentrate on the care and feeding of OpenSSL without having to hustle commercial work. If you’re a 249 | corporate or government decision maker in a position to do something about it, give it some thought. Please. 250 | I’m getting old and weary and I’d like to retire someday.[6] 252 |

253 |
254 |

255 | After Heartbleed, OpenSSL finally got more of the funding it needed—at least for now. They currently have 256 | enough money to pay four full-time employees for three years. But a year and a half into that funding, Marquess 257 | isn’t sure what will come next. 258 |

259 |

260 | Marquess said that Heartbleed was a boon for them, admitting it was a “little ironic” that publicity had helped 261 | elevate their cause. But after funding runs out and the world moves on, Marquess thinks they could be back in 262 | the same situation as pre-Heartbleed, and perhaps even worse: the client work that took Marquess years to build 263 | has dried up, since the team works full-time on OpenSSL right now and no longer has time for contracts. 264 | [7] 265 |

266 |

267 | Marquess himself is approaching retirement. He is the only person willing to handle the business and 268 | operational tasks associated with OpenSSL, including taxes, sourcing client work, and managing donors. The rest 269 | of his team prefers to focus on writing and maintaining code. He can’t hire someone else into his position when 270 | he retires, either, because he currently doesn’t take an income. Marquess remarked, I don't know that we can 271 | hold this together for more than a couple of years.[8] 273 |

274 |

275 | OpenSSL’s story is not unique, and in many ways, Marquess thinks they are the lucky ones. Countless other 276 | projects continue to go unheard of and unsupported. These projects make up the critical digital infrastructure 277 | that powers today’s software, and in turn, every aspect of our daily lives. 278 |

279 |

280 | Checking email, reading the news, checking stock prices, shopping online, going to the doctor, calling customer 281 | service—whether we realize it or not, everything we do is made possible by projects like OpenSSL. Without them, 282 | the technology that modern society relies upon simply could not function . 283 |

284 |

285 | Many of these projects are built and maintained by volunteers and offered to the public for free. Anyone, from 286 | Facebook to an amateur programmer, can use that code to build their own apps. And they do. 287 |

288 |

289 | If it sounds unbelievable that, as Marquess puts it, a ragtag group of amateurs could outcompete huge 290 | corporations with their money and resources,[9] consider how this work reflects the rise of peer-to-peer collaboration around the 292 | world. 293 |

294 |

295 | Unlikely startups like Uber or AirBnB exploded into major corporate powerhouses in just a few years, 296 | challenging longstanding industries like transportation and hospitality. Musicians make a name for themselves 297 | through YouTube or Soundcloud instead of big record labels. Creative people fund their ideas through 298 | crowdfunding platforms like Kickstarter or Patreon. 299 |

300 |

301 | Similarly, these infrastructure projects sprang from passionate, creative developers who thought I could do this better, collaborating to build and release code to the world. The difference is that 303 | millions of people rely on this code to lead functional daily lives. 304 |

305 |

306 | Because code is less charismatic than a hit YouTube video or Kickstarter campaign, there is little public 307 | awareness of and appreciation for this work. As a result, there is not nearly enough institutional support for 308 | the output that sparked an information revolution. But we can’t ignore it for much longer. 309 |

310 |

311 | In the past five years, our reliance on software, and the free and public code that supports it, has 312 | accelerated. Technology has worked its way into every aspect of our lives. And the more people use software, 313 | the more software gets built, and the more work is required to maintain it all. 314 |

315 |

316 | Every successful startup needs public infrastructure to succeed, yet no one company is motivated to act on its 317 | own. As the world blazes ahead into a modern age of startups, code and technology, infrastructure continues to 318 | lag behind. The cracks in the foundation are not obvious right now, but they are widening. After years of 319 | unprecedented growth that propelled us into a new era of wealth and prosperity, we must act now in order to 320 | ensure that the world we built in such a short period of time does not come unexpectedly crashing down. 321 |

322 |

323 | To understand how to protect our future, first we need to understand software itself. 324 |

325 |
326 | 327 | 328 | -------------------------------------------------------------------------------- /src/EPUB/style.css: -------------------------------------------------------------------------------- 1 | #cover { 2 | margin: 0; 3 | text-align: center; 4 | } 5 | #cover img { 6 | height: auto; 7 | width: auto; 8 | max-width: 100%; 9 | max-height: 99vh; 10 | } 11 | 12 | #copyright p { 13 | text-align: center; 14 | margin-bottom: 3em; 15 | } 16 | 17 | nav li { 18 | list-style: none; 19 | margin-bottom: 0.5em; 20 | } 21 | nav ol { 22 | margin: 0.5em 0 1em 0; 23 | padding-left: 1.5em; 24 | } 25 | nav a { 26 | color: #000; 27 | text-decoration: none; 28 | } 29 | nav > ol { 30 | padding: 0; 31 | } 32 | nav > ol > li > a { 33 | color: #F2645E; 34 | font-size: 1.25em; 35 | } 36 | nav > ol > li > ol { 37 | } 38 | 39 | body > section { 40 | page-break-before: always; 41 | break-before: always; 42 | } 43 | 44 | h2 { 45 | background: #F2645E; 46 | color: #FFF; 47 | display: inline-block; 48 | padding: 0.3em; 49 | } 50 | 51 | h3 { 52 | color: #F2645E; 53 | font-family: sans-serif; 54 | font-weight: normal; 55 | } 56 | 57 | figure { 58 | margin: 1em auto; 59 | text-align: center; 60 | } 61 | img { 62 | max-width: 100%; 63 | } 64 | 65 | /* Callouts */ 66 | .callout { 67 | background: #FEEAE2; 68 | padding: 1em 1em 1em 2em; 69 | font-style: italic; 70 | } 71 | .callout li { 72 | list-style: none; 73 | } 74 | 75 | /* Quotes */ 76 | q, blockquote { 77 | font-style: italic; 78 | quotes: "\201C""\201D""\2018""\2019"; 79 | } 80 | q:before { 81 | content: open-quote; 82 | } 83 | q:after { 84 | content: close-quote; 85 | } 86 | q.normal, q sup { 87 | font-style: normal; 88 | } 89 | blockquote { 90 | color: #F2645E; 91 | } 92 | blockquote:before { 93 | opacity: 0.1; 94 | content: "\201C"; 95 | font-size: 7em; 96 | line-height: 0em; 97 | float: left; 98 | position: relative; 99 | top: 0.25em; 100 | left: 0.15em; 101 | z-index: -1; 102 | margin-left: -1ex; 103 | } 104 | /* blog post titles are quoted instead of italicized */ 105 | cite.post { 106 | font-style: normal; 107 | } 108 | cite.post:before { 109 | content: open-quote; 110 | } 111 | cite.post:after { 112 | content: close-quote; 113 | } 114 | 115 | #glossary dt { 116 | float: left; 117 | clear: left; 118 | } 119 | #glossary dt dfn { 120 | font-style: normal; 121 | font-weight: bold; 122 | } 123 | #glossary dt dfn:after { 124 | content: ":\00a0"; 125 | } 126 | #glossary dd { 127 | margin: 0; 128 | } 129 | 130 | #sponsor { 131 | text-align: center; 132 | text-transform: uppercase; 133 | font-size: .8em; 134 | } 135 | #sponsor img { 136 | display: block; 137 | margin: 0 auto; 138 | width: 20em; 139 | height: auto; 140 | } 141 | -------------------------------------------------------------------------------- /src/EPUB/title.xhtml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | Roads and Bridges 7 | 8 | 9 | 10 | 11 | 12 |

13 | Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure 14 |

15 | 16 | 17 | -------------------------------------------------------------------------------- /src/META-INF/container.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /src/mimetype: -------------------------------------------------------------------------------- 1 | application/epub+zip --------------------------------------------------------------------------------