"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!
Linux would have had strlcpy/strlcat 25 years ago but the glibc maintainer was famously being a giant chode and refused to allow "horribly inefficient BSD crap" into his precious code, and this fight went on for years:
It's surprising how we ended up with such a robust open-source OS ecosystem (pretty much every server running Linux) with such emotional people at the helm.
He is clearly not being rational there, but I could see how his aesthetic tastes might correlate pretty well with robust software. I suppose that saying no to new features is a good default heuristic, these additions could have easily added more problems than they solve, and then you have more surface area to maintain.
That being said, this old-school ideology of maintainers dumping the full responsibility on the user for applying the API "properly" is rather unreasonable. It often sounds like they enjoy having all these footguns they refuse to fix, so they can feel superior and differentiate their club of greybeards who have memorised all the esoteric pitfalls, simply because they were along for the journey, from the masses.
> The problem with strlcat and strlcpy is that they assume that it's okay to arbitrarily discard data for the sake of preventing a buffer overflow. The buffer overflow may be prevented, but because data may have been discarded, the program is still incorrect. This is roughly analogous to clamping floating point overflow to DBL_MAX and merrily continuing in the calculation.
Well, sounds like no one else stepped up with a fork, the commitment to maintain something better, and the networking effort, so the community had to put up with whoever was doing the work. Like if you didn’t cook and just sat on the couch you can’t be picky about you’re served.
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
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
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.
It's really not an open source issue. It's a more general issue than that. The author provides as counterexamples MacOS and Windows, but that's a silly comparison. Apple nor Microsoft never coordinated with anybody else on their APIs. Closed source developers are never as good at coordinating with others as OSS developers are. Sure, they can invest more in their own products, but that's a different issue.
Also, I'm not sure what kind of standard this author is pining for. We have Wayland and freedesktop.org. Pretty much any Linux app can already run on pretty much any DE
I don’t think of it as a coordination issue. OSS can coordinate well. What it can’t do is make decisions. Most times there are at least two possible implementations for a given task (with different legitimate trade-offs). The OSS approach isn’t to pick the implementation that works for the most people, but rather support both implementations. Many times the only decision is to not to decide.
The best projects have someone who will make unilateral decisions. They might be right or wrong, but it’s done and decided. Companies with an organizational hierarchy do that much better than a decentralized group of OSS developers.
> The author provides as counterexamples MacOS and Windows, but that's a silly comparison. Apple nor Microsoft never coordinated with anybody else on their APIs.
No, but each of those two systems is ruled by one dictator and has one blessed way to do things. For example in the Windows / .NET world, it's WinForms, er I mean WPF, er I mean...
> Also, I'm not sure what kind of standard this author is pining for.
It sounds like a wish for the clarity of a cathedral rather than the chaos of a bazaar.
In recent years it appears that at least for Microsoft different teams working on Windows also aren't really coordinating with each other resulting in a scattered OS with duplicated implementations of similar features and a dozen different UI styles.
> 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.
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.
> So if you're using GNOME, try not to depend on something that depends on having the whole KDE installed.
I disagree with this bit. When i used a Gtk desktop I still used KDE applications so I had lots of KDE libraries installed. I use KDE now and I still have lots of Gtk applications installed.
Its slightly wasteful of storage and memory but is still a lot less resource hungry than Windows.
> not entirely clear why/how this is an open source issue?
Was going to say this too, cause competing proprietary software companies generally don't coordinate. Macs don't easily run Windows programs and vice versa. Unless an alliance or some agreement to adhere to some standards body is made, the collaboration issue is part of both worlds.
> For fun, look into bicycles and how standardized (or, increasingly not) they are.
Because triangles are a fantastic, high-strength shape, that suits the loads a bicycle is subject to. For the vast majority of cases, it’s a very solid choice. We deviate when specific UX requirements are required (city bikes having a battery and a low stepover to suit a variety of clothing, and the motor makes up for additional weight required.
> Is there a solid technical reason for multiple ways to make shoes that connect to pedals?
All of them attempt to address the same requirement, and make different tradeoffs depending on use-case and environment.
> Why are there several ways to shift from your handlebars?
Price points, performance reqs, handlebar setup, environmental (is it expected to be subject to mud rocks and trees constantly?) and weight.
> With the popularity of disk brakes, why don't we have a standard size for pads?
Same as for shifters: the braking compound and design for a race road bike will be really different to what a DH race bike requires.
> All of them attempt to address the same requirement, and make different tradeoffs depending on use-case and environment.
All road shoes/pedals interface have the same requirements. All XC ones have the same ones, All Dh ones, same.
> Same as for shifters: the braking compound and design for a race road bike will be really different to what a DH race bike requires.
Regardless if we are talking shifters, breaks or pedals interface among a specific line (road, gravel, xc, DH) the requirements stay the same and more importantly those formats/shapes/interface almost never vary accross price point:
All mtb shifters from a given manufacturer and amount of gears available are usually interchangeable. A deore shifter can operate an XTR derailleur. Same SPD cleats accross all MTB pedals from Shimano. Same brake pad shape is used accross all lines for a given number of pistons. More importantly pads and calipers are usually interchangeable between road and mtb for a given manufacturer. Conpound, requirements and price point as little to do with it as manufacturers release pads with different compound but same shape.
What makes all these formats not standards is because every manufacturer wants to have its own for 2 reasons:
1) think it knows better
2) aim to capture a market and become a monopoly (through cleats format)
Only rarely they discuss between each others or release a standard and don't ask for royalties. Same as proprietary software vendors.
The open source fragmentation only really comes from reason 1.
> > With the popularity of disk brakes, why don't we have a standard size for pads?
Same as for shifters: the braking compound and design for a race road bike will be really different to what a DH race bike requires
I really don’t understand how this mentality Uk survives.
for the past 100 years companies have been working to get unfair advantage over each other by creating user lock-in, patent trolling each-other, DRM in games, changing their design to break compatibility with generic products etc.
surely you must realise that many motivations for product difference have no bearing on user benefit, or we would never have region-locking on DVDs or proprietary media formats.
Bicycle market is not a healthy competitive market. Shimano makes almost all gears for all bikes in Europe. For the price of an electric cargo bike that goes 15 mph and has 0.6 kWh battery I can buy an electric motorbike that goes 70 mph and has 6 kWh battery.
I'm not sure which point you are trying to make with the bikes. For road racing the UCI quite famously sets quite strict standards. For "normal" use, if you live within the US or EU will also have some standards (mostly conserning road saftey). Of course you may cherry pick some exceptions, but IMO this doesn't drive the point.
UCI only has power on formats [1] used in race. It definitely influences the market but it has no say on which width of handlebar can I use on my own bike as long as I don't pin a number in a UCI sanctionnd race.
[1] I prefer using that word because most aren't really standardised.
> Inertia of user base is by far the largest predictor of what will stick in a market
Why are you calling open source of market?
These appear to be feuds and battle of ideas fought between contributors, with minimal input from end users. There is no price signal at all
Re. Bicycles, it’s not a healthy market. Shimano dominates with 70% share in gears and brakes. Top 3 manufacturers have what, 95%+?
Also look at how cargo bikes cost 3x what a normal bike does, but have same components.
With that structure, users have zero input on size of breakpads.
There's still an agreement on what's beneficial, even if the how isn't standardized. TO use your bicycle analogy, it's widely accepted that clipping into pedals is beneficial, we've found it improves power transfer and efficiency - the idea of clipping in is standardized, but the implementation (cleat design) is still open for interpretation.
We see this in open source too - we can coordinate and all agree on a core idea or problem that needs solving, but still end up with different, competing implementations. It's not a bad thing, choice is good and often leads to innovation as different approaches compete and evolve.
I do think you are right on your first point - that inertia of user base is the predictor of what will stick. Even Linux, stuck around due to licensing and availability (and then user inertia from that) rather than any technical superiority.
It’s not at all. As a counter-example, in the 00s, open source rapidly coalesced to using git, which has been so incredibly successful that it has now been adopted for many private corporate proprietary software repositories as well.
I don’t think you can take a general lesson from any particular example here. Coordination of complex systems among thousands of competing and cooperative components is very hard and unpredictable, and why things happen depends on random events and personalities in ways that are not generalizable.
> Is there a solid technical reason for multiple ways to make shoes that connect to pedals?
Yes!
- Toe clips give you more power than just flat pedals. You can use regular shoes with them.
- Straps (similar to toe clips) can and be used with regular shoes / trainers and allow you to control the pedal stroke up and down. Fixed gear riders use them a lot.
- MTB style cleats are easier to unclip and re-clip than Road style cleats as you are more likely to need to clip / unclip quickly.
- Road style cleats provide better power transfer, the shoes are far stiffer as well.
> Why are there several ways to shift from your handlebars?
Two reasons. The first is that the technology has improved over time. I have ridden old racing bikes where the shifter was not on the handlebar and on the downtube. You had to feel the position of the next gear while steering with the other hand. It is difficult for people that haven't ridden a road bike before to get used to.
Secondly the different types of bikes have the rider in different positions and thus their hands will be in a different position. Thus the different shifter types.
The moral of the story is that different requirements, require different solutions.
BTW almost everything else around the pedal and the shifter is standardised. The hub are normally one of a few sizes, wheel sizes have a few standard sizes, bottom brackets are almost all the same sizes, headsets have a few standard sizes. I have a mountain bike from 1995 that I've put a brand new stem on because the headsets are the same size as they were in 1995.
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.
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 =)
> 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.
Often there's a great use case for two things to work together but you have a chicken and egg situation. You need a top-down edict to get everyone on the same page.
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)
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."
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.
> Since then Microsoft has had no real answer for "how do I write desktop applications for Windows?" other than "use Electron".
Microsoft has been pushing WinUI the past few years, with WinUI 3 being the latest recommended UI toolkit [1]. I think what's interesting about WinUI 3 is it's not built into Windows - you have to ship the whole toolkit with your app, just as you would GTK or Qt on Windows. I find that a perplexing direction for a "native" toolkit.
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).
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.
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.
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.
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?
> 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 :)
> 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.
I often submit minor bug fixes or features to fairly popular projects, and as an outside contributor the communication can be very async. It's typically limited to GitHub PR/issue discussions, and sometimes the latency is measured in weeks/months.
I think it's probably quite different if you're a "core contributor" and likely using additional channels like slack and scheduled meetings, more akin to a company operating.
Readit News
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!
https://sourceware.org/legacy-ml/libc-alpha/2000-08/msg00053...
So it wasn't for lack of trying. Yes, Open Source can't coordinate and this is why we can't have nice things.
He is clearly not being rational there, but I could see how his aesthetic tastes might correlate pretty well with robust software. I suppose that saying no to new features is a good default heuristic, these additions could have easily added more problems than they solve, and then you have more surface area to maintain.
That being said, this old-school ideology of maintainers dumping the full responsibility on the user for applying the API "properly" is rather unreasonable. It often sounds like they enjoy having all these footguns they refuse to fix, so they can feel superior and differentiate their club of greybeards who have memorised all the esoteric pitfalls, simply because they were along for the journey, from the masses.
He was not that wrong!
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
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.
Also, I'm not sure what kind of standard this author is pining for. We have Wayland and freedesktop.org. Pretty much any Linux app can already run on pretty much any DE
The best projects have someone who will make unilateral decisions. They might be right or wrong, but it’s done and decided. Companies with an organizational hierarchy do that much better than a decentralized group of OSS developers.
No, but each of those two systems is ruled by one dictator and has one blessed way to do things. For example in the Windows / .NET world, it's WinForms, er I mean WPF, er I mean...
> Also, I'm not sure what kind of standard this author is pining for.
It sounds like a wish for the clarity of a cathedral rather than the chaos of a bazaar.
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.
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.
I disagree with this bit. When i used a Gtk desktop I still used KDE applications so I had lots of KDE libraries installed. I use KDE now and I still have lots of Gtk applications installed.
Its slightly wasteful of storage and memory but is still a lot less resource hungry than Windows.
Was going to say this too, cause competing proprietary software companies generally don't coordinate. Macs don't easily run Windows programs and vice versa. Unless an alliance or some agreement to adhere to some standards body is made, the collaboration issue is part of both worlds.
Because triangles are a fantastic, high-strength shape, that suits the loads a bicycle is subject to. For the vast majority of cases, it’s a very solid choice. We deviate when specific UX requirements are required (city bikes having a battery and a low stepover to suit a variety of clothing, and the motor makes up for additional weight required.
> Is there a solid technical reason for multiple ways to make shoes that connect to pedals?
All of them attempt to address the same requirement, and make different tradeoffs depending on use-case and environment.
> Why are there several ways to shift from your handlebars?
Price points, performance reqs, handlebar setup, environmental (is it expected to be subject to mud rocks and trees constantly?) and weight.
> With the popularity of disk brakes, why don't we have a standard size for pads?
Same as for shifters: the braking compound and design for a race road bike will be really different to what a DH race bike requires.
All road shoes/pedals interface have the same requirements. All XC ones have the same ones, All Dh ones, same.
> Same as for shifters: the braking compound and design for a race road bike will be really different to what a DH race bike requires.
Regardless if we are talking shifters, breaks or pedals interface among a specific line (road, gravel, xc, DH) the requirements stay the same and more importantly those formats/shapes/interface almost never vary accross price point:
All mtb shifters from a given manufacturer and amount of gears available are usually interchangeable. A deore shifter can operate an XTR derailleur. Same SPD cleats accross all MTB pedals from Shimano. Same brake pad shape is used accross all lines for a given number of pistons. More importantly pads and calipers are usually interchangeable between road and mtb for a given manufacturer. Conpound, requirements and price point as little to do with it as manufacturers release pads with different compound but same shape.
What makes all these formats not standards is because every manufacturer wants to have its own for 2 reasons: 1) think it knows better 2) aim to capture a market and become a monopoly (through cleats format)
Only rarely they discuss between each others or release a standard and don't ask for royalties. Same as proprietary software vendors.
The open source fragmentation only really comes from reason 1.
I really don’t understand how this mentality Uk survives.
for the past 100 years companies have been working to get unfair advantage over each other by creating user lock-in, patent trolling each-other, DRM in games, changing their design to break compatibility with generic products etc.
surely you must realise that many motivations for product difference have no bearing on user benefit, or we would never have region-locking on DVDs or proprietary media formats.
Bicycle market is not a healthy competitive market. Shimano makes almost all gears for all bikes in Europe. For the price of an electric cargo bike that goes 15 mph and has 0.6 kWh battery I can buy an electric motorbike that goes 70 mph and has 6 kWh battery.
They are both about £4,000
[1] I prefer using that word because most aren't really standardised.
Because each manufacturer can't put a premium on their pads that way.
Why are you calling open source of market?
These appear to be feuds and battle of ideas fought between contributors, with minimal input from end users. There is no price signal at all
Re. Bicycles, it’s not a healthy market. Shimano dominates with 70% share in gears and brakes. Top 3 manufacturers have what, 95%+? Also look at how cargo bikes cost 3x what a normal bike does, but have same components.
With that structure, users have zero input on size of breakpads.
We see this in open source too - we can coordinate and all agree on a core idea or problem that needs solving, but still end up with different, competing implementations. It's not a bad thing, choice is good and often leads to innovation as different approaches compete and evolve.
I do think you are right on your first point - that inertia of user base is the predictor of what will stick. Even Linux, stuck around due to licensing and availability (and then user inertia from that) rather than any technical superiority.
I don’t think you can take a general lesson from any particular example here. Coordination of complex systems among thousands of competing and cooperative components is very hard and unpredictable, and why things happen depends on random events and personalities in ways that are not generalizable.
Yes!
- Toe clips give you more power than just flat pedals. You can use regular shoes with them.
- Straps (similar to toe clips) can and be used with regular shoes / trainers and allow you to control the pedal stroke up and down. Fixed gear riders use them a lot.
- MTB style cleats are easier to unclip and re-clip than Road style cleats as you are more likely to need to clip / unclip quickly.
- Road style cleats provide better power transfer, the shoes are far stiffer as well.
> Why are there several ways to shift from your handlebars?
Two reasons. The first is that the technology has improved over time. I have ridden old racing bikes where the shifter was not on the handlebar and on the downtube. You had to feel the position of the next gear while steering with the other hand. It is difficult for people that haven't ridden a road bike before to get used to.
Secondly the different types of bikes have the rider in different positions and thus their hands will be in a different position. Thus the different shifter types.
The moral of the story is that different requirements, require different solutions.
BTW almost everything else around the pedal and the shifter is standardised. The hub are normally one of a few sizes, wheel sizes have a few standard sizes, bottom brackets are almost all the same sizes, headsets have a few standard sizes. I have a mountain bike from 1995 that I've put a brand new stem on because the headsets are the same size as they were in 1995.
Thus far, open source has optimized for maximum utility for individuals who can write code... but AI may be changing that soon enough.
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 =)
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.
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)
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."
Microsoft has been pushing WinUI the past few years, with WinUI 3 being the latest recommended UI toolkit [1]. I think what's interesting about WinUI 3 is it's not built into Windows - you have to ship the whole toolkit with your app, just as you would GTK or Qt on Windows. I find that a perplexing direction for a "native" toolkit.
[1] https://learn.microsoft.com/en-us/windows/apps/winui/winui3/
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.
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).
It's called the Common Desktop Environment.
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.
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?
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 :)
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.
I think it's probably quite different if you're a "core contributor" and likely using additional channels like slack and scheduled meetings, more akin to a company operating.