Yeah, I should clarify: I'm a lot less certain of the solution than of the problem.
I was implicitly assuming some preconditions: a) You're a programmer trying to solve a problem, b) You have access to the source code of your dependencies. It might be a web API, but you must be able to setup your own server to service the API. If you can't fork a project my points are irrelevant.
If you can in fact fork, my idea is to explicitly deemphasize eco-system health and fragmentation in favor of just keeping your integrated stack clean. I think it's an approach worth trying out.
OSS people love to say, "you have the source, you can change it to do what you want." On the one hand it ignores that it takes more than just the sources to accomplish something in the presence of real-world constraints (time, resources). On the other hand, when you do take the steps to change it to do what you want there's a negativity associated with 'forking a project'.
I want to raise a counter-point that encourages people to fork projects rather than trying to work around issues with hacks atop black-box dependencies. This does already happen in the real world. Ubuntu does patch packages rather than wait for upstream to accept them. I think there's benefit to more people trying this in all parts of the eco-system.
The eco-system would be better off if projects were partly chosen based on how encouraging they are of forking. Sometimes the appropriate response to a patch may be, "thanks, this is great, but it's a little outside our ambit, so why don't you fork the project?" And baking this choice into the workflow would encourage simpler architectures that are easier for others to understand and start forking.
I was implicitly assuming some preconditions: a) You're a programmer trying to solve a problem, b) You have access to the source code of your dependencies. It might be a web API, but you must be able to setup your own server to service the API. If you can't fork a project my points are irrelevant.
If you can in fact fork, my idea is to explicitly deemphasize eco-system health and fragmentation in favor of just keeping your integrated stack clean. I think it's an approach worth trying out.
OSS people love to say, "you have the source, you can change it to do what you want." On the one hand it ignores that it takes more than just the sources to accomplish something in the presence of real-world constraints (time, resources). On the other hand, when you do take the steps to change it to do what you want there's a negativity associated with 'forking a project'.
I want to raise a counter-point that encourages people to fork projects rather than trying to work around issues with hacks atop black-box dependencies. This does already happen in the real world. Ubuntu does patch packages rather than wait for upstream to accept them. I think there's benefit to more people trying this in all parts of the eco-system.
The eco-system would be better off if projects were partly chosen based on how encouraging they are of forking. Sometimes the appropriate response to a patch may be, "thanks, this is great, but it's a little outside our ambit, so why don't you fork the project?" And baking this choice into the workflow would encourage simpler architectures that are easier for others to understand and start forking.