> I find it disingenuous to imply that developers should not be venturing outside the little garden of code they or their company has written except on certain

> I find it disingenuous to imply that developers should not be venturing outside the little garden of code they or their company has written except on certain days and that the developer will even have a choice in the matter. I don't think this was the intention of the link — I think it's a good faith request for engineering time. It's asking for two days per month in situations where there are presently no days per month. If someone in management is focused exclusively on what the next feature that's being implemented is—what things cause a developer pain isn't ever going to get captured by that. Probably at least half of the time, by the time I work out a bug in a third-party (or even first-party) library, I already have a hack or workaround. The cheapest thing, in the extreme short-term, is for me to just go with the workaround, and let every future developer experience the same pain. Of course this is a bad decision, but I suspect this is part of what is motivating the author of our manifesto. Of course, the downside to not sending things upstream (and contributing to FOSS in general) is that developers end up solving the same stuff over and over again. I can, off the top of my head, think of a couple problems I've solved myself multiple time, across multiple employers. Wasted time. edit: to be clear, I see your point, I think: the spirit here is what we're after, not rigid adherence to 2 days / month, and it fair to say that perhaps the link should speak to that, lest someone read it too literally. Also, keep in mind that it takes a good bit of work: if you patch a third-party dep, you need to somehow deploy/integrate that patch into your process in the meantime; you need whatever approvals internally you need to upstream the change; you need to ensure the patch is reasonable (e.g., not a hack) to upstream; you need to actually send to upstream and deal with any feedback from upstream (and in some cases, hope the upstream is even still alive). It can be several months later that upstream finally accepts the patch and cuts a release, and then you need to upgrade to that release.