

The Two Day Manifesto - sergiotapia
http://twodaymanifesto.com/?atm=email

======
TheDong
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.

~~~
girvo
> _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.

------
sergiotapia
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!

------
thebenedict
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.

[1] ([http://www.theguardian.com/voluntary-sector-
network/2014/mar...](http://www.theguardian.com/voluntary-sector-
network/2014/mar/03/which-would-you-rather-have-time-or-money))

~~~
jkot
Well formatted bug report, with test case to reproduce issue is most helpful.

------
bshimmin
"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.

~~~
CodeMage
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.

~~~
bshimmin
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.

~~~
sukilot
Raise your rates 10%, and bill 18 days per month. Or eat the 10% yourself.

------
cdnsteve
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.

Companies like to feel comfortable.

------
dvirsky
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.

------
andrewmutz
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.

This is what we do at my company.

~~~
nine_k
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.

~~~
girvo
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.

------
KLVTZ
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.

------
karmacondon
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.

------
Paul_S
This is an equivalent to having 10% of your engineers work full time on OSS.
I'm not saying it's a bad thing just that it's a big ask.

I think it'd be better if companies instead opened their own code.

------
sktrdie
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.

~~~
netcan
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.

------
BinaryIdiot
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.

------
dmourati
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.

~~~
icebraining
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?

------
anonymousDan
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.

------
phelmig
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.

------
late2part
This is a novel idea, but 10% of an employee's time seems high.

------
vinceguidry
Will be implementing this in my department and every department I'm a part of
from here on out.

------
M8
Open Source needs to become a charity. Most businesses don't mind wasting
resources on charity as long as it generates good PR.

Two day manifesto makes it sound like a tax. Companies don't like taxes.

------
Thiz
Donate.

The Two Day Salary Manifesto would be much better.

------
michaelochurch
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.

------
douche
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?

