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

4 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657
  1. title: The Two Day Manifesto
  2. url: http://twodaymanifesto.com/
  3. hash_url: 73fc8424bbfbf91a8f75db7060a24aea
  4. <p class="exhortation">
  5. Each developer in your company should have two days
  6. per month to work on the open source software your product is
  7. built on.
  8. </p>
  9. <h2>Why should we?</h2>
  10. <p>
  11. There is probably more code in your product written by other people for free
  12. than was written by your developers. Giving something back to the people who
  13. built this for you is simply the right thing to do.
  14. </p>
  15. <p>
  16. Don't buy that? That's OK. The real reason you should do it is because it
  17. will make your product better, make your developers better, and make your
  18. company a more attractive place to work.
  19. </p>
  20. <p>Yes, really.</p>
  21. <p>
  22. This code is <em>still part of your product</em> and by making it better,
  23. you make your product better. By taking the time to improve its stability,
  24. performance, or features, you are also improving your product. If you fix
  25. a bug in a library you use, that is a bug that you won't later see in
  26. production. If you improve the performance, that is performance you'll see
  27. in production. If you develop a feature you need, that will save you time
  28. when you need to use it in your product.
  29. </p>
  30. <p>
  31. It also gives your developers a way to improve their skills. They become
  32. more familiar with their tools and their capabilities, and the change of
  33. perspective will give them new ideas about how to work on the main product.
  34. </p>
  35. <h2>How should we?</h2>
  36. <p>
  37. Simply schedule it in like you would any other work. Figure out which projects
  38. are a priority, decide what you want to work on in them, and then do it.
  39. </p>
  40. <p>
  41. If you're not
  42. sure what tasks you start with, try looking at projects' issue trackers or asking
  43. their maintainers. You might want to start with smaller projects, as they will
  44. both be easier to get started with and more accessible to new developers, but
  45. really any software you use is an option.
  46. </p>