5 ms·

>it is far better to have one really good piece of software than 20 half baked ones all doing roughly 80% of the whole. I have to disagree on this one. Multipl

>it is far better to have one really good piece of software than 20 half baked ones all doing roughly 80% of the whole. I have to disagree on this one. Multiple diverging projects create _Stability_, whereas a single project creates _fragility_. One bad step on the only project, and it will be all who suffer

bluGill 7y ago
That depends on how many people are involved. Enough people work on desktops that more is better. However for more obscure things merging projects can be the difference between two projects that are almost dead and one project that shows signs of life.
jacquesm 7y ago
Ok, one or two. A couple. But not the tower of Babel that we have today. No need for a monoculture but no need for forks for forks' sake either. Or complete re-implementations of stuff that already works because it is cool to be maintainer of a project, rather than collaborator. In the end it is all about having something that is viable and that can compete on merits with closed source.
- scumbert 7y ago
  Even funnier, forks over social identity/ideological differences
  - Deeplybrassic 7y ago
    Not even software exists in only a vacuum, it's influenced by real world events. There are lots of people who see some of these changes as a threat to the existence of the software they use and want to secure it themselves
- flir 7y ago
  > In the end it is all about having something that is viable and that can compete on merits with closed source. I thought it was about scratching your own itch? "I want to be a maintainer" kinda sounds like an itch.
mbreese 7y ago
I might agree with you in theory, but in the specific instance, there were never really two distinct projects. They were artificially maintained as two distinct projects to have an arbitrary “enterprise” project and the community-supported project. The relationship between FreeNAS and TrueNAS is more like the difference between Fedora and RHEL. Both sponsored by the same company, but the later is the more mature, “enterprise” version. So instead of having FreeNAS and TrueNAS we’re going to have “TrueNAS Core” and “TrueNAS Enterprise”. It’s honestly not that big of a shift from a practical perspective.
- yjftsjthsd-h 7y ago
  > like the difference between Fedora and RHEL That sounds more like RHEL vs CentOS, really. ...which is fitting, since those two have also been slowly coming closer and closer to each other.
BiteCode_dev 7y ago
Try to provide a package of a GUI app "for linux". After you support centos, fedora, debian, ubuntu, gentoo and arch, you'll maintain a mess of brittle packaging scripts for years, breaking at each release and some updates. Just making the first release for each is a challenge. Even app images, the least well integrated system will fail at some point. You'll see how stable is diversity. Then package for windows xp. It probably works on windows vista, 7, 8 and 10. Now I do see a lot of value in diversity. Resiliance, ethics, competition, collaboration... Stability isn't one.
- kick 7y ago
  Do developers not know how to statically compile software anymore? Also, you shouldn't be writing your own packaging scripts: leave those to distribution packagers. There are thousands of people who work on packaging these things, and the user of the distribution is much safer if they don't touch software distributed by random people. This stuff is completely stable, just don't break the assumptions of the system without knowing what you're doing.
  - johannes1234321 7y ago
    Depending on distributors means that your users will only use ages old versions of your software, thus you receive support requests for stuffprobably already fixed/changed. Sending users back to distros also takes time. And for static linking: That is kind of happening with those modern snap and flatpack and whatever systems for handling applications, but it's bad for security. I want to update my system zlib in case there is an issue instead if depending on all applications consuming compressed unteusted streams updating their package in time. And I certainly don't want each little tool bundling their own Qt.
  - BiteCode_dev 7y ago
    Oh, but you still need to make a deb, rpm, nix, whatnot then compose with the os tooling, conventions and expectations. And use those to provide your conf/update/failure, menu integration, permission system, logging, init system, notifications, etc. Or provide an app image and ignore most integration. This is my point exactly: to get stability, you remove diversity. Static linking, one packaging system, and you don't have to care about how diverse the universe it. But it also means you don't benefit from what make those differences add: security updates, dependancy graph, automation, signing, jails, user documentation and training, os integration, native window theming, etc.
lazyier 7y ago
> I have to disagree on this one. Multiple diverging projects create _Stability_, whereas a single project creates _fragility_. One bad step on the only project, and it will be all who suffer Anti-fragility is a lot more complicated then just having a lot of implementations. The moving away from CVS and SVN to much more easily distributed revision controls is one of the best things that ever happened to large open source projects. The reason for this is that when its very easy to loose contributors and users to forks then it enforces a lot of project management discipline on the part of the project leadership. Before when you held all the keys to the castle and it was difficult to move away it was very tempting for people to use their position to impose "political" restraints on other people. And vastly reduced hosting costs thanks to things like github, gitlab, spread of cloud providers and so on and so forth makes it now cheaper then ever before. And these things makes it easier to 'unfork' as well. In this way we have the odd result of easy forking has a way of making it so that forking isn't necessary. And when there is a major dispute in a particular community then cheap and easy forking (and recombining) means that people can actually have competing governance models and see which approach is actually better. Rather then just fighting until everybody gets burned out and abandons the project. Lede vs Openwrt is a good example of this. Libre Office vs Open Office. Gnome vs Unity. These things exist more due to competing governance models then anything else. So this can be summarized as saying "improvements in anti-fragility in modern large open source projects is more due to the fluidity in which projects can be managed, forked, and recombined rather then just the number of implementations users and contributors can choose from"

bluGill 7y ago

That depends on how many people are involved. Enough people work on desktops that more is better. However for more obscure things merging projects can be the difference between two projects that are almost dead and one project that shows signs of life.

jacquesm 7y ago

Ok, one or two. A couple. But not the tower of Babel that we have today. No need for a monoculture but no need for forks for forks' sake either. Or complete re-implementations of stuff that already works because it is cool to be maintainer of a project, rather than collaborator. In the end it is all about having something that is viable and that can compete on merits with closed source.

scumbert 7y ago
Even funnier, forks over social identity/ideological differences
- Deeplybrassic 7y ago
  Not even software exists in only a vacuum, it's influenced by real world events. There are lots of people who see some of these changes as a threat to the existence of the software they use and want to secure it themselves
flir 7y ago
> In the end it is all about having something that is viable and that can compete on merits with closed source. I thought it was about scratching your own itch? "I want to be a maintainer" kinda sounds like an itch.

mbreese 7y ago

I might agree with you in theory, but in the specific instance, there were never really two distinct projects. They were artificially maintained as two distinct projects to have an arbitrary “enterprise” project and the community-supported project. The relationship between FreeNAS and TrueNAS is more like the difference between Fedora and RHEL. Both sponsored by the same company, but the later is the more mature, “enterprise” version. So instead of having FreeNAS and TrueNAS we’re going to have “TrueNAS Core” and “TrueNAS Enterprise”. It’s honestly not that big of a shift from a practical perspective.

yjftsjthsd-h 7y ago
> like the difference between Fedora and RHEL That sounds more like RHEL vs CentOS, really. ...which is fitting, since those two have also been slowly coming closer and closer to each other.

BiteCode_dev 7y ago

Try to provide a package of a GUI app "for linux". After you support centos, fedora, debian, ubuntu, gentoo and arch, you'll maintain a mess of brittle packaging scripts for years, breaking at each release and some updates. Just making the first release for each is a challenge. Even app images, the least well integrated system will fail at some point. You'll see how stable is diversity. Then package for windows xp. It probably works on windows vista, 7, 8 and 10. Now I do see a lot of value in diversity. Resiliance, ethics, competition, collaboration... Stability isn't one.

kick 7y ago
Do developers not know how to statically compile software anymore? Also, you shouldn't be writing your own packaging scripts: leave those to distribution packagers. There are thousands of people who work on packaging these things, and the user of the distribution is much safer if they don't touch software distributed by random people. This stuff is completely stable, just don't break the assumptions of the system without knowing what you're doing.
- johannes1234321 7y ago
  Depending on distributors means that your users will only use ages old versions of your software, thus you receive support requests for stuffprobably already fixed/changed. Sending users back to distros also takes time. And for static linking: That is kind of happening with those modern snap and flatpack and whatever systems for handling applications, but it's bad for security. I want to update my system zlib in case there is an issue instead if depending on all applications consuming compressed unteusted streams updating their package in time. And I certainly don't want each little tool bundling their own Qt.
- BiteCode_dev 7y ago
  Oh, but you still need to make a deb, rpm, nix, whatnot then compose with the os tooling, conventions and expectations. And use those to provide your conf/update/failure, menu integration, permission system, logging, init system, notifications, etc. Or provide an app image and ignore most integration. This is my point exactly: to get stability, you remove diversity. Static linking, one packaging system, and you don't have to care about how diverse the universe it. But it also means you don't benefit from what make those differences add: security updates, dependancy graph, automation, signing, jails, user documentation and training, os integration, native window theming, etc.

lazyier 7y ago

> I have to disagree on this one. Multiple diverging projects create _Stability_, whereas a single project creates _fragility_. One bad step on the only project, and it will be all who suffer Anti-fragility is a lot more complicated then just having a lot of implementations. The moving away from CVS and SVN to much more easily distributed revision controls is one of the best things that ever happened to large open source projects. The reason for this is that when its very easy to loose contributors and users to forks then it enforces a lot of project management discipline on the part of the project leadership. Before when you held all the keys to the castle and it was difficult to move away it was very tempting for people to use their position to impose "political" restraints on other people. And vastly reduced hosting costs thanks to things like github, gitlab, spread of cloud providers and so on and so forth makes it now cheaper then ever before. And these things makes it easier to 'unfork' as well. In this way we have the odd result of easy forking has a way of making it so that forking isn't necessary. And when there is a major dispute in a particular community then cheap and easy forking (and recombining) means that people can actually have competing governance models and see which approach is actually better. Rather then just fighting until everybody gets burned out and abandons the project. Lede vs Openwrt is a good example of this. Libre Office vs Open Office. Gnome vs Unity. These things exist more due to competing governance models then anything else. So this can be summarized as saying "improvements in anti-fragility in modern large open source projects is more due to the fluidity in which projects can be managed, forked, and recombined rather then just the number of implementations users and contributors can choose from"