6 ms·

His comments are fine, but don't engage with any of the criticism or concrete points others have made. The "Go Is Not a Community Driven Project" post really d

by Lazare 7y ago

His comments are fine, but don't engage with any of the criticism or concrete points others have made. The "Go Is Not a Community Driven Project" post really dug into detail how, in a specific case, Go did not behave as a community driven project, and it was made very clear that Go was Google's language, not the communities. Responding with, in essence, "but we love the community!" is great, and probably true, but...unless it's followed up by "...and that's why we feel so badly about the previous events, and have made these specific changes" (or at the minimum a rebuttal of the specific criticisms), it doesn't really....mean anything? Keep in mind, the closest we've got to introspection from Cox about the modules issue was a "I'm sorry everyone else is upset, I must have not explained things well enough" non-apology. Which is fine! The Go team doesn't need to apologise for running their language development process however they see fit...but it does underscore the issue. Fundamentally, a decent chunk of the Go community thinks that the modules process was fundamentally broken, and the Go team thinks the modules process was fundamentally fine. I would interpret the subtext of Cox's post as "we really wish the community would be fine with the process". No doubt. Finally, there's something a bit patronising about this: > I spent a while trying to work out what I want to say about the general theme of Go and open source, but in the end I realized that my talk at Gophercon 2015 is a better articulation of what open source means for Go, and what Google's role is, than any email I can write in a few hours today. You can read the blog post version, “Go, Open Source, Community,” at https://blog.golang.org/open-source https://blog.golang.org/open-source, and I am including a copy below. I reread it this morning, and I still believe everything I said then. The current discussion is about events after 2015, by people who are well aware of that talk. If people are questioning how the Go team is interacting with the community even after that talk, then maybe it isn't sufficient, and you need to do more than just tell everyone to read it again?

hermitdev 7y ago
It seems to me, as an outside observer, that golang is OSS. In that "hey, here's the code, you're welcome to tinker with it and all," but we're not accepting community contributions (or community contributions come under such heavy internal to Google scrutiny, they're unlikely to be accepted upstream, which discourages anyone from attempting). Again, outside observer as a non golang user, but this is my impression. Any non-Google's contributing care to share experiences. This perceived (on my part) hostility to the non Google user community definitely keeps me from even taking a look at it. I use C++, C# and Python professionally. I'd potentially give Rust a go if I had time to learn it (my job currently wouldn't allow it, as we're mainly a C# shop, only now branching into Python - few of the main reasons I was hired was business domain knowledge and +15 years experience in both C# and Python). My 3 main languages all have active engagement with their user community and 2 of the 3 aren't controlled by a single corporation. C# is definitely driven by MS, bit they are actively engaged with their development community and listen to feedback and accept PRs for .Net Core.
- hermitdev 7y ago
  I asked for people to contrafute my perception, not just a downvote. I posted my perception as a nonuser, non member of the golang community, but with my perception of my perceived hostility against non googler memebers of the community...and I get met with no comments and downvotes, which reinforces my perception (deservedly or not) of hostility towards non-googler involvement in golang development. So, yeah, thanks. Golang is something I will now not likely something I will ever pursue.
  - deleted 7y ago
    [deleted]
  - deleted 7y ago
    [deleted]
  - tomhoward 7y ago
    Your comment isn't downvoted anymore, and there's no way of knowing who downvoted you or why.
- Lazare 7y ago
  > It seems to me, as an outside observer, that golang is OSS. That seems fair, yes. Although while some people are unhappy because they're just not fans of that model, I think more of the unrest is because the Go team keeps saying they want it to be more community driven, and then there being a (perceived) disconnect between intentions and reality. If your language has a BDFL, and they make arbitrary decisions, well, what did you expect? And lots of people are fine with that, and if you're lucky then, like Python, you can eventually transition to a more community driven model. Sometimes it seems to me that the only people who think Go isn't being run exclusively by the Go team are the Go team themselves. :)
  - hermitdev 7y ago
    I think you've succinctly put the issue(s) I have with Go. Most languages either have a BFDL, a committee or a corporate DFL, which is the case with golang and Google, and I think to a far lesser extent with C# and MS. MS in the last few years seems far more accepting of community contributions to their "core" language, whether its ideas or actual PRs. Admittedly, not all MS OSS projects are equal, there are a number of "here's the code", but it's going to be driven internally, versus a more traditionally driven mix of a primary corporate driver and OSS community contributions. One of the things I'd love to see is a bespoke cross platform DB API. I'm currently using zillow's cTDS lib, which has been great, except it can't support table valued parameters, because FreeTDS doesn't. Yet pytds supports SVTPs, but seems to only support bulk copy via a file. I wish that MS would provide a bespoke lib that provided all of this functionality (TVPs and BCP without an intermediate file).
0815test 7y ago
> in a specific case, Go did not behave as a community driven project Why are people saying this? What is your reply when folks point out that the "community-driven" modules solution did not meet the needs of anyone managing a sufficiently-large project with independently-developed (i.e. 'community'!) dependencies? Rust does the right thing there, this is a fact.
- sagichmal 7y ago
  dep absolutely met the needs of most/all large projects and advanced users.
  - AstralStorm 7y ago
    Who is using it who is not Google? Did anyone with a big project in go even chime in, or is it that there are just no big projects yet?
    - Lazare 7y ago
      Depends what you mean by "big", but between Docker, Influx, Cockroach, etcd, all the hashicorp projects (consul, nomad, terraform), caddy, grafana, bolt, etc., there's a fair number of pretty big golang project around. And most of them seemed pretty happy with dep...
  - 0815test 7y ago
    > dep absolutely met the needs of most/all large projects and advanced users. ...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper, and dep critics were right to highlight it. That these critics might be mostly Googlers in this specific case would seem to be a red herring.
    - sagichmal 7y ago
      > ...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper No, it isn't. Most other dependency management tools don't allow this condition.

by Lazare 7y ago

hermitdev 7y ago

It seems to me, as an outside observer, that golang is OSS. In that "hey, here's the code, you're welcome to tinker with it and all," but we're not accepting community contributions (or community contributions come under such heavy internal to Google scrutiny, they're unlikely to be accepted upstream, which discourages anyone from attempting). Again, outside observer as a non golang user, but this is my impression. Any non-Google's contributing care to share experiences. This perceived (on my part) hostility to the non Google user community definitely keeps me from even taking a look at it. I use C++, C# and Python professionally. I'd potentially give Rust a go if I had time to learn it (my job currently wouldn't allow it, as we're mainly a C# shop, only now branching into Python - few of the main reasons I was hired was business domain knowledge and +15 years experience in both C# and Python). My 3 main languages all have active engagement with their user community and 2 of the 3 aren't controlled by a single corporation. C# is definitely driven by MS, bit they are actively engaged with their development community and listen to feedback and accept PRs for .Net Core.

hermitdev 7y ago
I asked for people to contrafute my perception, not just a downvote. I posted my perception as a nonuser, non member of the golang community, but with my perception of my perceived hostility against non googler memebers of the community...and I get met with no comments and downvotes, which reinforces my perception (deservedly or not) of hostility towards non-googler involvement in golang development. So, yeah, thanks. Golang is something I will now not likely something I will ever pursue.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
- tomhoward 7y ago
  Your comment isn't downvoted anymore, and there's no way of knowing who downvoted you or why.
Lazare 7y ago
> It seems to me, as an outside observer, that golang is OSS. That seems fair, yes. Although while some people are unhappy because they're just not fans of that model, I think more of the unrest is because the Go team keeps saying they want it to be more community driven, and then there being a (perceived) disconnect between intentions and reality. If your language has a BDFL, and they make arbitrary decisions, well, what did you expect? And lots of people are fine with that, and if you're lucky then, like Python, you can eventually transition to a more community driven model. Sometimes it seems to me that the only people who think Go isn't being run exclusively by the Go team are the Go team themselves. :)
- hermitdev 7y ago
  I think you've succinctly put the issue(s) I have with Go. Most languages either have a BFDL, a committee or a corporate DFL, which is the case with golang and Google, and I think to a far lesser extent with C# and MS. MS in the last few years seems far more accepting of community contributions to their "core" language, whether its ideas or actual PRs. Admittedly, not all MS OSS projects are equal, there are a number of "here's the code", but it's going to be driven internally, versus a more traditionally driven mix of a primary corporate driver and OSS community contributions. One of the things I'd love to see is a bespoke cross platform DB API. I'm currently using zillow's cTDS lib, which has been great, except it can't support table valued parameters, because FreeTDS doesn't. Yet pytds supports SVTPs, but seems to only support bulk copy via a file. I wish that MS would provide a bespoke lib that provided all of this functionality (TVPs and BCP without an intermediate file).

0815test 7y ago

> in a specific case, Go did not behave as a community driven project Why are people saying this? What is your reply when folks point out that the "community-driven" modules solution did not meet the needs of anyone managing a sufficiently-large project with independently-developed (i.e. 'community'!) dependencies? Rust does the right thing there, this is a fact.

sagichmal 7y ago
dep absolutely met the needs of most/all large projects and advanced users.
- AstralStorm 7y ago
  Who is using it who is not Google? Did anyone with a big project in go even chime in, or is it that there are just no big projects yet?
  - Lazare 7y ago
    Depends what you mean by "big", but between Docker, Influx, Cockroach, etcd, all the hashicorp projects (consul, nomad, terraform), caddy, grafana, bolt, etc., there's a fair number of pretty big golang project around. And most of them seemed pretty happy with dep...
- 0815test 7y ago
  > dep absolutely met the needs of most/all large projects and advanced users. ...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper, and dep critics were right to highlight it. That these critics might be mostly Googlers in this specific case would seem to be a red herring.
  - sagichmal 7y ago
    > ...as long as your community dependencies never happen to depend in-turn on differing major releases of the same module. This is absolutely a show-stopper No, it isn't. Most other dependency management tools don't allow this condition.