A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

index.md 2.0KB

title: The Two Day Manifesto url: http://twodaymanifesto.com/ hash_url: 73fc8424bb

Each developer in your company should have two days per month to work on the open source software your product is built on.

Why should we?

There is probably more code in your product written by other people for free than was written by your developers. Giving something back to the people who built this for you is simply the right thing to do.

Don't buy that? That's OK. The real reason you should do it is because it will make your product better, make your developers better, and make your company a more attractive place to work.

Yes, really.

This code is still part of your product and by making it better, you make your product better. By taking the time to improve its stability, performance, or features, you are also improving your product. If you fix a bug in a library you use, that is a bug that you won't later see in production. If you improve the performance, that is performance you'll see in production. If you develop a feature you need, that will save you time when you need to use it in your product.

It also gives your developers a way to improve their skills. They become more familiar with their tools and their capabilities, and the change of perspective will give them new ideas about how to work on the main product.

How should we?

Simply schedule it in like you would any other work. Figure out which projects are a priority, decide what you want to work on in them, and then do it.

If you're not sure what tasks you start with, try looking at projects' issue trackers or asking their maintainers. You might want to start with smaller projects, as they will both be easier to get started with and more accessible to new developers, but really any software you use is an option.