Alright y'all. GitHub/Gitlab isn’t an app store, and it’s time anyone stops pretending it is. A recent online debate I had the (mis)fortune of partaking in highlighted the never-ending clash between non-technical users and the developer community—and how much of the frustration stems from misplaced expectations. Now I am all about getting rid of gatekeepers, but there are ways NOT TO learn in tech.
This debate centered on expectations of GitHub’s role in software distribution versus user experience. Both sides—the OP and the defenders—came from fundamentally different understandings of what GitHub is and how it works. Although OP later tried to reframe it as a dev community problem.
Here’s a breakdown:
The original poster (OP) misunderstood GitHub’s purpose, expecting it to cater to non-developer users with polished, easy-to-install software. They criticized the lack of direct download options and claimed developers should use alternative platforms for consumer-facing software. They suggested projects meant for developers should be clearly labeled to avoid confusion….but my guy…what do you think GitHub is?
The defenders gave an accurate description of what Github is. Many tried nicely explaining this to OP. Using an analogy, I explained that GitHub is like a kitchen where recipes are created, not a restaurant serving ready meals. I emphasized that many tools, especially enterprise software, require command-line interface (CLI) setups because of the industry’s reliance on diverse Linux environments.
For the defenders, the issue was not GitHub’s design but a lack of user knowledge. They pointed out that GitHub serves its target audience effectively, and misunderstanding its role reflects a gap in expectations, not a platform flaw.
Note to learners, do not pushback against valid critique with personal attacks. As in this case, OP and their (sole) supporter dismissed clarifications as condescending and proceeded to use insults. These exchanges overshadowed any meaningful points and demonstrated an unwillingness to engage constructively.
Later, OP claimed their frustration stemmed from being "bullied" on GitHub for not understanding the platform but then shifted focus to blame the community's behavior, stating the issue was about developers needing to “check themselves.” However, based on OP’s behavior in his post at the simplest form of redirection, I am not inclined to believe that. Ultimately, their arguments showed misunderstanding, poor communication, and resistance to learning, derailing the conversation from its core technical and cultural concerns.
FOSS Misconceptions
Many users misunderstand Free and Open Source Software (FOSS) and platforms like GitHub, expecting them to cater to non-technical users. A commenter compared GitHub to a restaurant serving ready-made meals:
"No, we understand the analogy—it’s just that you don’t understand that people do use GitHub like a restaurant."
Treating Github as an app store leads to misplaced expectations and shifts responsibility unfairly. Key areas of misunderstanding include:
- CLI vs. GUI: Some users favor graphical interfaces over command-line tools, saying:"Is it really that impossible to understand that what comes easily or naturally for you is actually a pain and that there are a lot of things which are vastly simplified by a GUI?"
While GUIs can simplify tasks, many FOSS and enterprise tools require command-line interfaces (CLIs) for essential setup—not to create difficulty but because they're necessary for flexibility and functionality.
- Technical Trade-Offs: The preference for GUIs overlooks the trade-offs involved. CLIs often offer more control and are essential for certain operations, especially in diverse environments.
- Enterprise vs. Non-Enterprise Software: Some dismiss the need for CLI in non-enterprise contexts:"You also keep talking about enterprise solutions when frankly the FOSS toxicity described by OP is found among people working on software for Mac and Windows and where the CLI isn’t even necessary."
This ignores that many non-enterprise solutions also require CLI use due to their complexity or the customization they offer. Complaining about installation because of needed CLI use just comes off as lazy, at the least. Understanding these technical aspects is crucial. Both developers and users share responsibility:
- Developers can improve documentation and usability where feasible.
- Users should engage with the technical aspects and make an effort to understand the platforms.
Community Culture
Claims of a universally "toxic culture" in FOSS communities lack nuance. One commenter stated:
"The FOSS toxicity described by OP is found among people working on software for Mac and Windows and where the CLI isn’t even necessary."
While some technical communities can be unwelcoming, many developers provide support and documentation. Miscommunication often escalates due to personal attacks, hindering constructive dialogue:
- Examples of escalating tensions include remarks like:"Do you know how dense marble is?""I hate the culture, of which you are a great example, of being unable to take criticism."
Who’s Ultimately Right?
The defenders of GitHub and FOSS have the stronger argument in this case. Expecting GitHub to function as a polished software distribution site misunderstands its role in the software ecosystem. As the mod succinctly states:
“The problem isn’t with GitHub. GitHub knows what it is and it’s very good at serving its target audience.”
That said, although he’s very brutish, the OP’s frustration raises a valid secondary point: non-technical users often stumble into GitHub due to poor guidance or unclear documentation. It’s a shared responsibility. However, the OP undermines their position by refusing to engage constructively, doubling down on their complaints instead of seeking solutions.
Let’s break down real quick what things the OP and his supporting commenter get twisted about how GitHub and software distribution actually work
1. What GitHub Is (and Isn’t)
GitHub is more like a workshop where developers share their tools, not a showroom for polished products.
2. Open Source ≠ Plug-and-Play
Not everything on GitHub is built for non-technical users. A lot of projects are development tools, libraries, or proofs of concept—not consumer-ready apps. You’re not always going to find a one-click installer here.
3. Developers Set the Rules
How software is packaged and distributed is up to the developers, not GitHub. They might share installation files through GitHub, but more often, you’ll find those on their websites, package managers, or other dedicated download hubs.
4. Misreading GitHub’s Features
GitHub does have tools to help distribute software: the releases section, README files, and documentation. The problem isn’t the platform.
5. Community Dynamics
Calling help “dev-splaining” can miss the point. Tech folks may explain things in a straightforward way that sounds blunt, but it’s often just an attempt to answer the question. Not every interaction is wrapped in warm fuzzies, but that doesn’t mean it’s dismissive.
6. Blaming the Wrong Thing
Criticizing GitHub for not being user-friendly to non-devs is like knocking a wrench for not being a drill. It does what it’s supposed to for its target audience. Developers aren’t obligated to tailor everything to beginners.
GitHub serves its intended purpose. The defenders were right to push back against the OP’s demands. Gatekeeping and condescending exists in tech, but this was NOT a case of that. If you’re learning in tech, come with an open mind.
So in closing, what did we learn?
I believe the better question is what SHOULD we learn? Let me be real with you: labeling every explanation as “devsplaining” isn’t helping your case, especially when the people explaining GitHub’s purpose are just clarifying what the platform is and how it works. If you don’t want to learn how to navigate GitHub or install tools, that’s okay—it’s not for everyone. But blaming the developer community at large for your frustration is misdirected energy.
If you're not interested in learning how to use these tools, consider seeking software from official websites, package managers, or marketplaces, even if it means paying for it. Complaining that GitHub doesn't cater to non-developers misses its intended purpose.
Git itself, where Github is derived from, is Open Source software. Open source started as a playground for devs—sharing code and tinkering away. Now, with tech everywhere, non-tech folks are stepping in expecting everything to be plug-and-play. But these projects are often raw and unpolished, leading to frustrated users and stretched-thin developers. Finding that sweet spot is tough. Developers need powerful tools without the fluff, while users want simplicity and ease. Some projects are stepping up with slick interfaces, but not everyone has the time or crew to make it happen.
Low-code/No-code is now becoming a thing, and solutions like Harpoon simplify Kubernetes deployment for those looking to bypass the CLI. Co-Pilot is being integrated into many tools, and is catered to help those who have little coding proficiency. However, for that increased functionality from your FOSS software, you are going to need to learn more. This is where education and community come in. Devs can bridge gaps with better docs and quick-start guides, and users need to be down to learn a bit. When the vets help the newbies, everyone levels up.
In this case, the issue isn't the community but the mismatch between a user's expectations and what GitHub offers. Developers are often willing to help if approached with an open mind. If you're unwilling to engage or learn, that's cool, but it's not the responsibility of developers or GitHub to accommodate that. Meeting the platform on its terms is more productive than criticizing what it isn't.
Github is like playing Dark Souls. You can’t change the difficulty and it’s not easy, so if you want to enjoy your experience, you have to git gud. The resources are out there, most of them free.
