[olladecarne]

> those working for the company get considerably more say and control than outside contributors

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?

[coddle-hark]

I think the problem is that Google doesn’t really want or need outside collaboration in their open source projects. They have project managers that steer the ship and more than enough smart people to write code. What do they need you for?

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.

[dhodell]

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.

[kortilla]

These kind of projects are just “open washing” at that point. The source is available, but outsiders can’t meaningfully contribute stuff outside of the preordained roadmap nor is the project beholden to community consensus.

As an open source contributor, it’s very unfulfilling and disappointing to find out you’re essentially an unpaid contributor to a company project.

[dhodell]

I'm playing Devil's Advocate here because I sympathize with your point, but isn't there a way you can squint and look at this weird that it's true of pretty much everything else? IBM makes tons of money off of Linux, for example. iXsystems profits off of FreeBSD. Facebook profits off of their wildly popular C++ libraries.

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.

[chme]

> IBM makes tons of money off of Linux, for example.

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.

[dhodell]

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

[sanxiyn]

I think unpaid internship is unquestionably a good thing. It's consensual, and unpaid interns are usually happy to do unpaid internship.

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.

[fnord123]

>I think unpaid internship is unquestionably a good thing.

Unpaid internships are definitely questioned. You're very much incorrect here.

[ac29]

For one,they provide a major advantage to people who have enough money to be able to afford to go unpaid. And really, if a company can't or won't pay you even minimum wage (something like $500/week on the high end in the US), that should be a huge red flag.

[smichel17]

I feel you've picked that one paragraph to focus on and ignored OP's point. Namely:

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