"Simply schedule it in like you would any other work."
When I schedule in work, usually it involves a client paying me for that work. One of my clients for one of my larger ongoing projects expects my team to produce 20 days of development a month. How exactly do I explain to them that instead we will be doing 18 days of development for them, and two days contributing to, say, Rails? I don't think they'll really see that two days of contribution to the improvement of Rails is equivalent to two days of adding features to their product.
Your team will still be producing 20 days of development a month. The whole idea behind a manifesto like this one is to introduce a new kind of task into your pipeline.
What does "20 days of development" really mean? Does it exclude unit tests or integration tests? Does it exclude writing developer docs? Does it exclude performance tuning?
All those are development tasks whose purpose is to make your product better in different ways. This manifesto posits that working on the open source software your product is based on will also make your product better. To me, your question indicates that you haven't yet decided whether this proposition is true.
You are very intuitive. My comment initially read "I don't think they'll really agree...", and then I changed the last word to "see" when I realised I wasn't sure whether I even agreed with it myself.
My team certainly does do things like writing unit and integration tests and developer documentation, and these are things I do charge clients for (though sometimes even these things can be difficult to explain as a line item on an invoice - but, as others often say here, the kind of clients who are problematic about that sort of thing are perhaps not the clients you really want to work with).
Personally I would have a hard time explaining to a client that we spent their paid-for time improving something "for the greater good" that may or may not have a direct, quantifiable benefit for them.
Well rails is a bad example. You could just start by having your developers send 2 pull requests to libraries used in the features you are making. You don't even need to put a metric on it, but I bet that you are looking into or using libraries that could use improvements that would be noticed.
One approach would be to bake it into the value/expertise proposition of your team--these aren't just your ordinary Rails developers, or even Rails experts, but Rails contributors.
When I schedule in work, usually it involves a client paying me for that work. One of my clients for one of my larger ongoing projects expects my team to produce 20 days of development a month. How exactly do I explain to them that instead we will be doing 18 days of development for them, and two days contributing to, say, Rails? I don't think they'll really see that two days of contribution to the improvement of Rails is equivalent to two days of adding features to their product.