If you're using the technology a lot, the developers should already be diving into the codebase and improving it.
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.
> 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 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.
my first thought exactly. however I mostly find that many devs simply put workarounds out of the library (and suffer great pains when update time comes) or fix the library and never push the changes upstream
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)
heh. developers in a fortune 500 company will work around issues/misunderstandings in code from the same company... let alone some 20 open source projects they were told to use by some architect
I own a little agency here in Bolivia, and we will start doing this this month. It's a fantastic idea and one I hope catches on. Imagine the contributions if everybody did even a little slice of work.
Documentation, refactoring, updating the readme, whatever!
Question for maintainers of popular open source projects: Would you prefer two days of developer time/month, or a comparable cash donation?
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.
Personally I'd like to embrace the power of 'and'. :-)
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.
"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.
The idea of donating 2 days a month seems great but I feel the site isn't arming developers well. These are some example questions that might come up in conversations:
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.
This is fine, but in my experience, when I try to contribute to open source projects I use at work - the outcome a lot of the times is a few days to weeks (and in one case 2 years) of radio-silence on the PRs/issues that may or may not result in a merge or any response at all. Most of the time it does result in merges, but sometimes just talking to the author and asking if he needs help with something takes time. So it doesn't scale for most projects.
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.
Why not give developers 2 days a month to work on projects of their choosing? If the project they want to work on is an open source project, then great.
Why not give a developer two days to work on building a desk in his/her garage?
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.
If you look at it from a different perspective, being able to work on personal projects means your place of employment gets the skills you develop, has a chance to offer help and support or even invest in the idea together with you. It's brilliant for morale as well, and something that I love about my current place of work.
Speaking from personal experience, if I'm using a dependency within our application that I see fit to improve upon, I usually take the initiative to add that improvement --whether or not upper management approves of such behavior. I think this manifesto is great in that it encourages developers to contribute, but it's almost implied, that many developers who implement these tools, find requirements that would fit not only their needs but others as well.
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 think that developers and companies will benefit from this as much as the open source community will. One of the best ways to get better at coding is to read other peoples' code, especially well maintained open source code. Whether you pick up style tips or best practices from someone else's work, or sharpen your own eye by figuring out how you could have done it better. Analyzing an open source project is also great for learning a new language or familiarizing yourself with a new programming paradigm. In many ways this is equivalent to telling your employees "Spend two days a month honing your skills in a productive way".
I would definitely do this whenever I wasn't rushing to meet a deadline or dealing with a full bug queue.
Only 2 days? It's 2015!! You'd think that we could afford doing what each and everyone of us loved the whole damn time and not just 2 days while slaving away the rest of the month.
A la 2015… Since it started becoming clear that technology was advancing fast, changing everything and the process would continue for a long time, we've had this semi-utopian idea about the future.
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 don't see why you equate working on Open Source projects as something "loved" and the rest as "slaving". I personally prefer working on internal code than writing patches to larger projects, since the latter often linger for weeks or months, while the former code gets into production much faster, and with less BS.
(I'm assuming the distinction is based on OSS projects vs company code. Almost all the code I write is freely licensed anyway)
This is a great idea and limiting it to two days will help corporates not feel like they're "wasting" too much money (you know, because developers are "resources" and if they're being used for something else it's a "waste"; at least I've had that experience in the past).
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.
This works better in larger organizations than smaller ones. In a large org, there are more people working in the same capacity which creates more redundancy and allows for one person to keep doing the business's day-to-day specific work while another goes into open source community for longer term benefits.
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.
What's the cost of not having the OSS code to power your startup, and having to reimplement it from scratch or paying a huge license to some commercial vendor?
Great idea. In terms of how to pitch this to businesses, one angle I haven't seen mentioned so far is to emphasise how improvements in open source dependencies not used by competitors could give you a direct commercial edge. For example in my previous company we had our own DSL for algo trading algorithms that used LLVM, whereas all our competitors solutions were Java based. Any performance improvements we contributed to LLVM would benefit us but not our competitors.
I like the idea. The only problem I see from a companies' perspective is that open source technology suddenly becomes costly which then makes commercial options more viable and in long term could harm OSS.
I'm going to oppose this. Like 20% time, it ends up becoming a negative space and, despite the best intentions behind it, backfiring and making our cultural enemies stronger. "Agile", at its inception, wasn't the toxic micromanagement nightmare that it has become. We have to be more careful about what we put out there. Implying that 10% of an employee's time for this autonomy ought to be enough is dangerous.
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.
If only... There are some things in Nancy that I'd love to make some small changes to, if only to get some more comprehensible errors output when the Razor viewengine blows up because you typo'ed something in a view. I love NullReferenceExceptions...
BTW:
Is there something weird going on with justification on this page?
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.