back

by nateb2022·3y ago·view on hn ↗
I think the Maintainers are doing a good job, all things considered.

People are certainly free to fork Go, or any open-source project, and take on the roles and responsibilities of Maintainers, but I believe fragmenting the community has almost always led to the overall downfall of a language. Communities are stronger united.

With that in mind, generally Maintainers have the prerogative to decide the specific areas of a project that need improvement, and to focus their time and energy there. Contributors are welcome to contribute code to areas highlighted by Maintainers, and generally Maintainers are responsive and happy to work with those.

Certainly with the volume of PR's (100+) and Issues (5k+), the current Maintainers have their hands full. Decisions will have to be made, and priorities established. While an argument may be made that we need more Maintainers, this is not an overnight solution. A Maintainer needs to really "own" the project, and has to have substantial knowledge of the code inside-out.

Developing a great product like Go takes a lot of time and effort. I believe that slow(er) development is a fine tradeoff for the polished, focused language that Go has become. I would gladly take that any day over a fast-and-furious project where development happens at light-speed but the overall quality decreases with every commit.

4 comments
> Certainly with the volume of PR's (100+) and Issues (5k+), the current Maintainers have their hands full. Decisions will have to be made, and priorities established. While an argument may be made that we need more Maintainers, this is not an overnight solution. A Maintainer needs to really "own" the project, and has to have substantial knowledge of the code inside-out.

I think one of the big problems is that decisions aren't being made. Issues, proposals, PRs, etc. get ignored. Ignoring is not a decision, it's the absence of a decision.

It's fine if they don't want to accept/fix/invest/etc in whatever issue a contributor is raising, but by not providing a rationale, the community just gets left in the dark without any idea how to proceed.

FYI there is a weekly review of a subset of open proposals here: https://github.com/golang/go/issues/33502
I'm aware. There's no timeline for when a proposal may actually be considered. It certainly isn't submission order. So proposals sit around for an indefinite amount of time before entering into the process to give them a definitive decision.
Is this scenario better managed in other language projects?
I've made contributions to Rust repos and it was a great experience, they helped me along and were very quick with responses. I never even considered it for Go because the community shot down every idea I had.
I'm a maintainer of some smaller open source projects -- you have to consider it from the project owner's point of view. To say they "shoot down ideas" is a negative way of saying it, but from their point of view they're carefully selecting and designing features and code that fit the design philosophy of the language. If the Go developers included every idea that users submitted (and there are many! -- I read the mailing lists), the language and standard libraries would be a sprawling and incoherent pile.
I imagine it varies wildly based on the project. How any other project behaves doesn't change the experience of working with the go project.

Comparing go to itself, I feel like they've lost some steam and are coping with the ecosystem steadily growing. I can't say for sure if that's the case, and I can have a lot of empathy for anyone just feeling exhausted all the time these days. That doesn't change the experience on the trying-to-contribute side of the interaction though.

Complex systems tend to attract this class of opinions where individuals believe their judgement would improve the overall system. They are nearly always wrong, otherwise they would have devised a better system already.
I don't know. Authors that get big enough to ignore their editors can produce some pretty awful work. The role of editor has value.
It's not about ignoring editors, it's about taking constructive feedback, and the ratio of constructive feedback to noise is very low in complex projects. In those projects, people that aren't heavily invested typically don't know enough about the wider project to make valuable contributions.
I don't follow how you got from 'complex problems don't have simple solutions' to 'editors don't add value'
Fair. It was the "otherwise they would have devised a better system already" bit.

I'm saying that people who are not capable of writing a bestseller (solving a complex problem) are still capable of editing a bestseller (their judgement would improve the overall system).

Except that implementing ideas usually takes a non-zero amount of time.
> but I believe fragmenting the community has almost always led to the overall downfall of a language

I'd argue the opposite. Most programming languages that truly thrive have multiple independent implementations. Go always (1.0+) had multiple implementations and for some of us this was a factor in accepting it as a serious contender.

Fragmentation is not a concern as long as the language and standard library remain well defined. The more the merrier.

(I'm not arguing for trying to wrestle control from the current team, I think they are doing a fine job. Only meant to address the fragmentation thing)

>but I believe fragmenting the community has almost always led to the overall downfall of a language

Warning, I am not a professional developer, only a mere scripter.

Aren't forks and transpiled languages sometimes a driving force? Typescript/coffeescript pushed changes in Javascript. Scala on the VM pushed changes in Java. jQuery as a DSL of javascript even pushed changes in the language.

And in all of these cases, the branch language/framework eventually becomes less relevant, but that does not take away the utility and influence they provided in their time.

So if someone imagines running a Golang fork and successfully develops the fork with new features and/or better processes and faster iteration, it may be useful even if they end up dying once and if Golang itself incorporates the changes.

With Typescript/coffeescript, there were core language improvements to the language that led to popularity in the JavaScript community. Things like types and arrow functions were welcome additions and gained adoption.

I think that a Go fork would be more like, for example, Go with text internationalisation fixed. It wouldn't be very interesting to a large part of the Go community who is using the language just fine.