I don’t object to ‘if you don’t like it, fork it’ as a response as long as you have structured the project to make it easy for people to maintain downstream forks.
-
I don’t object to ‘if you don’t like it, fork it’ as a response as long as you have structured the project to make it easy for people to maintain downstream forks. Indeed, I consider the existence of downstream forks to be a sign of health in an open-source ecosystem. This means:
- External interfaces to the rest of your ecosystem need to be 100% stable and to be added slowly. You must have feature-discovery mechanisms that make it easy for things to work with old versions of your project.
- Internal code churns infrequently. Pulling in changes from upstream and reviewing them should be easy.
- Internal structure is well documented and modular.
This leads to small projects with loose coupling that can be done (or, at least, ‘maintenance mode’, where they get occasional bug fixes but meet their requirements and don’t need to change).
A lot of projects were like that 20-30 years ago. Reaching the ‘maintenance mode’ state was a badge of honour: you had achieved your goals and no one else needed to reinvent the wheel. New things could be built as external projects. The last few decades have seen a push towards massive too-big-to-fork projects that have external interfaces that the rest of the ecosystem needs to integrate with, which are complex and lead to tight coupling.
-
I don’t object to ‘if you don’t like it, fork it’ as a response as long as you have structured the project to make it easy for people to maintain downstream forks. Indeed, I consider the existence of downstream forks to be a sign of health in an open-source ecosystem. This means:
- External interfaces to the rest of your ecosystem need to be 100% stable and to be added slowly. You must have feature-discovery mechanisms that make it easy for things to work with old versions of your project.
- Internal code churns infrequently. Pulling in changes from upstream and reviewing them should be easy.
- Internal structure is well documented and modular.
This leads to small projects with loose coupling that can be done (or, at least, ‘maintenance mode’, where they get occasional bug fixes but meet their requirements and don’t need to change).
A lot of projects were like that 20-30 years ago. Reaching the ‘maintenance mode’ state was a badge of honour: you had achieved your goals and no one else needed to reinvent the wheel. New things could be built as external projects. The last few decades have seen a push towards massive too-big-to-fork projects that have external interfaces that the rest of the ecosystem needs to integrate with, which are complex and lead to tight coupling.
@david_chisnall
"Too big to fork" is the new "too big to fail" -
I don’t object to ‘if you don’t like it, fork it’ as a response as long as you have structured the project to make it easy for people to maintain downstream forks. Indeed, I consider the existence of downstream forks to be a sign of health in an open-source ecosystem. This means:
- External interfaces to the rest of your ecosystem need to be 100% stable and to be added slowly. You must have feature-discovery mechanisms that make it easy for things to work with old versions of your project.
- Internal code churns infrequently. Pulling in changes from upstream and reviewing them should be easy.
- Internal structure is well documented and modular.
This leads to small projects with loose coupling that can be done (or, at least, ‘maintenance mode’, where they get occasional bug fixes but meet their requirements and don’t need to change).
A lot of projects were like that 20-30 years ago. Reaching the ‘maintenance mode’ state was a badge of honour: you had achieved your goals and no one else needed to reinvent the wheel. New things could be built as external projects. The last few decades have seen a push towards massive too-big-to-fork projects that have external interfaces that the rest of the ecosystem needs to integrate with, which are complex and lead to tight coupling.
@david_chisnall i don't like "if you don't like it, fork it", but other than that, agreed
-
R relay@relay.an.exchange shared this topic
-
I don’t object to ‘if you don’t like it, fork it’ as a response as long as you have structured the project to make it easy for people to maintain downstream forks. Indeed, I consider the existence of downstream forks to be a sign of health in an open-source ecosystem. This means:
- External interfaces to the rest of your ecosystem need to be 100% stable and to be added slowly. You must have feature-discovery mechanisms that make it easy for things to work with old versions of your project.
- Internal code churns infrequently. Pulling in changes from upstream and reviewing them should be easy.
- Internal structure is well documented and modular.
This leads to small projects with loose coupling that can be done (or, at least, ‘maintenance mode’, where they get occasional bug fixes but meet their requirements and don’t need to change).
A lot of projects were like that 20-30 years ago. Reaching the ‘maintenance mode’ state was a badge of honour: you had achieved your goals and no one else needed to reinvent the wheel. New things could be built as external projects. The last few decades have seen a push towards massive too-big-to-fork projects that have external interfaces that the rest of the ecosystem needs to integrate with, which are complex and lead to tight coupling.
@david_chisnall I think it also leads to big projects only being understandable to full time developers, and so more vulnerable to 'corporate capture', e.g. 99% of the development is done by developers that are being paid/sponsored by large corporations and then it's less a community and more a corporate project. And that's fine and it's great to be able to use it for free, but does that introduce conflicts of interests and decisions that are possibly less end user friendly and more corporate friendly.
-
@david_chisnall
"Too big to fork" is the new "too big to fail"RE: https://infosec.exchange/@david_chisnall/116272193136749031
If pots and pans were tinkers' hands, there'd be no work for forks and fans.
-
@david_chisnall i don't like "if you don't like it, fork it", but other than that, agreed
@SRAZKVT @david_chisnall how about " 'f you dont like it then you shoulda made a fork of it"?
-
@SRAZKVT @david_chisnall how about " 'f you dont like it then you shoulda made a fork of it"?
@paranormal_distribution @david_chisnall that's the same thing
-
@paranormal_distribution @david_chisnall that's the same thing
@SRAZKVT @david_chisnall ...yes, but to the tune of a Beyoncé song.
I'm sorry, I'll see myself out -
I don’t object to ‘if you don’t like it, fork it’ as a response as long as you have structured the project to make it easy for people to maintain downstream forks. Indeed, I consider the existence of downstream forks to be a sign of health in an open-source ecosystem. This means:
- External interfaces to the rest of your ecosystem need to be 100% stable and to be added slowly. You must have feature-discovery mechanisms that make it easy for things to work with old versions of your project.
- Internal code churns infrequently. Pulling in changes from upstream and reviewing them should be easy.
- Internal structure is well documented and modular.
This leads to small projects with loose coupling that can be done (or, at least, ‘maintenance mode’, where they get occasional bug fixes but meet their requirements and don’t need to change).
A lot of projects were like that 20-30 years ago. Reaching the ‘maintenance mode’ state was a badge of honour: you had achieved your goals and no one else needed to reinvent the wheel. New things could be built as external projects. The last few decades have seen a push towards massive too-big-to-fork projects that have external interfaces that the rest of the ecosystem needs to integrate with, which are complex and lead to tight coupling.
@david_chisnall there need to be more posts that mention cohesion and coupling. "high cohesion, low coupling" was a foundation of my academic years, and I'm frequently disappointed that it's not a more common mantra in software.
-
I don’t object to ‘if you don’t like it, fork it’ as a response as long as you have structured the project to make it easy for people to maintain downstream forks. Indeed, I consider the existence of downstream forks to be a sign of health in an open-source ecosystem. This means:
- External interfaces to the rest of your ecosystem need to be 100% stable and to be added slowly. You must have feature-discovery mechanisms that make it easy for things to work with old versions of your project.
- Internal code churns infrequently. Pulling in changes from upstream and reviewing them should be easy.
- Internal structure is well documented and modular.
This leads to small projects with loose coupling that can be done (or, at least, ‘maintenance mode’, where they get occasional bug fixes but meet their requirements and don’t need to change).
A lot of projects were like that 20-30 years ago. Reaching the ‘maintenance mode’ state was a badge of honour: you had achieved your goals and no one else needed to reinvent the wheel. New things could be built as external projects. The last few decades have seen a push towards massive too-big-to-fork projects that have external interfaces that the rest of the ecosystem needs to integrate with, which are complex and lead to tight coupling.
@david_chisnall i'm ambivalent about it. fossilized stuff like x11 has been subject to fascist takeover (enabled by the things you list). doesn't seem like a universally good outcome
(this is just the "how replaceable should labor be" discussion all over again, but less corporate now)
-
@david_chisnall i'm ambivalent about it. fossilized stuff like x11 has been subject to fascist takeover (enabled by the things you list). doesn't seem like a universally good outcome
(this is just the "how replaceable should labor be" discussion all over again, but less corporate now)
@david_chisnall the obvious answer is "labor i like should not be replaceable but labor i dislike should be" which doesn't yield itself for philosophical fedi posts, just actions
-
R relay@relay.infosec.exchange shared this topic
