As someone who knows little about open source politics, I'm genuinely curious about how people expect this should work. What are the large open source projects that have the gold standard for this that I can learn about?
My initial reaction is that if a company contributes considerably more to a project, shouldn't they have considerable more say? For example if they have 20 full time engineers working on it and have contributed 95% of the code, then if I come along and make a few changes should I have equal say and control over the project?
I think that’s often the (subconscious?) attitude Google has towards its open source projects at least. Which would be fine if they didn’t try to make it seem like their OS projects are a welcome place where anyone can contribute ideas and code and move the project forward.
As an example: Angular is open source but it’s very much a Google project. Rails is also open source but it’s a broad collaboration, certainly not a “37signals project”. Most people would rather spend their time contributing to the second kind of project.
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.
As an open source contributor, it’s very unfulfilling and disappointing to find out you’re essentially an unpaid contributor to a company project.
I think we really need to divorce "profit" from "open source". OSS is great because we can contribute our own ideas to it, because we can learn from it, because we can form communities around it. It's also useful because it's a vector for entrepreneurship. Edit: why should these be mutually exclusive properties?
It's fair to point out that it can be a vector for exploiting unpaid labor. But that's an accessibility issue that exists already. For example, it's easy to tell folks interested in the field to "do open source work" if they want to get a job in the field. If you're a low-income single parent, this doesn't make CS more accessible, it's a sick joke. Even without profit, open source isn't this bastion of opportunity that we sometimes like to think it is.
You make an excellent point that it's hard to learn large new systems. But it's not impossible. Indeed, it's possible to make super meaningful contributions to the system in "limited time", starting with net zero knowledge: https://blog.quarkslab.com/playing-around-with-the-fuchsia-o.... To that end, I have to disagree that we're the kind of project that outsiders can't meaningfully contribute to.
I've addressed the point of community consensus elsewhere. All I can say here is that I personally owe my career to open source, and I'm therefore committed to helping others do the same. We opened the project to communicate with people. My personal goal is to do this and help as many people as possible succeed professionally through this vector.
Personally I would rather contribute to a GPL licensed project, because if big companies try to profit of it, they will also have to release their changes. Those could improve the project, and now the community does no longer have to do themselves -> Community devs get payed back in development time that they would have to spend themselves.
With permissively licensed projects (or commercially dual-licensed), where big companies are allowed to just take and improve it internally without giving anything back to the community, a community dev would pretty much be an unpaid developer for those companies.
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.
It makes sense you are not happy to do unpaid internship, but the only thing it shows is that you are not the target audience.
Unpaid internships are definitely questioned. You're very much incorrect here.
> The whole issue I have with it is that they pretend otherwise. With go many people laboured under the misapprehension that they could have more input than was actually possible.
> The cathedral model is fine but be honest about it.
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.
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.
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
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.
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 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.
>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.
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.
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.
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
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.
And probably that works well for go and keeps a very clear philosophy and style for the language. It is just the fact they very blatantly misled the community on the scope of possible contributions that frustrates me.
Fuschia does, in all fairness, appear to be considerably more honest on these issues.
There's nothing wrong with an open source being controlled by a company or even existing only to privilege a specific company, but it's important not to mislead open source developers into thinking that a project has different objectives than what it has.
There generally tends to be an insular 'cathedral' rather than 'bazaar' approach to Google projects where those working for the company get considerably more say and control than outside contributors.
The whole issue I have with it is that they pretend otherwise. With go many people laboured under the misapprehension that they could have more input than was actually possible. Not so different with chromium.
The cathedral model is fine but be honest about it.
With the Linux kernel if you have a good idea and can defend it you have a genuine chance of contributing. So I know my limited spare time efforts aren't wasted. With fuchsia I couldn't be so sure.
I hope I am wrong but the fact they are only now taking potential contributions suggests otherwise.