Having worked for corporate software projects and for free software projects, I can't say that free software projects are dominated by personnel issues any more than corporate software projects.
The main difference is things tend to happen out in the open for free software projects, and things happen behind closed doors within corporations. So it just seems like there is more drama, because issues are hashed out in public, things are not swept under the rug.
> The main difference is things tend to happen out in the open...
I don't think this is just due to a difference in the degree of openness in dealing with personal issues.
It's also the fact that project maintainers can use the project to advance their personal agenda, while a company cannot do that to the same extent.
For example, imagine if a company terminated a business partnership based only on the suspicion of sexual discrimination at the partner firm.
I think most people would find this premature or inappropriate, especially if the partner firm was not found guilty in a court, or if it did not admit any wrongdoing, and there isn't a history of such allegations at the firm.
I think it's a motivating factor to attract contributions.
I was catching up on C++11/14/17 after spending a lot of time in Rust recently and I realized that I see the C++ standards committee as this nameless faceless void, and the Rust team as these friendly people on GitHub and IRC. There's this college kid who thinks using "pre-pooping your pants" as a technical term is a good plan, this Brooklyn hipster who really likes communism, etc. Whether or not I endorse their "personal stuff", I have a sense that there's a community of real people and not just names on a community, and that makes Rust as a language attractive. If I want to contribute something to the language, there are people I can talk to, and there's a clear way for me, as I am, to do that. I have no idea how to propose something to C++ without working for a company that has a seat on the standards committee. Maybe there is a way, but I'm certainly not under the impression that there is a way.
Projects that are more able to attract contributions will be healthier, more technically productive, and more secure (via Linus' Law). It's meaningless to try to focus purely on the technical if you don't have the people to do the technical work.
I see C++ and Rust in the opposite way: Rust is developed by Mozilla for its needs and about as open as something from Apple, while the C++ committees include lots of respected experts, many of which popular and/or friendly.
If that were the case, much of the community-driven work going towards - for example - specific embedded targets wouldn't happen. What is the case is that one of the major users of Rust is Servo, which definitely runs into more problems at large scale then other projects.
Rust is primarily community-driven and that is a conscious choice by Mozilla. If it were primarily for Mozilla, we wouldn't run research into how production users use it.
Finally, Mozilla cannot be compared with Apple at all, for all that's bad about them, there's an extreme amount of stuff that happens very much in the open and the clear, with the possibility to influence it.
We have the discussion processes you want, but the language is 2 years old, it's certainly not comparable to C++ on that angle, yet.
Maybe, maybe not, but the point is there is a much lower barrier for people to do so whether or not there is any reason for it when it doesn't affect their livelihood.
There is also a much lower barrier for someone else to take it public for the same reason.
If personal issues create problems in a corporate project, people get fired. This alone creates a chilling effect - people put up with a lot of crap before they make the problems public, see Uber or any other story about a toxic workplace.
The chilling effect seems only true for toxic environments. Yet most workplaces are not toxic in the way that you might imagine Uber to be. There are many tech companies (large and small) that are pro-active about creating a good environment. Also, the workplace makes you think twice about bad behavior, because it has real consequences like losing your job, unlike on the internet. See also cookiecaper's comment.
Agreed. As an open sourcer, a night at the bar and smartphone in hand is all it takes to get the ball rolling when the inevitable issues start appearing in your inbox. You take your oss projects personal, for better or worse. Good take on the issue, when (you feel) the whole company is fucked, its hard to stand up and declare an issue local to you.
> If personal issues create problems in a corporate project, people get fired.
Or promoted, or anything inbetween. Some corporate projects live for years because a certain manager can't be seen to have wasted so much money on a failed one. Personal/political issues are everywhere in the corporate world.
I disagree. I think that free software has more of these issues because it's done on a volunteer basis.
The commitment and interdependence of the employment relationship smooths over most disagreements at work. People may not like it, but they stay aboard because, well, what are they going to do, leave? And what's the company going to do, fire them?
No such arrangement exists in voluntary efforts. People will work together fine as long as they all agree on most things. Once a real conflict emerges, without the underlying commitment and interdependence, people just decide it's not worth the frustration and walk away.
> in voluntary efforts ... people just decide it's not worth the frustration and walk away
You make it sounds like it's a bad thing. Being able to focus your energies on healthy communities in a feature.
> employment [...] smooths over most disagreements at work
No. It just hides them. Backstabbing is popular, so it is disenchantment and cynicism. People biases turn into harsh peer performance feedback, refusal to hire and poor cooperation. Sociopaths get promoted.
> You make it sounds like it's a bad thing. Being able to focus your energies on healthy communities in a feature.
No, it's definitely a bug.
Walking away from personal conflicts weakens projects and communities through fragmentation. It feeds the selfish desire for safety and isolation at the expense of developing the more healthy ability to put aside personal differences in pursuit of a greater goal.
As a result, these so-called "healthy communities" will eventually end up more fragile and more fragmented than their original counterparts, especially since personal conflicts are inevitable in any project. What a fine way to derail a movement.
> No. It just hides them...
This is only true for toxic workplaces, but most workplaces are not toxic. There are many tech companies (large and small) that are pro-active about creating a good environment.
Because they are often started by a small group (usually just one) of people who are passionate about the subject enough to work on it in their spare time, so they have stronger personal involvement. That provides the drive, but also the side-effect of personal drama when things go wrong.
Larger institutions usually setup protections against just that kind of drama, but often with the side-effect of reducing motivation.
In my experience in the software industry, I've seen enough feuds, ego-related fighting, insults, people having mental breakdowns and lashing angrily at everyone around them (this happened more than once, at different workplaces!), and rude team members demeaning others over their alleged lack of technical skills, that I think these things happen everywhere, regardless of whether the project is free or proprietary. It's just that it's easier to see in free software projects.
In my experience, it's the same with any volunteer project that doesn't have a large amount of contributors and low barrier of entry for active contribution.
My theory is that the traditional idea of "ownership" does not translates to free software. In fact its one of the reason why I am hesitant to be involved with any type of open source "community". In a traditional corporation, you own shares or worse stock options but their are clear legal rights. In Open Source on the other hand you can start a very popular software spend years of your life toiling away and nurturing it, and then suddenly a bunch of activists make an issue out of a donation you made several years ago. Instantly you find yourself kicked out of the organization. Now if it were a company, sure you might still get kicked out the company but your shares will remain intact.
These days with random unverifiable accusations, extreme political correctness, & activists going through history to dig up mud, open source community has become hazardous to ones career.
Groups of people in general are dominated by personnel issues, unless you're a small group of people with very similar backgrounds. Free software projects are communities first and foremost, with the software as an output of that community.
much free software is done on spare time, so people are most often personally involved in their "babies". Creating an institution allows one to take some step back, but so may the motivation... I wonder things are really this way...
I think a combination of that, and that with closed projects the drama like this doesn't tend to end up in public purview, sometimes not even among the workers in a company if HR does a good job of not letting it turn into a big issue. That's one kind of situation that companies tend to have an advantage in dealing with since they can more easily fire/remove a person causing problems from a project. That's a lot harder with a publicly developed open source project.
> end up in public purview, sometimes not even among the workers in a company
I agree. The exact same thing happens on closed corporate projects, it just happens behind closed doors. You're right - sometimes a co-founder gets pushed out for political reasons, and even within the company most people don't know what the whole story is.
Also, personal drama can have a negative effect on the rest of the team, and in a business environment, good HR would try to minimize that effect. But there is no such equivalent in the volunteer world.
