github.com/graybobo/golang.org-package-offline-cache@v0.0.0-20200626051047-6608995c132f/x/blog/content/open-source.article (about) 1 Go, Open Source, Community 2 08 Jul 2015 3 Tags: community 4 5 Russ Cox 6 7 * Welcome 8 9 [This is the text of my opening keynote at Gophercon 2015. 10 [[https://www.youtube.com/watch?v=XvZOdpd_9tc][The video is available here]].] 11 12 Thank you all for traveling to Denver to be here, 13 and thank you to everyone watching on video. 14 If this is your first Gophercon, welcome. 15 If you were here last year, welcome back. 16 Thank you to the organizers 17 for all the work it takes 18 to make a conference like this happen. 19 I am thrilled to be here and to be able to talk to all of you. 20 21 I am the tech lead for the Go project 22 and the Go team at Google. 23 I share that role with Rob Pike. 24 In that role, I spend a lot of time thinking about 25 the overall Go open source project, 26 in particular the way it runs, 27 what it means to be open source, 28 and the interaction between 29 contributors inside and outside Google. 30 Today I want to share with you 31 how I see the Go project as a whole 32 and then based on that explain 33 how I see the Go open source project 34 evolving. 35 36 * Why Go? 37 38 To get started, 39 we have to go back to the beginning. 40 Why did we start working on Go? 41 42 Go is an attempt to make programmers more productive. 43 We wanted to improve the software development process 44 at Google, 45 but the problems Google has 46 are not unique to Google. 47 48 There were two overarching goals. 49 50 The first goal is to make a better language 51 to meet the challenges of scalable concurrency. 52 By scalable concurrency I mean 53 software that deals with many concerns simultaneously, 54 such as coordinating a thousand back end servers 55 by sending network traffic back and forth. 56 57 Today, that kind of software has a shorter name: 58 we call it cloud software. 59 It's fair to say that Go was designed for the cloud 60 before clouds ran software. 61 62 The larger goal is to make a better environment 63 to meet the challenges of scalable software development, 64 software worked on and used by many people, 65 with limited coordination between them, 66 and maintained for years. 67 At Google we have thousands of engineers 68 writing and sharing their code with each other, 69 trying to get their work done, 70 reusing the work of others as much as possible, 71 and working in a code base with a history 72 dating back over ten years. 73 Engineers often work on or at least look at 74 code originally written by someone else, 75 or that they wrote years ago, 76 which often amounts to the same thing. 77 78 That situation inside Google 79 has a lot in common with 80 large scale, modern open source development 81 as practiced on sites like GitHub. 82 Because of this, 83 Go is a great fit for open source projects, 84 helping them accept and manage 85 contributions from a large community 86 over a long period of time. 87 88 I believe much of Go's success is explained by the fact that 89 Go is a great fit for cloud software, 90 Go is a great fit for open source projects, 91 and, serendipitously, both of those are 92 growing in popularity and importance 93 in the software industry. 94 95 Other people have made similar observations. 96 Here are two. 97 Last year, on RedMonk.com, Donnie Berkholz 98 wrote about 99 “[[http://redmonk.com/dberkholz/2014/03/18/go-the-emerging-language-of-cloud-infrastructure/][Go as the emerging language of cloud infrastructure]],” 100 observing that 101 “[Go's] marquee projects ... are cloud-centric or otherwise 102 made for dealing with distributed systems 103 or transient environments.” 104 105 This year, on Texlution.com, the author 106 wrote an article titled 107 “[[https://texlution.com/post/why-go-is-doomed-to-succeed/][Why Golang is doomed to succeed]],” 108 pointing out that this focus on large-scale development 109 was possibly even better suited to open source than 110 to Google itself: “This open source fitness is why I think 111 you are about to see more and more Go around ...” 112 113 * The Go Balance 114 115 How does Go accomplish those things? 116 117 How does it make scalable concurrency 118 and scalable software development easier? 119 120 Most people answer this question by talking about 121 channels and goroutines, and interfaces, and fast builds, 122 and the go command, and good tool support. 123 Those are all important parts of the answer, 124 but I think there is a broader idea behind them. 125 126 I think of that idea as Go's balance. 127 There are competing concerns in any software design, 128 and there is a very natural tendency to try to solve 129 all the problems you foresee. 130 In Go, we have explicitly tried not to solve everything. 131 Instead, we've tried to do just enough that you can build 132 your own custom solutions easily. 133 134 The way I would summarize Go's chosen balance is this: *Do*Less.*Enable*More.* 135 136 Do less, but enable more. 137 138 Go can't do everything. 139 We shouldn't try. 140 But if we work at it, 141 Go can probably do 142 a few things well. 143 If we select those things carefully, 144 we can lay a foundation 145 on which developers can _easily_ build 146 the solutions and tools they need, 147 and ideally can interoperate with 148 the solutions and tools built by others. 149 150 ** Examples 151 152 Let me illustrate this with some examples. 153 154 First, the size of the Go language itself. 155 We worked hard to put in as few concepts as possible, 156 to avoid the problem of mutually incomprehensible dialects 157 forming in different parts of a large developer community. 158 No idea went into Go until 159 it had been simplified to its essence 160 and then had clear benefits 161 that justified the complexity being added. 162 163 In general, if we have 100 things 164 we want Go to do well, 165 we can't make 100 separate changes. 166 Instead, we try to research and understand 167 the design space 168 and then identify a few changes 169 that work well together 170 and that enable maybe 90 of those things. 171 We're willing to sacrifice the remaining 10 172 to avoid bloating the language, 173 to avoid adding complexity 174 only to address specific use cases 175 that seem important today 176 but might be gone tomorrow. 177 178 Keeping the language small 179 enables more important goals. 180 Being small makes Go 181 easier to learn, 182 easier to understand, 183 easier to implement, 184 easier to reimplement, 185 easier to debug, 186 easier to adjust, 187 and easier to evolve. 188 Doing less enables more. 189 190 I should point out that 191 this means we say no 192 to a lot of other people's ideas, 193 but I assure you 194 we've said no 195 to even more of our own ideas. 196 197 Next, channels and goroutines. 198 How should we structure and coordinate 199 concurrent and parallel computations? 200 Mutexes and condition variables are very general 201 but so low-level that they're difficult to use correctly. 202 Parallel execution frameworks like OpenMP are so high-level 203 that they can only be used to solve a narrow range of problems. 204 Channels and goroutines sit between these two extremes. 205 By themselves, they aren't a solution to much. 206 But they are powerful enough to be easily arranged 207 to enable solutions to many common problems 208 in concurrent software. 209 Doing less—really doing just enough—enables more. 210 211 Next, types and interfaces. 212 Having static types enables useful compile-time checking, 213 something lacking in dynamically-typed languages 214 like Python or Ruby. 215 At the same time, 216 Go's static typing avoids 217 much of the repetition 218 of traditional statically typed languages, 219 making it feel more lightweight, 220 more like the dynamically-typed languages. 221 This was one of the first things people noticed, 222 and many of Go's early adopters came from 223 dynamically-typed languages. 224 225 Go's interfaces are a key part of that. 226 In particular, 227 omitting the ``implements'' declarations 228 of Java or other languages with static hierarchy 229 makes interfaces lighter weight and more flexible. 230 Not having that rigid hierarchy 231 enables idioms such as test interfaces that describe 232 existing, unrelated production implementations. 233 Doing less enables more. 234 235 Next, testing and benchmarking. 236 Is there any shortage of testing 237 and benchmarking frameworks in most languages? 238 Is there any agreement between them? 239 240 Go's testing package is not meant 241 to address every possible facet of these topics. 242 Instead, it is meant to provide 243 the basic concepts necessary 244 for most higher-level tooling. 245 Packages have test cases that pass, fail, or are skipped. 246 Packages have benchmarks that run and can be measured 247 by various metrics. 248 249 Doing less here is an attempt 250 to reduce these concepts to their essence, 251 to create a shared vocabulary 252 so that richer tools can interoperate. 253 That agreement enables higher-level testing software 254 like Miki Tebeka's go2xunit converter, 255 or the benchcmp and benchstat 256 benchmark analysis tools. 257 258 Because there _is_ agreement 259 about the representation of the basic concepts, 260 these higher-level tools work for all Go packages, 261 not just ones that make the effort to opt in, 262 and they interoperate with each other, 263 in that using, say, go2xunit 264 does not preclude also using benchstat, 265 the way it would if these tools were, say, 266 plugins for competing testing frameworks. 267 Doing less enables more. 268 269 Next, refactoring and program analysis. 270 Because Go is for large code bases, 271 we knew it would need to support automatic 272 maintenance and updating of source code. 273 We also knew that this topic was too large 274 to build in directly. 275 But we knew one thing that we had to do. 276 In our experience attempting 277 automated program changes in other settings, 278 the most significant barrier we hit 279 was actually writing the modified program out 280 in a format that developers can accept. 281 282 In other languages, 283 it's common for different teams to use 284 different formatting conventions. 285 If an edit by a program uses the wrong convention, 286 it either writes a section of the source file that looks nothing 287 like the rest of the file, or it reformats the entire file, 288 causing unnecessary and unwanted diffs. 289 290 Go does not have this problem. 291 We designed the language to make gofmt possible, 292 we worked hard 293 to make gofmt's formatting acceptable 294 for all Go programs, 295 and we made sure gofmt was there 296 from day one of the original public release. 297 Gofmt imposes such uniformity that 298 automated changes blend into the rest of the file. 299 You can't tell whether a particular change 300 was made by a person or a computer. 301 We didn't build explicit refactoring support. 302 Establishing an agreed-upon formatting algorithm 303 was enough of a shared base 304 for independent tools to develop and to interoperate. 305 Gofmt enabled gofix, goimports, eg, and other tools. 306 I believe the work here is only just getting started. 307 Even more can be done. 308 309 Last, building and sharing software. 310 In the run up to Go 1, we built goinstall, 311 which became what we all know as "go get". 312 That tool defined a standard zero-configuration way 313 to resolve import paths on sites like github.com, 314 and later a way to resolve paths on other sites 315 by making HTTP requests. 316 This agreed-upon resolution algorithm 317 enabled other tools that work in terms of those paths, 318 most notably Gary Burd's creation of godoc.org. 319 In case you haven't used it, 320 you go to godoc.org/the-import-path 321 for any valid "go get" import path, 322 and the web site will fetch the code 323 and show you the documentation for it. 324 A nice side effect of this has been that 325 godoc.org serves as a rough master list 326 of the Go packages publicly available. 327 All we did was give import paths a clear meaning. 328 Do less, enable more. 329 330 You'll notice that many of these tooling examples 331 are about establishing a shared convention. 332 Sometimes people refer to this as Go being “opinionated,” 333 but there's something deeper going on. 334 Agreeing to the limitations 335 of a shared convention 336 is a way to enable 337 a broad class of tools that interoperate, 338 because they all speak the same base language. 339 This is a very effective way 340 to do less but enable more. 341 Specifically, in many cases 342 we can do the minimum required 343 to establish a shared understanding 344 of a particular concept, like remote imports, 345 or the proper formatting of a source file, 346 and thereby enable 347 the creation of packages and tools 348 that work together 349 because they all agree 350 about those core details. 351 352 I'm going to return to that idea later. 353 354 * Why is Go open source? 355 356 But first, as I said earlier, 357 I want to explain how I see 358 the balance of Do Less and Enable More 359 guiding our work 360 on the broader 361 Go open source project. 362 To do that, I need to start with 363 why Go is open source at all. 364 365 Google pays me and others to work on Go, because, 366 if Google's programmers are more productive, 367 Google can build products faster, 368 maintain them more easily, 369 and so on. 370 But why open source Go? 371 Why should Google share this benefit with the world? 372 373 Of course, many of us 374 worked on open source projects before Go, 375 and we naturally wanted Go 376 to be part of that open source world. 377 But our preferences are not a business justification. 378 The business justification is that 379 Go is open source 380 because that's the only way 381 that Go can succeed. 382 We, the team that built Go within Google, 383 knew this from day one. 384 We knew that Go had to be made available 385 to as many people as possible 386 for it to succeed. 387 388 Closed languages die. 389 390 A language needs large, broad communities. 391 392 A language needs lots of people writing lots of software, 393 so that when you need a particular tool or library, 394 there's a good chance it has already been written, 395 by someone who knows the topic better than you, 396 and who spent more time than you have to make it great. 397 398 A language needs lots of people reporting bugs, 399 so that problems are identified and fixed quickly. 400 Because of the much larger user base, 401 the Go compilers are much more robust and spec-compliant 402 than the Plan 9 C compilers they're loosely based on ever were. 403 404 A language needs lots of people using it 405 for lots of different purposes, 406 so that the language doesn't overfit to one use case 407 and end up useless when the technology landscape changes. 408 409 A language needs lots of people who want to learn it, 410 so that there is a market for people to write books 411 or teach courses, 412 or run conferences like this one. 413 414 None of this could have happened 415 if Go had stayed within Google. 416 Go would have suffocated inside Google, 417 or inside any single company 418 or closed environment. 419 420 Fundamentally, 421 Go must be open, 422 and Go needs you. 423 Go can't succeed without all of you, 424 without all the people using Go 425 for all different kinds of projects 426 all over the world. 427 428 In turn, the Go team at Google 429 could never be large enough 430 to support the entire Go community. 431 To keep scaling, 432 we 433 need to enable all this ``more'' 434 while doing less. 435 Open source is a huge part of that. 436 437 * Go's open source 438 439 What does open source mean? 440 The minimum requirement is to open the source code, 441 making it available under an open source license, 442 and we've done that. 443 444 But we also opened our development process: 445 since announcing Go, 446 we've done all our development in public, 447 on public mailing lists open to all. 448 We accept and review 449 source code contributions from anyone. 450 The process is the same 451 whether you work for Google or not. 452 We maintain our bug tracker in public, 453 we discuss and develop proposals for changes in public, 454 and we work toward releases in public. 455 The public source tree is the authoritative copy. 456 Changes happen there first. 457 They are only brought into 458 Google's internal source tree later. 459 For Go, being open source means 460 that this is a collective effort 461 that extends beyond Google, open to all. 462 463 Any open source project starts with a few people, 464 often just one, but with Go it was three: 465 Robert Griesemer, Rob Pike, and Ken Thompson. 466 They had a vision of 467 what they wanted Go to be, 468 what they thought Go could do better 469 than existing languages, and 470 Robert will talk more about that tomorrow morning. 471 I was the next person to join the team, 472 and then Ian Taylor, 473 and then, one by one, 474 we've ended up where we are today, 475 with hundreds of contributors. 476 477 Thank You 478 to the many people who have contributed 479 code 480 or ideas 481 or bug reports 482 to the Go project so far. 483 We tried to list everyone we could 484 in our space in the program today. 485 If your name is not there, 486 I apologize, 487 but thank you. 488 489 I believe 490 the hundreds of contributors so far 491 are working toward a shared vision 492 of what Go can be. 493 It's hard to put words to these things, 494 but I did my best 495 to explain one part of the vision 496 earlier: 497 Do Less, Enable More. 498 499 * Google's role 500 501 A natural question is: 502 What is the role 503 of the Go team at Google, 504 compared to other contributors? 505 I believe that role 506 has changed over time, 507 and it continues to change. 508 The general trend is that 509 over time 510 the Go team at Google 511 should be doing less 512 and enabling more. 513 514 In the very early days, 515 before Go was known to the public, 516 the Go team at Google 517 was obviously working by itself. 518 We wrote the first draft of everything: 519 the specification, 520 the compiler, 521 the runtime, 522 the standard library. 523 524 Once Go was open sourced, though, 525 our role began to change. 526 The most important thing 527 we needed to do 528 was communicate our vision for Go. 529 That's difficult, 530 and we're still working at it.. 531 The initial implementation 532 was an important way 533 to communicate that vision, 534 as was the development work we led 535 that resulted in Go 1, 536 and the various blog posts, 537 and articles, 538 and talks we've published. 539 540 But as Rob said at Gophercon last year, 541 "the language is done." 542 Now we need to see how it works, 543 to see how people use it, 544 to see what people build. 545 The focus now is on 546 expanding the kind of work 547 that Go can help with. 548 549 Google's primarily role is now 550 to enable the community, 551 to coordinate, 552 to make sure changes work well together, 553 and to keep Go true to the original vision. 554 555 Google's primary role is: 556 Do Less. Enable More. 557 558 I mentioned earlier 559 that we'd rather have a small number of features 560 that enable, say, 90% of the target use cases, 561 and avoid the orders of magnitude 562 more features necessary 563 to reach 99 or 100%. 564 We've been successful in applying that strategy 565 to the areas of software that we know well. 566 But if Go is to become useful in many new domains, 567 we need experts in those areas 568 to bring their expertise 569 to our discussions, 570 so that together 571 we can design small adjustments 572 that enable many new applications for Go. 573 574 This shift applies not just to design 575 but also to development. 576 The role of the Go team at Google 577 continues to shift 578 more to one of guidance 579 and less of pure development. 580 I certainly spend much more time 581 doing code reviews than writing code, 582 more time processing bug reports 583 than filing bug reports myself. 584 We need to do less and enable more. 585 586 As design and development shift 587 to the broader Go community, 588 one of the most important things 589 we 590 the original authors of Go 591 can offer 592 is consistency of vision, 593 to help keep Go 594 Go. 595 The balance that we must strike 596 is certainly subjective. 597 For example, a mechanism for extensible syntax 598 would be a way to 599 enable more 600 ways to write Go code, 601 but that would run counter to our goal 602 of having a consistent language 603 without different dialects. 604 605 We have to say no sometimes, 606 perhaps more than in other language communities, 607 but when we do, 608 we aim to do so 609 constructively and respectfully, 610 to take that as an opportunity 611 to clarify the vision for Go. 612 613 Of course, it's not all coordination and vision. 614 Google still funds Go development work. 615 Rick Hudson is going to talk later today 616 about his work on reducing garbage collector latency, 617 and Hana Kim is going to talk tomorrow 618 about her work on bringing Go to mobile devices. 619 But I want to make clear that, 620 as much as possible, 621 we aim to treat 622 development funded by Google 623 as equal to 624 development funded by other companies 625 or contributed by individuals using their spare time. 626 We do this because we don't know 627 where the next great idea will come from. 628 Everyone contributing to Go 629 should have the opportunity to be heard. 630 631 ** Examples 632 633 I want to share some evidence for this claim 634 that, over time, 635 the original Go team at Google 636 is focusing more on 637 coordination than direct development. 638 639 First, the sources of funding 640 for Go development are expanding. 641 Before the open source release, 642 obviously Google paid for all Go development. 643 After the open source release, 644 many individuals started contributing their time, 645 and we've slowly but steadily 646 been growing the number of contributors 647 supported by other companies 648 to work on Go at least part-time, 649 especially as it relates to 650 making Go more useful for those companies. 651 Today, that list includes 652 Canonical, Dropbox, Intel, Oracle, and others. 653 And of course Gophercon and the other 654 regional Go conferences are organized 655 entirely by people outside Google, 656 and they have many corporate sponsors 657 besides Google. 658 659 Second, the conceptual depth 660 of Go development 661 done outside the original team 662 is expanding. 663 664 Immediately after the open source release, 665 one of the first large contributions 666 was the port to Microsoft Windows, 667 started by Hector Chu 668 and completed by Alex Brainman and others. 669 More contributors ported Go 670 to other operating systems. 671 Even more contributors 672 rewrote most of our numeric code 673 to be faster or more precise or both. 674 These were all important contributions, 675 and very much appreciated, 676 but 677 for the most part 678 they did not involve new designs. 679 680 More recently, 681 a group of contributors led by Aram Hăvărneanu 682 ported Go to the ARM 64 architecture, 683 This was the first architecture port 684 by contributors outside Google. 685 This is significant, because 686 in general 687 support for a new architecture 688 requires more design work 689 than support for a new operating system. 690 There is more variation between architectures 691 than between operating systems. 692 693 Another example is the introduction 694 over the past few releases 695 of preliminary support 696 for building Go programs using shared libraries. 697 This feature is important for many Linux distributions 698 but not as important for Google, 699 because we deploy static binaries. 700 We have been helping guide the overall strategy, 701 but most of the design 702 and nearly all of the implementation 703 has been done by contributors outside Google, 704 especially Michael Hudson-Doyle. 705 706 My last example is the go command's 707 approach to vendoring. 708 I define vendoring as 709 copying source code for external dependencies 710 into your tree 711 to make sure that they doesn't disappear 712 or change underfoot. 713 714 Vendoring is not a problem Google suffers, 715 at least not the way the rest of the world does. 716 We copy open source libraries we want to use 717 into our shared source tree, 718 record what version we copied, 719 and only update the copy 720 when there is a need to do so. 721 We have a rule 722 that there can only be one version 723 of a particular library in the source tree, 724 and it's the job of whoever wants to upgrade that library 725 to make sure it keeps working as expected 726 by the Google code that depends on it. 727 None of this happens often. 728 This is the lazy approach to vendoring. 729 730 In contrast, most projects outside Google 731 take a more eager approach, 732 importing and updating code 733 using automated tools 734 and making sure that they are 735 always using the latest versions. 736 737 Because Google has relatively little experience 738 with this vendoring problem, 739 we left it to users outside Google to develop solutions. 740 Over the past five years, 741 people have built a series of tools. 742 The main ones in use today are 743 Keith Rarick's godep, 744 Owen Ou's nut, 745 and the gb-vendor plugin for Dave Cheney's gb, 746 747 There are two problems with the current situation. 748 The first is that these tools 749 are not compatible 750 out of the box 751 with the go command's "go get". 752 The second is that the tools 753 are not even compatible with each other. 754 Both of these problems 755 fragment the developer community by tool. 756 757 Last fall, we started a public design discussion 758 to try to build consensus on 759 some basics about 760 how these tools all operate, 761 so that they can work alongside "go get" 762 and each other. 763 764 Our basic proposal was that all tools agree 765 on the approach of rewriting import paths during vendoring, 766 to fit with "go get"'s model, 767 and also that all tools agree on a file format 768 describing the source and version of the copied code, 769 so that the different vendoring tools 770 can be used together 771 even by a single project. 772 If you use one today, 773 you should still be able to use another tomorrow. 774 775 Finding common ground in this way 776 was very much in the spirit of Do Less, Enable More. 777 If we could build consensus 778 about these basic semantic aspects, 779 that would enable "go get" and all these tools to interoperate, 780 and it would enable switching between tools, 781 the same way that 782 agreement about how Go programs 783 are stored in text files 784 enables the Go compiler and all text editors to interoperate. 785 So we sent out our proposal for common ground. 786 787 Two things happened. 788 789 First, Daniel Theophanes 790 started a vendor-spec project on GitHub 791 with a new proposal 792 and took over coordination and design 793 of the spec for vendoring metadata. 794 795 Second, the community spoke 796 with essentially one voice 797 to say that 798 rewriting import paths during vendoring 799 was not tenable. 800 Vendoring works much more smoothly 801 if code can be copied without changes. 802 803 Keith Rarick posted an alternate proposal 804 for a minimal change to the go command 805 to support vendoring without rewriting import paths. 806 Keith's proposal was configuration-free 807 and fit in well with the rest of the go command's approach. 808 That proposal will ship 809 as an experimental feature in Go 1.5 810 and likely enabled by default in Go 1.6. 811 And I believe that the various vendoring tool authors 812 have agreed to adopt Daniel's spec once it is finalized. 813 814 The result 815 is that at the next Gophercon 816 we should have broad interoperability 817 between vendoring tools and the go command, 818 and the design to make that happen 819 was done entirely by contributors 820 outside the original Go team. 821 822 Not only that, 823 the Go team's proposal for how to do this 824 was essentially completely wrong. 825 The Go community told us that 826 very clearly. 827 We took that advice, 828 and now there's a plan for vendoring support 829 that I believe 830 everyone involved is happy with. 831 832 This is also a good example 833 of our general approach to design. 834 We try not to make any changes to Go 835 until we feel there is broad consensus 836 on a well-understood solution. 837 For vendoring, 838 feedback and design 839 from the Go community 840 was critical to reaching that point. 841 842 This general trend 843 toward both code and design 844 coming from the broader Go community 845 is important for Go. 846 You, the broader Go community, 847 know what is working 848 and what is not 849 in the environments where you use Go. 850 We at Google don't. 851 More and more, 852 we will rely on your expertise, 853 and we will try to help you develop 854 designs and code 855 that extend Go to be useful in more settings 856 and fit well with Go's original vision. 857 At the same time, 858 we will continue to wait 859 for broad consensus 860 on well-understood solutions. 861 862 This brings me to my last point. 863 864 * Code of Conduct 865 866 I've argued that Go must be open, 867 and that Go needs your help. 868 869 But in fact Go needs everyone's help. 870 And everyone isn't here. 871 872 Go needs ideas from as many people as possible. 873 874 To make that a reality, 875 the Go community needs to be 876 as inclusive, 877 welcoming, 878 helpful, 879 and respectful as possible. 880 881 The Go community is large enough now that, 882 instead of assuming that everyone involved 883 knows what is expected, 884 I and others believe that it makes sense 885 to write down those expectations explicitly. 886 Much like the Go spec 887 sets expectations for all Go compilers, 888 we can write a spec 889 setting expectations for our behavior 890 in online discussions 891 and in offline meetings like this one. 892 893 Like any good spec, 894 it must be general enough 895 to allow many implementations 896 but specific enough 897 that it can identify important problems. 898 When our behavior doesn't meet the spec, 899 people can point that out to us, 900 and we can fix the problem. 901 At the same time, 902 it's important to understand that 903 this kind of spec 904 cannot be as precise as a language spec. 905 We must start with the assumption 906 that we will all be reasonable in applying it. 907 908 This kind of spec 909 is often referred to as 910 a Code of Conduct. 911 Gophercon has one, 912 which we've all agreed to follow 913 by being here, 914 but the Go community does not. 915 I and others 916 believe the Go community 917 needs a Code of Conduct. 918 919 But what should it say? 920 921 I believe 922 the most important 923 overall statement we can make 924 is that 925 if you want to use or discuss Go, 926 then you are welcome here, 927 in our community. 928 That is the standard 929 I believe we aspire to. 930 931 If for no other reason 932 (and, to be clear, there are excellent other reasons), 933 Go needs as large a community as possible. 934 To the extent that behavior 935 limits the size of the community, 936 it holds Go back. 937 And behavior can easily 938 limit the size of the community. 939 940 The tech community in general 941 and the Go community in particular 942 is skewed toward people who communicate bluntly. 943 I don't believe this is fundamental. 944 I don't believe this is necessary. 945 But it's especially easy to do 946 in online discussions like email and IRC, 947 where plain text is not supplemented 948 by the other cues and signals we have 949 in face-to-face interactions. 950 951 For example, I have learned 952 that when I am pressed for time 953 I tend to write fewer words, 954 with the end result that 955 my emails seem not just hurried 956 but blunt, impatient, even dismissive. 957 That's not how I feel, 958 but it's how I can come across, 959 and that impression can be enough 960 to make people think twice 961 about using or contributing 962 to Go. 963 I realized I was doing this 964 when some Go contributors 965 sent me private email to let me know. 966 Now, when I am pressed for time, 967 I pay extra attention to what I'm writing, 968 and I often write more than I naturally would, 969 to make sure 970 I'm sending the message I intend. 971 972 I believe 973 that correcting the parts 974 of our everyday interactions, 975 intended or not, 976 that drive away potential users and contributors 977 is one of the most important things 978 we can all do 979 to make sure the Go community 980 continues to grow. 981 A good Code of Conduct can help us do that. 982 983 We have no experience writing a Code of Conduct, 984 so we have been reading existing ones, 985 and we will probably adopt an existing one, 986 perhaps with minor adjustments. 987 The one I like the most is the Django Code of Conduct, 988 which originated with another project called SpeakUp! 989 It is structured as an elaboration of a list of 990 reminders for everyday interaction. 991 992 "Be friendly and patient. 993 Be welcoming. 994 Be considerate. 995 Be respectful. 996 Be careful in the words that you choose. 997 When we disagree, try to understand why." 998 999 I believe this captures the tone we want to set, 1000 the message we want to send, 1001 the environment we want to create 1002 for new contributors. 1003 I certainly want to be 1004 friendly, 1005 patient, 1006 welcoming, 1007 considerate, 1008 and respectful. 1009 I won't get it exactly right all the time, 1010 and I would welcome a helpful note 1011 if I'm not living up to that. 1012 I believe most of us 1013 feel the same way. 1014 1015 I haven't mentioned 1016 active exclusion based on 1017 or disproportionately affecting 1018 race, gender, disability, 1019 or other personal characteristics, 1020 and I haven't mentioned harassment. 1021 For me, 1022 it follows from what I just said 1023 that exclusionary behavior 1024 or explicit harassment 1025 is absolutely unacceptable, 1026 online and offline. 1027 Every Code of Conduct says this explicitly, 1028 and I expect that ours will too. 1029 But I believe the SpeakUp! reminders 1030 about everyday interactions 1031 are an equally important statement. 1032 I believe that 1033 setting a high standard 1034 for those everyday interactions 1035 makes extreme behavior 1036 that much clearer 1037 and easier to deal with. 1038 1039 I have no doubts that 1040 the Go community can be 1041 one of the most 1042 friendly, 1043 welcoming, 1044 considerate, 1045 and 1046 respectful communities 1047 in the tech industry. 1048 We can make that happen, 1049 and it will be 1050 a benefit and credit to us all. 1051 1052 Andrew Gerrand 1053 has been leading the effort 1054 to adopt an appropriate Code of Conduct 1055 for the Go community. 1056 If you have suggestions, 1057 or concerns, 1058 or experience with Codes of Conduct, 1059 or want to be involved, 1060 please find Andrew or me 1061 during the conference. 1062 If you'll still be here on Friday, 1063 Andrew and I are going to block off 1064 some time for Code of Conduct discussions 1065 during Hack Day. 1066 1067 Again, we don't know 1068 where the next great idea will come from. 1069 We need all the help we can get. 1070 We need a large, diverse Go community. 1071 1072 * Thank You 1073 1074 I consider the many people 1075 releasing software for download using “go get,” 1076 sharing their insights via blog posts, 1077 or helping others on the mailing lists or IRC 1078 to be part of this broad open source effort, 1079 part of the Go community. 1080 Everyone here today is also part of that community. 1081 1082 Thank you in advance 1083 to the presenters 1084 who over the next few days 1085 will take time to share their experiences 1086 using and extending Go. 1087 1088 Thank you in advance 1089 to all of you in the audience 1090 for taking the time to be here, 1091 to ask questions, 1092 and to let us know 1093 how Go is working for you. 1094 When you go back home, 1095 please continue to share what you've learned. 1096 Even if you don't use Go 1097 for daily work, 1098 we'd love to see what's working for Go 1099 adopted in other contexts, 1100 just as we're always looking for good ideas 1101 to bring back into Go. 1102 1103 Thank you all again 1104 for making the effort to be here 1105 and for being part of the Go community. 1106 1107 For the next few days, please: 1108 tell us what we're doing right, 1109 tell us what we're doing wrong, 1110 and help us all work together 1111 to make Go even better. 1112 1113 Remember to 1114 be friendly, 1115 patient, 1116 welcoming, 1117 considerate, 1118 and respectful. 1119 1120 Above all, enjoy the conference.