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.