22 ms·

Open source can't coordinate?

• jaybro867 1y ago
  [dead]
• davidgerard 1y ago
  Fake title - original does not contain a question mark
• AStonesThrow 1y ago
  [dead]
• deleted 1y ago
  [deleted]
• TechPlasma 1y ago
  This feels very right. The problem is there are few entities invested enough in Linux as a consumer platform, that have the motivation to push things forward. To make the decisions on what their "Reference" system is. Valve is maybe the closest?
  • hackyhacky 1y ago
    Ubuntu, for all their faults, were the first to make Linux really easy to install and made it "just work." That counts for a lot. Since then, their output has been disappointing. Part of the problem, is that "Linux/Unix culture" is very averse to coordination. When someone does try to establish a common baseline, there is inevitable pushback. The classic example is systemd, which fills a desperately needed hole in the Linux ecosystem, but is to this day criticized for being antithetical to the ethos of, I guess, gluing together an operating system with chewing gum and bits of string. The fact is that many users would rather have a pile of software that can be hand-assembled into an OS, instead of an actual cohesive, consistent platform. So I can't blame people too much for not trying to establish standards. If OSS had created LSP, there would be 20 different incompatible variations, and they would insist "We like it this way." EDIT: averse, not adverse
    • Joel_Mckay 1y ago
      Indeed, "good" doesn't matter if the OS is a pain to use. The Driver support issues are essentially a theological war between FOSS ideals, and mystery OEM binaries. Most of the linux kernel code is still the driver modules, and board support packages. The desktop options have always been a mess of forks and bodged applets to make it useful. Ubuntu balances the purity of Debian with practical user experience (we could all write a book about UEFI shenanigans.) RedHat focuses more on hardened server use-cases. Is it worse than Win11 ? depends what you are doing, and what people consider is the low bar for messing with users. =3
    • clipsy 1y ago
      > The classic example is systemd, which fills a desperately needed hole in the Linux ecosystem If the hole is desperately needed, why would you want to fill it?
      • hackyhacky 1y ago
        > If the hole is desperately needed, why would you want to fill it? Good point. Let me rephrase: "Systemd fills a hole in the Linux ecosystem, which desperately needs to be filled." This version of the sentence is more correct and conveniently functions as a double entendre.
        • j16sdiz 1y ago
          systemd killed many projects and use cases along its way. Better integration for mainstream, sure. but at the end we have less choice.
          • hackyhacky 1y ago
            > but at the end we have less choice. This is exactly my point: you want "diverse choices", which is fundamentally at odds with "cohesive functionality." The article is about LSP, an imperfect standard, but nevertheless a standard. The prioritization of "choice" above all else is why the OSS world is incapable of creating standards. > systemd killed many projects The purpose of software is to fulfill a need. Creation of software projects is simply a side-effect of that process. It's good that systemd killed many projects, because those people who had worked on those projects can now work on a problem that hasn't already been solved.
  • charcircuit 1y ago
    Google is the closest with Android. They were even able to get Adobe to port photoshop which other Linux operating systems have failed to have happen. Despite Android's success the rest of the consumer Linux distributions chose to ignore it and continue on with what they were already doing. Trying to have them coordinate around what is succeeding is seemingly impossible.
    • hackyhacky 1y ago
      > Despite Android's success the rest of the consumer Linux distributions chose to ignore it and continue on with what they were already doing. Trying to have them coordinate around what is succeeding is seemingly impossible. I'm not sure I understand you here. What do you think other Linux distros should have done?
      • charcircuit 1y ago
        >What do you think other Linux distros should have done? Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with.
        • hackyhacky 1y ago
          > Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with. As a common target, AOSP isn't a very good one. AOSP ran on desktops. (Maybe it still does, haven't tried it in a while.) It was still a mobile OS, though, so it wasn't good on the desktop, but it ran. It also uses very old kernels. Other than the kernel, the Android UI is completely different from conventional Linux. Any Gnome or Qt app would have to be completely rewritten to support it, and would probably have to run in the JVM. Basically, if the Linux community followed your plan, they would have to commit a huge effort to port everything to what is essentially a completely different, incompatible OS in every respect except the kernel, and their reward would be to live in subservience to the whims of Google in supporting their product which Google themselves never had enough faith in to make it a proper desktop OS. It seems that the benefit does not justify the investment.
  • keyringlight 1y ago
    Valve doesn't seem interested in doing much on the desktop, they seem to have constrained themselves (probably wisely) to working on areas directly related to their business and products.
• mongol 1y ago
  > But there was no one to coordinate Linux on desktop. Freedesktop.org?
  • wmf 1y ago
    I get the impression that some people don't want to participate in FreeDesktop. Maybe they see it as bloated or too aligned with GNOME.
  • freeone3000 1y ago
    I’m still mad they stole the scriptable, composable DCOP and put it all behind a binary format.
    • LtWorf 1y ago
      whatever happened with kdbus btw?
      • deleted 1y ago
        [deleted]
  • dwheeler 1y ago
    Yes. GNOME and KDE at least coordinate via freedesktop.org. At least they did!
  • hackernoops 1y ago
    [flagged]
    • bilkow 1y ago
      I got curious and found a ton of red flags in about half hour... Summary of the drama that resulted in Xlibre: - https://discuss.pixls.us/t/weekly-recap-8-june-2025/50638 https://discuss.pixls.us/t/weekly-recap-8-june-2025/50638 From the README at https://github.com/X11Libre/xserver https://github.com/X11Libre/xserver: > This is an independent project, not at all affiliated with BigTech or any of their subsidiaries or tax evasion tools, nor any political activists groups, state actors, etc. It's explicitly free of any "DEI" or similar discriminatory policies. Anybody who's treating others nicely is welcomed. This exchange between him and Torvalds in 2021: - https://lkml.org/lkml/2021/6/10/903 https://lkml.org/lkml/2021/6/10/903 - https://lkml.org/lkml/2021/6/10/957 https://lkml.org/lkml/2021/6/10/957
• taeric 1y ago
  I'm not entirely clear why/how this is an open source issue? My assertion: Inertia of user base is by far the largest predictor of what will stick in a market. If you can create a critical mass of users, then you will get a more uniform set of solutions. For fun, look into bicycles and how standardized (or, increasingly not) they are. Is there a solid technical reason for multiple ways to make shoes that connect to pedals? Why are there several ways to shift from your handlebars? With the popularity of disk brakes, why don't we have a standard size for pads? I think there are a lot of things that we tell ourselves won from some sort of technical reasoning. The more you learn of things, the less this seems true, though. Not, btw, that there aren't some things that die due to technical progress.
  • dkkergoog 1y ago
    All those things have s price point
  • skydhash 1y ago
    > I'm not entirely clear why/how this is an open source issue? I think it's not even an issue. Most open source projects are implementations (maybe flawed), and few are new propositions. If something was not fully defined in the standard/protocol/interface, the implementation may come up with its own extensions that are incompatible with others. But that's how you choose implementations, you're supposed to commit to one and not use a mismatch. So if you're using GNOME, try not to depend on something that depends on having the whole KDE installed. If you're using OpenRC, anything systemd is prohibited. All projects are consistent within themselves, the only thing you need to do is to avoid conflicts by having two things doing the same job and to ollow the installed system guidelines. I don't mind fragmentation. What I mind is dependency due to laziness and not a real need (like using a couple of glibc specific library for no real reason just because you're working on Debian) or taking the time to support windows and macos, but tying yourself to glibc on Linux because reasons.
    • LtWorf 1y ago
      In my experience most people who want to avoid the glibc do so because they disagree with the values of free software. After this premise, can you explain to me why I should waste my time to help them? Let's not forget that we are talking about open source software and they could fix it themselves if they so desire.
• deleted 1y ago
  [deleted]
• xpe 1y ago
  Apple coordinates internally, since macOS works with Apple hardware. Windows can drive coordination among hardware vendors. In the Linux world, many organizations and projects share power; there is not the same focal power on having a consistent end user OS (dependencies, configuration). Declarative and deterministic build systems at the OS level allow different groups to package their subcomponents reliably. As various configurations get socialized, it gives choice to tradeoff between customization and popularity/vetting.
• dkdcio 1y ago
  https://github.com/pandas-dev/pandas/pull/58623 https://github.com/pandas-dev/pandas/pull/58623
• dcreater 1y ago
  Solving the coordination problem in FOSS is one of the grand challenges of humanity. If we solve it, I think it will effect a tectonic shift with far reaching implications and fixes major socioeconomic problems like wealth concentration. Eg: a FOSS alternative to Visa, and of course Windows/MS Office.
  • yencabulator 1y ago
    > FOSS alternative to Visa Software, or lack there of, is not the reason for Visa/Mastercard ruling the marketplace.
    • dcreater 1y ago
      What is? I agree that there is a lot more to this industry than software but that is the first foundational/enabling piece. They may have a duopoly currently but its a matter of when, not if, that it is broken
      • yencabulator 1y ago
        If Visa loses its position, it'll be replaced by something fairly similar. It serves the interests of the system. Why? Unchecked capitalism, lobbying, corruption, politics, societal needs[1], realpolitik[2]. [1]: E.g. legal system requiring KYC to investigate money laundering. [2]: In the positive sense; see items 2-4 for the negative sense.
• muglug 1y ago
  Ehh I don't buy that the market was ready 10 years earlier (in 2006) for open-source LSP implementations. You gotta have someone write those language servers for free, and the language servers have to be performant. In 2006 that meant writing in a compiled language, which meant that anyone creating a language server for an interpreted language would need to be an expert in two languages. That was already a small pool of people. And big multiplayer OSS platforms like GitHub didn't exist until 2008.
  • skydhash 1y ago
    And the fact is that anyone working professionally was using an IDE, and anyone else was fine with grepping and using ctags. I think LSP is only truly useful in two contexts, global symbols (even with namespacing) and confusing imports. In language like C, you mostly have a few structs and functions, and for the ones in libraries, you only need to include a single header. With Python, the imports are concise and a good references gives you the symbol identifier. But with languages that needs an IDE or LSP, you find yourself dealing with many imports and many identifiers to write a few lines of code and it becomes quickly unmanageable if you don't have completion or autoimports.
  • autarch 1y ago
    > And big multiplayer OSS platforms like GitHub didn't exist until 2008. SourceForge launched in 1999. I think GitHub is better in many ways, but the basic building blocks of hosted repo, issue tracking, and discussions (via email lists) on Sourceforge. I collaborated with folks on a number of projects on SourceForge way back when.
• initramfs 1y ago
  I think the definition of linux is much broader than what is considered today a platform for the IDE. It's kind of like the IDE is the cart, and the kernel is the horse, but 30 years later, linux is an engine with a cabin virtual machine, rather than a desktop per se. the parts interact at a different level now.
• tbrownaw 1y ago
  > The underlying force there is the absence of one unified baseline set of APIs for writing desktop programs. It's called the Common Desktop Environment.
  • skydhash 1y ago
    Most desktop programs don't need to rely on a DE (apart from some utilities). If Emacs can run anywhere, your programs can too. GTK or QT is more than enough. For anything else, you go with components on a needed basis, and they should preferably be desktop independent.
    • hackyhacky 1y ago
      > If Emacs can run anywhere Any desktop program needs to be programmed against some API. In the case of Emacs, it's probably raw Xlib or a wrapper library on top of it. The problem with that is that (a) your dependency on X11, which is obsolete and has many documented inadequacies, (b) the lack of a modern widget library and toolkit makes extra, unnecessary work for the programmer, and (c) the lack of a cohesive visual language between programs makes the experience worse for the user. Toolkits like GTK and Qt solve all these problems. By avoiding them, you're just reinventing the wheel, poorly, every time.
      • skydhash 1y ago
        Emacs has a GTK3 layer (among others) for its UI.
      • dragandj 1y ago
        Emacs was there way before GTK and Qt appeared, though.
        • hackyhacky 1y ago
          > Emacs was there way before GTK and Qt appeared, though. So your point is that we should use older technology even when it's been surpassed by better alternatives?
• UltraSane 1y ago
  I was truly shocked at how bad the experience is when you are using and RPM based distribution and a program is only available as a DEB
  • udev4096 1y ago
    There is rpm-to-deb converter which works sometimes. Most of the modern projects include an AppImage these days, which is distro agnostic and only requires fuse to be installed
  • mroche 1y ago
    Tools like Flatpak, AppImage, Snap, Toolbox, and Distrobox can go a long way on relieving the end-user of the burden of trying to get things playing nice in those situations. Not always a silver bullet, but a useful tool to keep in the back pocket. If it's FOSS, at least you have the option of trying to repackage it for your distribution. You're SOL if it's a proprietary application distributed in binary format. , though.
    • UltraSane 1y ago
      It was the Termius SSH Client
    • shadowgovt 1y ago
      Something I don't yet understand about flatpak et al: isn't using that for every app in the core OS experience going to chew through storage because shared libraries can't be shared across images? Or does the containerization solve that problem?
      • UltraSane 1y ago
        Modern storage is at least hundreds of time bigger than when shared libraries were common to save space. Every single executable having its own copy of GNU C Library isn't a big deal.
        • 1y ago
• RossBencina 1y ago
  Who is being incentivised to reduce the friction of interoperation? Coordination is hard. People who are good at coordinating are not necessarily the same people who are happy to contribute their time to FOSS. And FOSS may need to coordinate in ways that vertically integrated companies do not. Coordinating between loosely aggregated volunteer projects is not the same as coordinating between vested stakeholders either. I would guess that most FOSS projects are more invested in their own survival than in some larger objective. Teams within a company are (presumably) by definition invested in seeing the company mission succeed. The GNOME / KDE example mentioned elsewhere in this thread is interesting because these are two somewhat equivalent co-existing projects. Any coordination between them is surely not their highest priority. Same with all of the different distros. The each exist to solve a problem, as the fine article says. I wonder how much the problem is actually "open source can't standardise on a single solution." Let one thousand flowers bloom, sure. But don't expect a homogeneous user experience. The great thing about standards is there are so many to choose from. xkcd 927. etc.
• colesantiago 1y ago
  I would love to tell people about linux for their desktops, but the main issue I have with it is the fact that people who are interested in it ask me one question regarding Linux distributions: “Which one?” This is pretty much the cause of a 90% drop off of interest in Linux on the desktop. I could say use Ubuntu (and I do) to some of the people who I’m close with that are interested in Linux, but they discover Lubuntu, or Linux Mint and Debian, then they get easily confused and give up. And that is not even getting into the updates and the packaging and heaven forbid anything breaks.
  • udev4096 1y ago
    There aren't that many to ponder over the idea of recommending someone for a daily use. For beginners, Fedora is the perfect choice. For people with programming background, Arch. Ubuntu was sane sometime ago, not anymore because of the bloat it ships by default
    • int_19h 1y ago
      > For beginners, Fedora is the perfect choice. Last time I tried another round of "let's install the most recent versions of popular distros on random laptops I have", Fedora was the most finicky about hardware. As in literally wouldn't even boot into live CD on one of said laptops, and had troubles with graphics on others. The thing that worked every time? For the past decade or so, it had consistently been Linux Mint for me.
  • Milpotel 1y ago
    > And that is not even getting into the updates and the packaging and heaven forbid anything breaks. How to spot the Ubuntu user...
    • imp0cat 1y ago
      And lead him to Nix? :) And then watch his eyes glaze over as he realizes that he's bitten off a lot more than he can chew. :D
• shadowgovt 1y ago
  I am reminded of someone I read recently decrying as a loss GNOME adopting systemd components as a critical dependency because they want alternatives to systemd. ... and this a layer of open source flexibility I never wanted. I don't want alternatives to core system management; I want one correct answer that is rugged, robust, well-tested, and standardized so that I don't have to play the "How is this service configured atop this service manager" game.
  • rjsw 1y ago
    GNOME started out being able to run on more than just Linux.
    • shadowgovt 1y ago
      That makes sense and I can see how it'd be frustrating to someone if it can't anymore. But how relevant is that today when there are enough flavors of Linux that you can install it on anything from space probes to toaster ovens?
• udev4096 1y ago
  What? How is this even at top? Some no-name program is not getting an update or is not perfectly installable and suddenly it's an open source problem? Stop being an entitled prick
• fr4nkr 1y ago
  The OP defeats his own argument. LSP was a collaborative effort that benefited from a degree of coordination that only hierarchical organizations can provide, yet it still sucks ass. OP blames FOSS for not providing an IDE protocol a decade earlier, but doesn't ask the rather obvious question of why language-specific tooling is not only still around, but as market-viable as ever. I'd argue it's because what LSP tries to do is just stupid to begin with, or at least exceptionally hard to get right. All of the best language tooling I've used is ad-hoc and tailored to the specific strengths of a single language. LSP makes the same mistake Microsoft made with UWP: trying to cram the same peg into every hole. Meanwhile, Microsoft still develops their proprietary Intellisense stuff because it actually works. They competed with themselves and won. (Minor edit: I forgot that MS alone didn't standardize LSP.)
  • deleted 1y ago
    [deleted]
  • diegoperini 1y ago
    > yet the end result was complete shit Could you elaborate why? It looks like a useful protocol.
    • fr4nkr 1y ago
      I elaborated a bit when I edited my post, but to be more specific, I think LSP is a protocol that fails at its stated goals. Every server is buggy as hell and has its own quirks and behaviors, so editors that implement LSP have to add workarounds for every server, which renders the point of LSP moot. It's the worst of both worlds: editors are still duplicating effort, but with fewer, if any of the benefits of tools tailor-made for a specific editor-language combination. And that's not even touching on the protocol's severe performance issues. Unsurprisingly, the vast majority of servers work much better with VSCode than other editors. Whether this was a deliberate attempt by Microsoft to EEE their own product, or simply a convenient result of their own incompetence, is ambiguous.
      • RossBencina 1y ago
• ninjin 1y ago
  "The reason why we have Linux, and BSDs, and XNU is that they all provide the same baseline API, which was defined from the outside [by POSIX]. The coordination problem was pre-solved, and what remained is just filling-in the implementation." But that is not at all how Posix operates or has operated. Posix standardises common denominators between existing implementations. The fact that we now have strlcpy(3) and strlcat(3) in Posix 2024, is not because Posix designed and stipulated them. Rather, they appeared in OpenBSD in 1998, were found useful by other *nix-es over time, spread, and were finally taken aboard by Posix that standardised what was already out there and being used! This to me is the very opposite of the point the author is trying to make!
  • maccard 1y ago
    Actually I think this is exactly the point. BSD got them in 1998, it took 17 years for it to go to posix and another 8 years before they made their way to glibc. 25 years to add a clear improvement
    • geysersam 1y ago
      Guess not everybody though it was a clear improvement then? It's not like it made everyone adopt BSD instead of Linux. If it was easy to make all the right decisions someone would have made them and sold it as a product instead
      • maccard 1y ago
        https://xkcd.com/1172/ https://xkcd.com/1172/
      • collingreen 1y ago
        Even if profit isn't involved this entire op argument seems really weird to me. It seems exceptionally entitled and also myopic? Somehow the author wants the good (??), popular (??) open source projects (made of thousands and thousands of opinionated decisions, many aesthetic and not "rational") to decide to cooperate and suddenly share opinions and aesthetic (while simultaneously maintaining the unique opinions and aesthetic that made the project popular in the first place?). The whole thing feels a lot like consumers demanding even more from open source maintainers and continuing to pay nothing.
• a-dub 1y ago
  idk. i don't really follow the argument. large projects in open source coordinate internally and engage externally when they need to- i suspect that isn't all that different from what you'd see in a large megacompany like apple or microsoft. open source people create reusable interfaces. i'd argue they go one step further and create open and public internet communities with standards, practices and distribution/release channels.
• bobajeff 1y ago
  Maybe open source doesn't need to coordinate. Perhaps users and developers should demand standards and interoperability from their platforms. Perhaps that's why we have things like Electron, Unreal Engine and Unity. One way or another we'll coordinate on something.
• deleted 1y ago
  [deleted]
• antonok 1y ago
  Open source has the best kind of coordination. If there's a real use-case for two things to work together, you or someone else can implement it and share it without anyone's permission. Meanwhile in proprietary land, people sometimes build things that nobody wanted, and also leave out features with high demand. Proprietary optimizes for the profit of some individuals; open source optimizes for maximum utility. Thus far, open source has optimized for maximum utility for individuals who can write code... but AI may be changing that soon enough.
  • illiac786 1y ago
    I am a fan of open source, but it’s definitely not for the coordination part. Proprietary, money driven development, is top down and has coordination in general. In very large software, it starts failing sometimes (I’m looking at you Oracle) Open source handles conflict by forking. I wouldn’t call that good coordination. But, at the same time, I don’t see a better (or less worse) solution so I shut up and I take their code =)
    • latchup 1y ago
      > Open source handles conflict by forking. I wouldn’t call that good coordination. Forking is far from the first step in conflict resolution; it is the ultima ratio between projects in the open-source world, when all dialogue breaks down. In other words, the worst outcome is that people agree to disagree and go their separate ways, which is arguably as good a solution as is possible. In the corporate world, coordination mostly exists within companies through top-down decision-making, as you said. Between them, however, things look much grimmer. Legal action is often taken lightly, and more often than not, a core business goal is to not just dominate, but to annihilate the competition by driving them out of business. Coordination between corporations, such as through consortia, is only ever found if everyone involved stands to profit significantly and risks are low. And ironically, when it does happen, it often takes the form of shared development of an open-source project, to eliminate the perceived risk of being shafted.
      • aleph_minus_one 1y ago
• throwaway2037 1y ago
  > But then, how can Linux exist? How does that square with “never break the user space?” Hot take: This catch phrase is out of date. For Linux desktop normies like me who don't really care about the stability of the Linux user space API, user space does break when GUI libraries (and the myriad of libraries dependencies) change their APIs. For example, I mostly use KDE, which depends upon Qt libraries for its GUI. Qt regularly introduces breaking changes to their API during each version increment: 4->5->6, etc. (I don't hate them for it; it is normally carefully done and well-documented.)
  • LtWorf 1y ago
    Kernel breaks API all the time too. It applies only if something that linus personally uses stops working.
    • LtWorf 1y ago
      Funny that I'm getting downvoted after having spent hours investigating a failure due to kernel breaking API a couple of weeks ago :) I guess y'all know better :)
      • Gracana 1y ago
        Why did you write a comment inviting downvotes when you could have told that story instead?
        • LtWorf 1y ago
          Why do people presume there isn't a story? Like I'm just making up stuff?
  • vhantz 1y ago
    "don't break user space" is about the Linux kernel not breaking user space. Qt is user space as well as any desktop environment or GUI framework. Introducing breaking changes with major version releases is standard software development practice. Very few projects go out of their way to always keep backwards compatibility.
• pacoxu2025 1y ago
  but open source foundation provide some guides/events/programs to coordinate.
• deleted 1y ago
  [deleted]
• bronlund 1y ago
  This is kind of the same reason I gave up on the Linux desktop and went for macOS. When I first learned about Linux I was thinking "Sweet!. This is going to kick Microsoft's ass!", but this was 30 years ago and instead of a kickass desktop OS, we got 1000 mediocre ones.
  • happymellon 1y ago
    > looks at Windows Vista, 8, 10, 11 I don't think its the mediocre interface thats holding Linux back... Whether its the abomination thats Windows 11, having to fight against an ad ridden interface in 10 or otherwise. Teams hasn't dominated because of a coherent interface, or even because anyone actually wants to use it. Besides, you say 1000 desktops, but there is really only 2 (well 1 since Gnome is the primary interface for the big 3 distros) along with couple of hobby ones that you have to seek out to even learn they exist and a lot of toys that no one outside HN has even heard of.
    • IshKebab 1y ago
      Windows 10 and 11 have great desktops. Definitely still ahead of anything Linux can offer. But I agree it's only partly because of that. The bigger issues are poor hardware support (especially for laptops) and over reliance on the CLI and config files.
      • happymellon 1y ago
        > Windows 10 and 11 have great desktops. We will have to just agree to disagree on that one. Windows 10 reverted back to a warmed over 7, but with flashy boxes to add noise, and the injection of adverts over time. The multi-desktop implementation was half baked, and when applications request focus you can end up with an unresponsive desktop until you find it. 11 is an interface that only a mother could love. Pointless changes like centering the bar make me wonder if you ever used it. It's a step back in every way, but without a guts to try something different like 8. 8 didn't work for laptops/desktops, but at least there was an attempt.
• cadamsdotcom 1y ago
  To me it's about how low-bandwidth communication channels limit collaboration. Linux and FOSS grew up (congrats!) and the important work got super big and complex. Unfortunately, online communication - typically the channel preferred by FOSS projects - has much lower bandwidth than teams working full time in an office. Thus limiting the "depth" of collaboration. It's not all bad. FOSS does have some profound success to be proud of. For small and well-defined projects "benevolent dictator for life" works! Anything one person can lead - a desktop tool or a library - FOSS produces really good outcomes. But above say, a package manager or a distro.. things get wonky. Again it's not all bad. FOSS is rolling up its sleeves. Folks are organically doing the "go down every avenue people are motivated to go down" thing. You could call it Darwinism. But many motivated communities lack resources to go far enough to reach value. Motivation stalls during projects (we're human!), and FOSS rarely comes with a motivation-boosting paycheck. Plenty of valiant efforts don't reach value and it's never malicious. It's OK! So is there a way to better concentrate efforts? If the paths are long, it follows that the community should tackle fewer paths. The path(s) taken should be well defined, charted in advance as much as possible, and not uncovered bit by bit - or the work will take decades. Growing an entire ecosystem around one path forward (or a few) requires alignment. Can enough trust be fostered in leaders to get people to work on a shared vision? A vision of what Linux on the desktop should/could converge to is the kind of problem that, if Linux were a company, would be bet-the-company strategic. A company can't afford to go down two paths. So it might lock its smartest people in a room to hash out one true strategy. Or have one smart person dictate one vision and align everyone on it. Can that be done for FOSS? In the bounds of a single project it has been proven that it can. But what about an entire ecosystem?
  • nottorp 1y ago
    > Unfortunately, online communication - typically the channel preferred by FOSS projects - has much lower bandwidth than teams working full time in an office. I wonder if that's why open source projects get so much done and at such a high quality with so few people. Instead of 75% "communication" and 25% work, 90% of the time donated to FOSS is actual work :)
  • candiddevmike 1y ago
    > Unfortunately, online communication - typically the channel preferred by FOSS projects - has much lower bandwidth than teams working full time in an office. Thus limiting the "depth" of collaboration. Source on this? There are tons of collaborative, 100% remote companies out there (and they release open source software). I think your assertion may be more the folks aren't as dedicated to open source as contributing is a part time or hobby thing.
• ashoeafoot 1y ago
  The selection and standardisation comitee for open source is the usage data. Make public what is used where under what circumstances, standards emerge .
• scrapheap 1y ago
  Alternative view - Open Source projects have the freedom to do what they want to do. Which in turn gives me the freedom to choose how I set up my desktop environment. How many changes have been pushed on Windows users over the last 15 years with the only option being to change and get security updates or stay on an old insecure version? And while there are lots of desktop environments for Linux you can usually run applications targeting one in any of them (I use Gnome's file manager in Enlightenment as it supports accessing CIFS shares directly).
  • reactcore 1y ago
    Agreed. I have been thinking about this since the announcement of iOS and macOS 26. I really dislike the UI changes made and will not upgrade until my devices become obsolete. On my openSUSE PC, my desktop still looks almost the same as it did in 2006, which I love so much.
• amelius 1y ago
  Yet most closed source stuff depends heavily on open source.
• amelius 1y ago
  We need more people writing RFC style documents.
• mike_hearn 1y ago
  Many moons ago Scott Alexander wrote a critique of Marx. It starts by arguing that if capitalists can be said to produce anything, it's coordination. Coordination, Scott argues, is a thing every bit as real as coal or food or legal services. People need to manufacture it, and we call them executives/investors/marketing staff, and others want to buy it. When we buy coordination we call it brand value or similar. Open source has a notable absence of coordinators, because producing coordination is hard and non-fun, so without a capitalist market there's not much incentive to do it. Same reason desktop Linux historically struggled with anything that wasn't hobby programming (art, UI design, etc... eventually Red Hat and others hired such people using server profits). The Linux kernel and GNU in general are projects that hacked around that problem by just copying the decisions of other people who were coordinated by capitalists (UNIX vendors), which worked long enough to bootstrap the ecosystem until some of the key people could be coordinated by Red Hat and others who monetized indirectly. But at every stage, the coordination was being produced by capitalists even though it was hard to see. In other places where the mimic-and-support model didn't work, open source really struggled. This is most obvious on the desktop. Even there, ultimately this approach has been adopted for large chunks of it. If you play games on Linux today it's because people copied the Win32 API i.e. the coordination was produced by capitalists like Bill Gates. Now Alex mentions LSP and JetBrains. The reason JetBrains didn't do the LSP isn't because of value capture. After all, IntelliJ has been open source for a long time. Other IDEs could easily have embedded it and used its plugins. The reason JetBrains use a Java API is because it's a lot more productive and effective to design in-process APIs than network protocols. As long as you aren't crossing runtime boundaries they're easier to write, easier to test, easier to reason about statically (especially w.r.t. concurrency), and much more performant. You can exchange complex object graphs in a shared address space and coordinate them using locks. All this is a highly effective way to extend an IDE. Microsoft did the LSP because they took a bunch of energetic developers who only wanted to do web development, so they used Electron. Also for reasons of sticking with the crowd, .NET being pretty useless for cross-platform desktop stuff... it's not just that experience with desktop programming is fading away. But browsers were never designed for the challenges of large scale desktop programming, in fact they weren't designed for building apps at all. So they don't let you use threads, static typing via TypeScript is an aftermarket hack, V8 has very low maximum heap sizes, and there are many other challenges with doing a clean JetBrains style architecture. To their credit, the VS Code team leaned into the architectural limits of the browser and did their best to turn it into advantages. They introduced this notion of a backend that could run independently of the frontend using a 'standard' protocol. This is technically not really different to the IntelliJ API being open source, but people like the idea of protocols more than embedding a JVM and using stuff in a company-specific namespace, so that created a lot of community good will and excitement for them at the cost of many technical challenges. Those challenges are why JetBrains only use the LSP style approach for one of their IDEs, which due to historical reasons doesn't share the same architectural approach as all the others. And it's also why, if you look at the Rider protocol, it's some fairly advanced state sync protocol thing, it's not a plain old HTTP RPC style protocol. Given that both are open source and both are produced by teams of paid developers working in an office coordinated by capitalists, it's probably not right to identify this as an open source vs proprietary difference. It's purely a technical one to do with JVM vs web as foundational platforms.
• simonebrunozzi 1y ago
  Key sentence here: > But it is also clear why JetBrains didn’t do LSP — why would they? While the right solution on the technical grounds, you aren’t going to get paid for being technically right.
• fergie 1y ago
  > There was a decade of opportunity for OSS to coordinate around an IDE protocol, but that didn’t happen, because OSS is bad at coordination. Its also because a lot of the key people in Open Source, and senior hackers generally, don't actually use IDEs. We should encourage more of the younger generation over to powerful configurable editors such as Emacs, rather than locking everybody into VSCode/JetBrains/etc.
  • tasuki 1y ago
    > We should encourage more of the younger generation over to powerful configurable editors such as Emacs, rather than locking everybody into VSCode/JetBrains/etc. Isn't that precisely what LSP facilitates? I was using IDEs for like four years. Now I'm back to (neo)vim and couldn't be happier! There is no substitute for "jump to definition".
    • yencabulator 1y ago
      Jump to definition was a common feature across editors in the early 90s. https://en.wikipedia.org/wiki/Ctags https://en.wikipedia.org/wiki/Ctags
• alganet 1y ago
  Must... make... cathedral... at... all... costs... why... no... cathedral... halp... http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html#catbmain http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral...
• deleted 1y ago
  [deleted]
• nixpulvis 1y ago
  This somewhat reminds me of arguments I've heard about waterfall vs agile over the years. Planning for ways to plan, and everything falling apart when faced with hard decisions and thick skulls.
• agumonkey 1y ago
  It's an important question. Paid enterprise enforce a certain level of coordination (supposedly overcoming the pain of dealing with people and ideas you don't necessary like). Open source imposes no such things, so efforts grow when and where they want..
• PaulHoule 1y ago
  Look at Microsoft Windows. You can still run Access '97 because all the DLLs with the GUI widgets from Win '95 are still there. Until 2012 or so, Microsoft would regularly come out with a whole new widget set every few years. You can see this most notably in the settings UI for Windows where there are some screens in the "modern" UI and plenty of dialogs that still come from the '95/NT 4 era. Since then Microsoft has had no real answer for "how do I write desktop applications for Windows?" other than "use Electron". (If they were still introducing new widget sets they'd be converting the 'modern' dialogs to something 'postmodern' while still having Win '95 dialogs in there)
  • LtWorf 1y ago
    None of my games from 15 years ago work.
  • Kranar 1y ago
    I decided to verify this and came up short. I went through the installation procedure which did work but required changing some workgroup settings and running the application as administrator... not ideal but understandable. However, when I tried to run it, no good. I get an error about missing files. I then went through the process of finding some of these missing files and installing them but ultimately ran up against the final fatal error that will not allow me to proceed. Access 97 depends on some Internet Explorer components and Microsoft has made it all but impossible to install Internet Explorer on the most recent Windows 10 and Window 11. Apart from that I also tried getting Minesweeper and SkiFree to work on Windows 10 and Windows 10 just straight up refuses to run them with the message "This app can't run on your PC."
    • PaulHoule 1y ago
      I installed Office ‘97 for work I think two summers ago. We had an old access database that I had to import into a new postgres-based system and it installed just fine on Windows 10. It was hilarious that clippy still tries to take over the desktop but it looks a little funny because borderless windows don’t work quite the same as they used to.
• bjourne 1y ago
  https://bugzilla.mozilla.org/show_bug.cgi?id=259356 https://bugzilla.mozilla.org/show_bug.cgi?id=259356 21 years old bug. XDG is such an obvious improvement, yet getting all projects on board is taking forever.
• jrm4 1y ago
  I think that that two of our more instructive examples here might be Wayland and late stage GNOME -- namely, how did these two projects get as big as they did, despite being both 1) past compatibility breaking and 2) not obviously good?
• pif 1y ago
  > There’s no single entity that can coordinate the API, in contrast to Windows and MacOS. > > But then, how can Linux exist? How does that square with “never break the user space?” The “never break the user space” philosophy is limited to the kernel, and the single entity coordinating that realm is called Linus.
• pif 1y ago
  This post displays the same ignorance as that joke about Kissinger complaining that Europe didn't have a phone number. Open source is a movement: it's neither an individual nor a committee. And people join it because it is a movement with no central authority.
  • IshKebab 1y ago
    That doesn't really refute the article's point though does it?
• margarina72 1y ago
  Seems to be a pattern - take a general then apply to open-source. You know what else can't coordinate - most of the corporate world. The article doesn't bring up any critical issue that the world world opensource should suddenly deal with - feels more like a morning rant after his shower - which is also how the post starts - it's basically on the front-page because its title is trying to be provocative.
• AmazingTurtle 1y ago
  Whats wrong with LSP?
• nyrikki 1y ago
  > I use NixOS. And NixOS isn’t a problem — it’s a solution. > The past ten years saw a big shift in how we are writing software: baseline level of “interactive static analysis" While I am making no judgement on what is 'better', the author's choices have impacts, and sometimes not all projects can work within the costs imposed by static analysis. For example, remember that Rice's theorm generalizes HALT, and that you always have to under or overestimate with SA. Either introducing over constraints or missing things. It is horses for courses, sometimes the added friction is worth it, other times it is damaging. The question of if Nix is a problem is a context specific question. Be careful about making default assumptions and patterns more than what they are, no matter how sensible they are as a default.
• badsectoracula 1y ago
  > I suspect that I have an outdated version of hotspot Linux profiler, but I can’t just go and download a fresh release from GitHub, because hotspot is a KDE app, and I use NixOS. KDE (not to be confused with the Plasma desktop) is just a bunch of C++ libraries that can work on a variety of desktop environments and even OSes (though Hotspot being a perf report alternative is clearly meant for use with Linux). I just went and downloaded the latest CI build from[0] and it ran just fine on my openSUSE Tumbleweed, running Xorg with Window Maker. I do have a bunch of KDE apps installed, like Kate (my currently preferred text editor), Dolphin (the file manager i use whenever i want thumbnails, usually for videos and images), Spectacle (for screenshots), Falkon (i use it as a "clean" browser to test out things), etc so i also do have the KDE libraries on my system, but that is just a `zypper install` away. Or an `apt-get install` or `pacman -S` or whatever package manager your distro uses, i've used a bunch of them and they all pretty much behaved the same. I'd expect Hotspot to be installable in the same way in any of them (and i'd expect the AppImage to have these libraries bundled in anyway so you probably wont need them[1]). If there are issues with NixOS (i don't know, i haven't tried it) i think it might actually be a NixOS issue and not a KDE issue. [0] https://github.com/KDAB/hotspot/releases/tag/continuous https://github.com/KDAB/hotspot/releases/tag/continuous [1] EDIT: i checked with --appimage-extract, it contains pretty much everything
• ozim 1y ago
  It is a feature not a bug. What author describes is about dominance. Most OSS is fragmented because of different ideas and different people. People nag about .NET not having much outside OSS because .NET devs (I am one of them) will not use stuff that doesn’t have MSFT badge. You don’t want such power in general OSS. Lack of coordination is sign of no dominant entity and that is the feature.
  • tester756 1y ago
    On the other hand how much time is wasted on reimplementing same/similar software X times.
• notepad0x90 1y ago
  I wonder if the author has seen codebases for enterprise apps that are a behemoth, designed by a committee with low developer retention. In contrast, open source software led by the same handful (typically just one guy) of people over years/decades are well coordinated by the BDFL(s) and have a clear direction. I think the term the author is looking for is "opinionated". The mantra is "if you don't like it fork it". The apparent lack of coordination is a feature of open source,not a bug. Successful and popular projects rarely seem uncoordinated. The Linux kernel coordinates thousands of devs over mailing lists. Git was created to facilitate that, and now everyone uses to coordinate development.I would even dare say modern dev coordination is spearheaded by open source projects.
• kragen 1y ago
  Open source, like private property, markets, science, and Satoshi consensus, enables people to benefit from the work of others that they don't have a means of coordinating with—for example, because they're dead, or they don't trust you, or they're hard to get along with. If you already have a way of coming to terms with somebody, you don't need open source. Different engineers inside Google can benefit from each other's work without making it open source because they're coordinated by Google's management. It's people who aren't coordinating with Google who benefit from them making it open source.
• jalapenos 1y ago
  Something uncoordinated struggles to co-ordinate. More news at ten
• dTal 1y ago
  @dang Why editorialize a question mark into titles like this? What does it signify? We are not talking about a factual assertion of debatable veracity, but a statement of opinion along the lines of "considered harmful". Disagreement and debate is the obvious expected result of such a statement. HN admin using special mod powers to editorialize a title which is neither misleading nor clickbait, simply to indicate skepticism, comes across as petty and not a little hypocritical in light of the "don't editorialize titles" site guideline.
  • dang 1y ago
    We add a question mark to titles that some commenters find questionable, in the hope that it will lead to fewer complaints about the title. Comments that react purely to titles are shallow, so we don't much want them here. I suppose the goal of nearly all the title edits we do, including this one, is to minimize them.