dhodell

Ironically, several folks who worked on Plan 9 later worked (or continue to work) at Google, although none of them worked on Fuchsia.

<ramble> To me the major overlap between them is their designs are clearly informed by the contemporaneous shape of network architectures. Fuchsia is a take on what an OS design would be as a set of named microservices that can be routed. Plan 9 noticed network topologies of compute labs and clusters weren't too different, and both graphs could be represented in filesystems. The major visible difference to me is that the visibility of routing is much more apparent in Plan 9 than it is in Fuchsia. It's still a little difficult to understand how and where capabilities propagate through the system.

Implementation-wise, FIDL is a much different take than 9P2K. Though much simpler, 9P2K forces every API to exist via a filesystem interface (many of the higher level protocols also involve quite a lot of string passing) and struggles with throughput of streaming operations. Individual FIDL APIs might have similar problems, but the message encoding itself is relatively more efficient. </ramble>

These things work in tandem: the base system is pinned, but can also be easily updated with an OTA. Packages existing outside that set are resolved on-demand, and are thus updated when components in a package are run after a new version is published to the package repository.

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.

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

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

> they will also have to release their changes

Strictly speaking, they only have to release their changes to people they distribute their product to. It's convenient to keep it entirely open, but not a requirement.

I agree that folks should contribute code to places they feel comfortable in any case. As I mentioned in GP, if you separate out pay, there are other reasons to work on OSS, and these motivations can coexist.

But this is not always a fair label to apply. If I release a device running Android that prevents you from using your own Android, that's a problem with me and the device I released, not with Android. This seems to be conflating hardware and software -- which is understandable in the context of operating systems -- but we should be clear about the cause of the problem, which has nothing to do with the openness of the code.

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

Without intending to either minimize or represent OP's opinion, my thought is the cases people get frustrated about are really unfortunate. In these cases, community opinions have been solicited -- sometimes committees are even formed -- and folks put in significant effort.

The oft-cited case with Go (and I'm paraphrasing heavily, so this account is likely unfair to everyone involved) was when Peter Bourgon formed a committee to design a Go packaging system, there were a bunch of meetings held that included core team members, and Russ apparently surprisingly came out with the Go modules proposal. The core team decided to adopt Russ' work. The team's perspective is it solved their problems simply and cleanly, and it came with an implementation. The community perspective was that the core team was now a sort of cabal.

I think the issue here isn't that the community's project was rejected, it's that there is a perception that folks were let to waste their time. It seems that sometimes people want this idealized model where an open project has a community that is on equal footing with the project owners, but I rarely see this to be the case in practice. Ultimately some individual or group holds a "voting share" that outweighs the community.

We have a documented process for system changes in Fuchsia that we have already been following internally. I've seen various proposals rejected; I've had proposals of my own rejected. It's always disappointing to have work rejected, because no matter what, it takes effort to come up, submit, and socialize work proposals. It's easy to feel slighted, especially when you're contributing for free while the folks making the decisions... well, it's their job.

I think I can say that it is nobody's goal on Fuchsia to waste folks' time. But I think it would be naive to think this kind situation couldn't or won't occur in the future. I just hope our transparency about our process and our availability to communicate with the community through lists will help mitigate negative feelings when a proposal representing a non-trivial effort is rejected.

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

There is not a RPi port, and that's non-trivial for reasons I vaguely recall to be related to display driver weirdness. The system does run on arm64le.

Well, sure. Because people who want to develop products on some platform also want some kind of warranty, which is explicitly not provided.

Google establishes with the public a warranty- and guarantee-free use license. If someone feels they've been harmed by the software, they're prevented by the open source license from suing Google, but they're (more importantly) also giving up their right to sue the individual contributors.

At the same time, vendors want to be able to hold suppliers accountable for support and warranty on products that are supplied. Permitting sublicensing allows Google to sell the software to OEMs and vendors with support agreements that allow those vendors to hold Google responsible for that support (rather than the individual contributors).

There's a lot of complaint about the sublicensing going on, but I think most vendors aren't going to build systems where they can't get support, and I don't think contributors actually want to be liable under tort law for the code they provided for free.

Then again, maybe the objection is to giving code to Google that Google can profit from. I guess that's fair, but you don't _have_ to contribute code and you're also not prevented from sublicensing and trying to turn a profit yourself.

(edit: typo)