[dhodell]

It's kind of unfortunate because existing developers have the privilege of experience with the systems and where they're going that external contributors simply don't have, and it will take a non-trivial amount time for interested parties to develop that knowledge.

At the same time, it is an active project with active development that are informed by goals and processes not all of which are open. And really, while the development has been "in the open", it hasn't engaged the public until now. To that end, it's not possible to engage in a "bazaar" approach off the bat, whether or not that's a goal of the project.

Having been active in Go development and seeing some of the issues there, I understand what you mean. I don't think we state anywhere "this is clearly a cathedral model of development", but I think we're pretty clear on it:

* We have a section of documentation on project governance https://fuchsia.dev/fuchsia-src/contribute/governance

* We have a section of documentation detailing different kinds of contributors, acknowledging that there are kinds of contributors with special powers, and also reserving the right to revoke contribution privileges in some cases: https://fuchsia.dev/fuchsia-src/contribute/community/contrib...

To the extent that you can look at these as a set of policies, follow all the policies, submit a change, and have that change rejected, I think that is unfortunate. I think this is much less likely if you first engage with the stakeholders, and having opened up mailing lists, we've made it simpler to do that.

However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion. I can fork the repo, but that's also already the case with Fuchsia.

> the fact they are only now taking potential contributions

We were honest about this too, and our documentation used to explicitly say that we did not accept external contributions.

[barnacled]

The real question is, moving forward, if somebody submits a proposal, properly tested, described and discussed with the community that makes a fundamental or deeper change whether that is likely to be accepted or not.

The bazaar certainly exists for the Linux kernel insomuch that this can and does happen (partly as a result of the fact many companies contribute but none control it). For go it does not, for chromium it does not seem to either.

It is tough for a company with internal aims and pressure to adhere to that kind of model for sure.

And it is good you have been honest about your approach prior to this in that no contributions were taken but now it is a matter of whether or not a non Googler has the opportunity to make such a change, in accordance with your policies.

But obviously as a hobbyist with limited free time I am understandably cautious as to where I put my effort.

Honestly on a personal level it is probably no loss on fuschia's part, I am a minor contributor at best, but the general point stands.

[dhodell]

I understand the concern. I spent the vast majority of my career not at Google while also involved in open source communities, and I can empathize with this. I think one place we have a leg up here is that we do have documented processes for performing this type of work. It's certainly possible that the outcome of a proposal is rejection, but the hope would be the process does that quickly. We're all human and we don't want to waste anyone's time.

One of the cases that people cite for Go rejecting the community outright is the modules work. My perspective is that could've been handled better, but I didn't have a stake in that. But then I look at the error handling proposals, all rejected, including the ones originating from Googlers. And the iteration on generics, which has been reworked several times due to dissatisfaction expressed by community members of all experience levels. I think it's fair to say that even though there are deciders of what happens, they hold themselves to the same standard.

I hope you'll consider at least taking a look as a hobbyist. It's a large system, so both lots of opportunity for contribution and lots to learn. I think many of us are very eager to work with people outside the team, especially as many strive for more social interaction in general, and I know many of us are individually looking forward to welcoming external contributions. Certainly we can never find out if the process works if no one tries.

edit: redundancies

[mook]

I think the important part will not be what gets rejected, but what gets accepted. Nobody will ever remember the rejected error handling or genetics proposals; but people will definitely take notice if the eventually accepted one come attached with Google names.

It's hard for an open source project started (or dominated) by a single company to shake the appearance of being insular. At this point I believe Kubernetes has major contributors from various companies, but I still mentally think of it as Google because, among other things, a bunch of the infrastructure is still Google so it feels very much like Google has dominant control. The dominant company will need to actively drum up interest and try to convince external contributors to take up the work to make it look less lop-sided.

I don't mean this as an attack on Google — getting good community governance is hard; I've also been on the dominant company side on other projects (generally not great at fostering a good external community). I believe it takes extra concerted effort.

[dhodell]

> Nobody will ever remember the rejected error handling or genetics proposals; but people will definitely take notice if the eventually accepted one come attached with Google names.

I guess, but my point is that many of the rejected ones are attached with Google names. Also it's unclear to me that the reason for not remembering is due to who proposes and implements the things -- it seems more likely that this is due to a huge volume of proposals over a long span of time. WRT generics, it's also very clear that community feedback is being incorporated.

So this is why I think the issue is really rejection. Nobody's really upset about how error reporting or generics are being handled because it's clear that community feedback is being honored, and it's clear that the core team is holding themselves to the same standard the community is being held to. Those two properties aren't as clear in the packaging situation.

That's why I think Fuchsia having a documented community process and also having been working within that process for some time is important. We're already holding ourselves to the standard we're asking of the community.

> I believe it takes extra concerted effort.

This is absolutely true, and it's why I'm here trying to make sure that folks know there are people involved in the project who care greatly about its open nature.

Many people have pointed out that the existence of open source doesn't necessarily make the project accessible for contribution, and that's I think the more difficult problem to solve in the short-to-medium-term.

[ajanicij]

> However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion.

I am aware of one, but an important one: ZeroMQ. Thanks to the late Pieter Hintjens, this project has C4 model. I have not seen any other project where I submitted a PR and maintainer accepted it less than half-hour later, no questions asked. And it works wonderfully; ZeroMQ is live and well.

[garaetjjte]

That one is fun

>16. Maintainers MAY merge incorrect patches from other Contributors with the goals of (a) ending fruitless discussions, (b) capturing toxic patches in the historical record, (c) engaging with the Contributor on improving their patch quality.

https://rfc.zeromq.org/spec/42/

[dhodell]

Neat, thanks for that info. I really appreciated Pieter and his work; it's nice to hear his community and project are still well.

[st1ck]

> However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion

The word "bazaar" alone should imply discussions, including some haggling and shouting. If no discussions were expected, it should've been called supermarket or something like that.

[fnord123]

> However, the "bazaar" is also a bit of a myth in this regard. I'm not really aware of any open source projects where I can go submit a PR without talking to anybody and have the expectation that it'll be merged without discussion.

Bazaar is not a myth at all. The distinction was never 'are patches always merged' but is the development done in public. The issue with Google projects is more about in-group and out-group and if you're not in Google, it's hard to be considered 'in-group.

But even if the complaint was that all projects had this issue; it's just wrong. I've made and received plenty of drive by contributions with no discussion before the PR was made. You can't expect it to be merged any more than you can expect a romantic interest to agree to a date. But that's just interacting with people.

[dhodell]

I agree with you. My point here was exactly that is not how a bazaar model functions. Hence the use of "in this regard."

[fnord123]

But it comes from observing what the Linux community did and giving it a name. It wasn't an ivory tower meditation but a field observation. I don't know how one can then turn around and say that it is not how the model works. Was the original observation incorrect?

It might sound like I'm being pernicious but I think fuchsia is great tech and I want it to succeed. I feel compelled to cheer you on in seeing the bazaar model as very real and good thing to pursue.

On the topic of more community engagement... despite Zircon not being an outright microkernel, maybe it's still appropriate for someone in the Fuchsia community to submit a talk to the FOSDEM 21 Microkernel devroom

https://fosdem.org/2021/schedule/track/microkernel/

[dhodell]

Sorry, I am doing a poor job communicating. I agree with your assessment of how the bazaar model works.

When I said "in this regard", the intent was to signal that "bazaar" explicitly doesn't mean an anarchic situation where all change is accepted. It's maybe more anarchic than the cathedral model, but it's controlled anarchy.

The reality is that most projects fall somewhere between the two models. The people most heavily invested in the projects tend to drive change, and this is sometimes at the behest of the community. That doesn't automatically make the project a cathedral.

Similarly, while Google controls the direction and funds the development of Fuchsia, our development process (which we publish on fuchsia.dev in the Governance section) is very much bazaar-like. This is difficult to see because we haven't been open about our processes, and we haven't engaged externally with developers. To that extent, we've been very much "cathedral". This expanded model is us inviting folks to join us in the bazaar.