5 ms·

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

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 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/contributor-roles#specialized-roles 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 6y ago
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 6y ago
  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 6y ago
    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.
ajanicij 6y ago
> 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.
- dhodell 6y ago
  Neat, thanks for that info. I really appreciated Pieter and his work; it's nice to hear his community and project are still well.
- garaetjjte 6y ago
  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/ https://rfc.zeromq.org/spec/42/
st1ck 6y ago
> 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 6y ago
> 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 6y ago
  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 6y ago
    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/ https://fosdem.org/2021/schedule/track/microkernel/
    - dhodell 6y ago
      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.

barnacled 6y ago

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 6y ago
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 6y ago
  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.

ajanicij 6y ago

> 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.

dhodell 6y ago
Neat, thanks for that info. I really appreciated Pieter and his work; it's nice to hear his community and project are still well.
garaetjjte 6y ago
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/ https://rfc.zeromq.org/spec/42/

st1ck 6y ago

> 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 6y ago

> 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 6y ago
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 6y ago
  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/ https://fosdem.org/2021/schedule/track/microkernel/
  - dhodell 6y ago
    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.