Not so sure.
They are crucial for open source - documentation, assets, etc.
But they can also mess up a project with giving power to non-developers who focus on changes like redoing the UX every release, to the detriment of stability, functionality, adoption, and so on. They also attract busybodies concerned with "politics", more so than coding does. It's also a great domain for bikeshedding (as anybody feels like they can do it).
Couldn't agree more.
This reminds me of the codes of conduct hell from a few years ago.
That is an interesting one. "The internet doesn't forget", they say, but all the bs and mudslinging around that got basically purged from the internet. It's impressive sometimes.
Every time I see a respectable project use a Code of Conduct I remind myself that, unfortunately, Caroline Ada won[1] and also that github will ban you if your code uses words they don't like[2]
[1] https://github.com/opal/opal/issues/941
[2] https://github.com/nixxquality/WebMConverter/commit/c1ac0baa...
You don’t have to use GitHub and they don’t have to host your insults. It’s free enterprise.
Just like I'm free not to use Whatsapp, as long as I don't mind not being able to contact most of my family and friends.
And I'm free not to use Facebook, as long as I don't mind not having access to specific medical support groups which are only available there.
And Cloudflare, as long as I can stop using most modern websites.
And so on, you get my point.
You can use whatever you like. They can also kick you off whenever they want. What bit of this is difficult to understand? Is the "free market" not free enough? The general rule is to respect other people. If you start trying to dehumanise or "other" people, don't be surprised when you get shut out.
Those mentioned platforms are big enough that it is not a free market anymore. Guess why the EU is going after them one-by-one.
None of them are monopolies. The EU will eventually be 'looking at' corner stores. If it becomes too costly to operate in the EU, multinationals will eventually leave.
Maybe someone in Europe will invent another cloudflare, github etc. They do have Telegram to replace WhatsApp.
They are monopolistic. If I want to buy Coke, I can go to nearly any store. I don't need to only go to one store.
If I want to interact with an open source project on Github, then I have to go to Github. I can't choose to go to sourcehut or bitbucket to interact with that project.
If github was just another git server (aka just another store) and I could go to any store to get coke (aka open source project), then it wouldn't matter. But it's not just another store or interface.
The product github supplies is a 'service', project hosting. There are multiple providers of that service. Github is not a supplier of the software projects themselves any more than the telco is a provider of conversation or S3 is a supplier of Netflix movies.
The "bending over and taking it" bit.
I don't believe platforms of a size and above should be treated to "they can do whatever they like" / "it's their way or the highway" standards.
I do believe users should have more dignity than to accept that.
censorship is still censorship just because a private corporation does it.... and it's not a free market at all, there are many regulations concerning these industries
I, for one, don't believe in the freedom that "free enterprise" supposedly affords in theory.
I believe in the practical reality, in which some companies/social media/products become near monopolies, and there's always an additional cost to "not using it", not just "chose this or that and get equivalent functionality".
In general, I find your answer not that different than the right wing "if you don't like it here, just move to another country".
But that _should_ be easier in the digital world than the physical one. That Github has become such a center of everything _is itself a problem_.
Codeberg is one answer to that: they host open source projects and also provide CI to those projects on an as-needed basis (decoupling the service from financial constraints by limiting their audience and therefore their costs to provide this service). Hosting code forges for particular communities is another way (I think SDF does this for theirs?). It's easier today than it ever has been in the past.
If we just say "I have to use the monopoly because it's too expensive not to" than we're part of the problem.
Eh. Some things can still change going forward while others won't. The future is unwritten.
I see cultural change as analogous to steering a large ship. You won't be doing any sharp turns but you can gradually move it in a different direction.
Don't worry, people archived quite a lot of it. As did I.
https://news.ycombinator.com/item?id=21386948
The GitHub issue I linked is gone but those archive links are still up.
Never forget the fact they laughed in people's faces when they tried to hold them accountable to their own rules.
This brutal article also came to mind:
https://zedshaw.com/blog/2020-10-07-authoritarianism-of-code...
If nothing else, that while ordeal has shown you can get a job at GitHub even if your only marketable skill is harassing people.
im looking to jump, explain honkey
Yes, the usual attack vector for entryists in an open source project is usually through non code contributions. Intensely political people figure this out pretty easily.
But, what can we do? I like to believe that those anti-social elements are (very vocal) but a small portion of the universe of non code contributors. Project leaders just need to be a little less naive and keep an eye on this possibility to tackle the problem as soon as it appears.
Is it even really true, though? This feels like the kind of idea that circulates among techies who feel like "their people" wouldn't engage in that kind of politicking, even though it's been obvious everywhere I've looked that we're just as capable of making a mess of an organization as anyone else.
perception is reality, and there have been a few high profile cases of people injecting politics into the discussion.
Yes, but the perception seems to be that those people are non-technical people who felt empowered to become involved because the project encouraged non-code contributions like documentation, bug reports, and helping out in the support forum.
The reality as far as I've seen is that the people injecting politics into the discussion are developers, not "normies". The perception exists because some of us have a stereotype of a developer as someone who's only interested in the technical details of a project, so the people who bring unrelated concerns to the table must be non-technical.
How is bug fixing a non-code contribution? You didn’t say bug reporting.
Oops, yes, that was a mistake, I meant bug reporting. Fixed.
How does that apply here? That applies when people act on their perceptions; here we are talking about what the reality is.
I don't know. You could be right. I've found my share of intensively conniving and political techies too. Even some that were highly competent/skilled but had this passion for politics, and a tribal instinct of building a clique of a bunch of followers steamrolling over everyone else wherever they went.
But on the other side, the non-tech infiltration route is also real.
When people say things like this, the first thing I think of is ncurses' absolutely legendary licensing and social drama[1]. Be warned: reading that page in full will take you at least an hour.
To find petty bickering, look no further than most technical contributors. Accusing non-technical people of this sort of thing isn't borne out.
[1]: https://invisible-island.net/ncurses/ncurses-license.html
Your story is from 1996 and 1997.
Of course all the bickering was between technical people — those were the only people around!
More recent example:
https://github.com/kovidgoyal/kitty/issues/879
It's just as true today, though. When the Rust mod team resigned en masse in 2021, it was announced by a programmer (the author of ripgrep) [0], and the conflict was with the core team (also programmers). A supermajority of the contributors to open source projects are programmers, so most famous meltdowns are going to be conflicts between programmers, not between programmers and the tiny minority of non-technical contributors.
I'm still waiting for anyone to give an example of an open source project meltdown that was triggered by non-technical contributors.
[0] https://github.com/rust-lang/team/pull/671
Do you think people are looking to attack and want a vector? A much simpler, less paranoid explanation is that they get involved and then perceive problems. Some of those problems might even be real!
lots of people "feel like they can" code, but surely projects are capable of weeding out bad code contributions. why should it be different with non-code contributions?
But that is the issue. They won't be allowed to ask them to leave.
just don't accept the PR?
Then to endure the endless irrelevant debate, citing the code of conduct, as to why they have to accept the PR? (As illustrated in a few of these posted github tickets).
No they aren't. See darktable and Ansel. I will never use darktable again. https://ansel.photos/en/
How could non-developers force changes to the UX? That requires changes to the code, no?
As for politics and bikeshedding, I have seen plenty of that amongst developers so I'm not convinced non-developers would be more likely to engage in it.
Or they could just give mockups, like in Gnome, Mozilla, and elsewhere, and have enough traction within the project to push for them.
With the amount of hate I see over Gnome's interface designs, if it was true that submitting mockups was enough to force a project to change its direction, Gnome would have a different interface.
The fact that Gnome was able to choose a direction they wanted to go and then go in that direction even over the extremely vocal protests of a large portion of the community is if anything proof that you absolutely can reject mockups from community members if you don't want to implement them. Ultimately, the project decides what interface it wants to have. And community members can protest that direction, they can complain that project's priorities are wrong, they can fork things (and Gnome has forks), they can do whatever -- but they lack the ability to force the project to abandon a design that its owners like. That's a good thing about Open Source.
The idea that UI designers are somehow hijacking Gnome because they advocated for designs that the org voluntarily implemented... it makes no sense to me at all. Does the org own the project or not, it's their choice. Unless the idea here is that Gnome should have been obligated to accept design critiques from people outside of the project and change their internal designs just because the people proposing changes from outside the project knew a programming language; but that would be a silly thing to say.
Well, here's the problem: these people proposing the changes are not outside the project. They are within the project. And their vote is as good as a dev's (and it's easier to gather dozens of them, as it doesn't require skills for doing the much harder and more prolonged dev work).
And in orgs with a non-dev bureucracy and management (like Mozilla and Gnome) they can get buy-in from those "higher ups" too. And they can also create enough friction and bikeshedding on regular FOSS projects too, as long as those don't have a BDFL and everybody has a voice.
So what, your issue is that project owners get to decide who they work with? If the people working on UI in Gnome are part of the Gnome project that is not in any way randos coming in and bikeshedding over the UI -- it's a project self-determining what it wants to do. I'm sorry they're organized in a way that you (an outsider to the project) find offensive.
Yeah, of course the vote of project members is as good if not better than the votes of people outside of the project because these projects get to set up their own orgs and governance structures and they don't have to justify or prove to anyone outside the project why the people they work with deserve to be there. And that is one of the things that is amazing about Open Source. You can just go do stuff and when somebody else shows up on your Github repo and says, "the UI designers are ruining your software" you can tell them to take a hike because they don't get to decide how your project is run. They're not required to consult with you.
----
I don't see what any of this has to do with no-code contributions. Encouraging non-coders to write documentation and tutorials and help with feature suggestions is bad because you have a problem with project management?
By the "higher ups" I guess you mean the literal orgs behind the projects? You don't need quotation marks for that, those are just called higher-ups, that's how organizations work. It's still the case that the people who build and control Open Source projects can take them in any direction they want regardless of what people outside of the projects want them to do.
Of course, Open Source has lots of mechanisms to avoid problems with bad project direction -- notably, forking, which should be hecking easy since all of the people complaining are apparently such excellent programmers.
*cough* Thunderbird *cough*.
In an ideal world, developers write documentation as they're developing. This seems to work really well for OpenBSD and its various project, all of which have some of the best man pages out there.
IMO it works a lot better for software that is aimed at other developers. Writing documentation that is accessible to non-technical users is a different skill.
doesn't even have to be non-technical, just something not normally in your domain.
a lot of documentation is put together as part of some KT handoff, and is written by technical folks in that domain, for folks in that domain.
All BSDs really, and I also want to mention GNU projects, they enforce this well, too. I made contributions to org-mode, and they made it clear that they won't accept a line of code without accompanying tests and, if applicable, handbook adjustments.
Have you found that a new developer is meaningfully less likely to recommend redoing the UX compared to a new non-developer? Personally my sense is that desire to update the UX is more closely correlated with the "newness" than development ability.
Kind of. New developers tend to do some bug fixing here and there, or implementing some small feature, not dictate major changes. And if they do, they're ignored or debated, and that's it.
That would be overwhelmingly true of most non-developer contributors too: they maybe submit one feature request that gets brushed off and then aren't heard from again. The question isn't whether most members of a given demographic are successful in derailing things or not, the question is if non-developer contributors are disproportionately likely to be disruptive to the project.
I don't believe that to be the case, but am open to examples that provide evidence in favor of the claim.
I present to you Ayo.js, a long-dead Node.js fork with almost as many moderators as "core" members. I'm sure there are a variety of reasons why it bit the dust but I'll always view it as a lesson in priorities.
https://github.com/ayojs/ayo
You've clearly touched a nerve, but this article barely talks about UX or political issues at all, it's overwhelmingly about low-recognition work like improving docs, filing good bug reports, and being active in the project's support channels.
The people who do the things that the article talks about do not tend to be busybodies because these are tasks that don't get a lot of attention or recognition, which is why this article was written.
Bikeshedding has become a thought-terminating cliche.[1] 99% of bikeshedding () I see is about things that absolutely have to do with how working at a nuclear power plant is like, not merely how you feel when you commute to and fro. Syntax? Absolutely something that matters. How an API is structured? That too.
It just so happens that everyone can have an opinion on it. So you have a problem with a thousand possible voices, and that many of them might be drive-through busibodies. But that’s still not bikeshedding.
True bikeshedding would be haggling over the styling of the Who Are We page of your promotional website.
[1] Like many, many nouns based on programming blogs from the last twenty years.
Just look at what having a Lawyer with a political axe as a leader did to mozilla.