The Two Day Manifesto
twodaymanifesto.com
twodaymanifesto.com
No software is perfect and sometimes the best way to fix your code is to actually fix whatever dependency is causing the problem and push it upstream.
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.
In my experience, developers often do everything possible to avoid working on dependencies (in a way that can be contributed upstream). While it may be the case that developers in SF or other big developer hubs do so, where I live most developers are content to either hack a fix into it, or work around it in their app code instead. Luckily, it makes getting a job easier for myself as I do have a number of open source contributions I can point to, which a lot of other devs around here lack. I had to explain to a recruiter what GitHub was, once.
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.
consider that many fixes, even when proper, may not be ready for submission, and many companies are penny pinching devs already and can hardly justify prettying up a fix for submission and prefer to establish a culture of 'fix it in the least amount of time'.
two days are a reasonable amount of time to get existing fixes in the codebase, clean them up to the library owner's guidelines, document them, the issue they solve, build a test case and deliver it upstream. two days are not enough for coding a workaround, and barely the minimum to prepare a patch properly.
that I think was the intent. as you say devs need to fix up things anyway, and two day a month to push upstream goes a long way to reduce work further the line (and I'm purposely ignoring the 'do good' argument)
Documentation, refactoring, updating the readme, whatever!
Charitable organizations often prefer the cash [1], but open source is different -- I suspect many developers have more context and preparation than the typical volunteer. On the other hand few people will be as efficient in a code base as the original authors.
[1] (http://www.theguardian.com/voluntary-sector-network/2014/mar...)
As someone who is going to be trying to make a living from his open source work in the near future, it sure would be nice to be given money by companies. But there's also more work than I can actually do on my own full time and extra labour would be nice too.
The additional problem is that there a lot of small open source projects that get used by don't really have the numbers that donations would give them enough money to live on, so they can't quit the day job. For those people time is actually much shorter than money.
(Disclaimer: I wrote twodaymanifesto.com)
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.
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.
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.
As outlined in the manifesto it is a long term investment.
It's hard to persuade actual paying clients about the benefits of playing the long game, usually because it's not relevant to them.
If you can afford to have an R&D department, I'm sure this manifesto makes a lot of sense.
1. Depending on your work environment, you may work in a place with lots of legacy code. After all, why should an employee work on open source when we could be improving our legacy codebase and slowly modernizing it?
2. How do we know the work contributed will be brought to use (aka merged in)?
3. Can and how do we donate to project X instead providing your time? We have some tight deadlines and we need everyone on board.
Marketing to your employer you need 2 days a month seems like a nonstarter. As in programming, start small, build a strong foundation and iterate. See what works.
Maybe you could start with 2 hours per week (1 day month) and see how that goes. This will get you, the developer, and the company who employees you comfortable with this arrangement.
Companies like to feel comfortable.
Another approach (we're also doing) is to open-source components of our code that might gain from a small community adoption. A side effect is that it contributes to creativity and the quality of work, and teaches people how to deliver high quality software.
This is what we do at my company.
Basically because the desk only affects the developer's private life. Why not just replace such a "project" with two more paid vacation days?
Working on an open-source project typically enhances lives of all of its users (and maybe even the for-profit entity that employs the mentioned programmer). Psychologically it's a different thing.
I recently implemented a very popular templating engine for our new project. Saw an improvement that could be made to the repo and did a quick PR on a fix. Done. I understand not all issues are that fast to fix, but it's default behavior on my part to fix the actual dependency (or find an improvement) while I'm working. In other words, I find that such actions are morally in-sync with the item at hand. I hope to see others share a common thought-process.
Make open-source part of your routine and see how far it takes you.
I would definitely do this whenever I wasn't rushing to meet a deadline or dealing with a full bug queue.
I think it'd be better if companies instead opened their own code.
If machines are making stuff, improving tools for the home and the workplace (vacuum cleaners & injection molding machines) will chip away at the number of hours we need to work. The future will be a leaser society. Part os this have come about. There are a lot more services and a bigger portion of total consumption allocated to various optional or "lifestyle" decisions. Most of us working in "developed economies" can certainly afford as many plates and electric kettles as we can use easily. In my grandmother's time, you got plates and sugar bowls for your wedding and your inheritance and tried not to break too many in between. But, some fundamental "human condition" issues have gone unsolved?
When I first thought about these things as a kid I didn't know that people had been making the same speculations for nearly 100 years.
I don't really know to say 'why.' But, I do think a good chunk of our consumption is competitive, and therefore resistant to adequacy. Real estate is competitive. Schooling is competitive. Status symbols are competitive. You can own the latest gadget for cheap, if you're willing to wait five years until prices drop (what would be the price of a brand new iphone 1 in 2015?).
Anyway… I think it's unhelpful to great improvements with cynicism. 2 days a month is a decent starting point. If you really want to work on whatever you want to work on without financial considerations.. you need to figure out a way of doing it for yourself. Otherwise, 2 days is not bad.
(I'm assuming the distinction is based on OSS projects vs company code. Almost all the code I write is freely licensed anyway)
Though I'd love to see a little more flexible "manifesto". Some months maybe do 3 days, or maybe crunch month you do 0 and the next month you do 4; I'd hate for this to be taken entirely literal.
At a smaller startup, there isn't that extra redundancy so any time one spends investing in future stability or performance comes at great opportunity cost to finding product market fit.
Two day manifesto makes it sound like a tax. Companies don't like taxes.
The Two Day Salary Manifesto would be much better.
Engineers should be able to improve and maintain the open-source libraries on which they rely whenever they fucking want. Working time, weekend time, 6:20 in the morning, whatever. Four fifths of these fucking companies would run better if they were run by people who actually do the work.
If engineers are managed down to 2-day increments of time instead of 2 months, then you need to fire 90% of your managers because there clearly isn't enough real work for them, so they're micromanaging. No one who is smart enough to write good code should ever have to justify days of his own working time. Fuck that, and fuck the whole shit pile of "Agile" nonsense that forces us to pretend that it's OK when senior engineers have to justify weeks and days of their own working time, often to non-producing "scrum masters" and "product owners".
I realize that this is a well-intended statement, but it's wrong-headed because companies where manifestos and official policies are needed just to shore up an engineer's basic autonomy to do valuable open-source work with his own working time are companies that don't deserve to live.
BTW: Is there something weird going on with justification on this page?