The business case for contributing code

618 views

Published on

In the Drupal community we tend to talk about committing code to our public spaces (drupal.org, but also github) in terms of "contributing" and "contributions", and while much of it can be seen in that light, there are actually very strong business reasons for publishing your code and/or attempting to get your code changes committed to the open source project that you are working on.

We will be looking at several documents from the U.S. Military detailing their recommendations for contracting Open Source Software services, and will use those as a jumping off point to discuss the many benefits of contributing code. Some of the business reasons for public publishing we'll explore will include:
* The power of peer review. With enough eyes, all bugs are shallow, and with only a few eyes the stupidity knows no depths!
* Fork you! The costs associated with "hacking" both Drupal core and contrib modules and base themes.
* Take my code, please! Cost savings from committing patches.
* Professionals publish or perish. Using code commits as marketing towards clients or potential hires.
* It's so easy, even a child(ish person) could do it! How you can easily integrate patching into your development workflow.

This session will also include a walk through of how Zivtech handles code review, patches, and deployment processes and you will hopefully walk away convinced that all of your in-house and out-sourced developers should be publicly committing their work.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
618
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • The business case for contributing code

    1. 1. The Business Case for Contributing Code Alex Urevick-Ackelsberg
    2. 2. The Business Case for Contributing Code Alex Urevick-Ackelsberg
    3. 3. About Us
    4. 4. About Us• Zivtech = 4+ years old, 20+ employees
    5. 5. About Us• Zivtech = 4+ years old, 20+ employees• Alex UA
    6. 6. About Us• Zivtech = 4+ years old, 20+ employees• Alex UA • Co-founder, CEO
    7. 7. About Us• Zivtech = 4+ years old, 20+ employees• Alex UA • Co-founder, CEO • Professional Troublemaker
    8. 8. About Us• Zivtech = 4+ years old, 20+ employees• Alex UA • Co-founder, CEO • Professional Troublemaker • Hat enthusiast
    9. 9. The Problem
    10. 10. The Problem• Wide spread confusion as to the nature of Open Source Software
    11. 11. The Problem• Wide spread confusion as to the nature of Open Source Software • Requires a different mind set for development: partially public development.
    12. 12. The Problem• Wide spread confusion as to the nature of Open Source Software • Requires a different mind set for development: partially public development.• Publicly committing code is talked about talked as strictly an altruistic activity
    13. 13. OSS goes toWashington
    14. 14. OSS goes to WashingtonClarifying Guidance Regarding Open Source Software (OSS) - bit.ly/ dod-ossh
    15. 15. What makes it OSS- ome?
    16. 16. What makes it OSS- ome?• Broad peer review = more secure & better quality code.
    17. 17. What makes it OSS- ome?• Broad peer review = more secure & better quality code.• Flexibility over time- the world changes & you must too.
    18. 18. What makes it OSS- ome?• Broad peer review = more secure & better quality code.• Flexibility over time- the world changes & you must too.• No vendor lock-in.
    19. 19. What makes it OSS- ome?• Broad peer review = more secure & better quality code.• Flexibility over time- the world changes & you must too.• No vendor lock-in.• No restrictions on users of OSS.
    20. 20. What makes it OSS- ome?
    21. 21. What makes it OSS- ome?• No per-seat licenses = scalable usage
    22. 22. What makes it OSS- ome?• No per-seat licenses = scalable usage• Shared maintenance = lower TCO
    23. 23. What makes it OSS- ome?• No per-seat licenses = scalable usage• Shared maintenance = lower TCO• Iteration & Experimentation
    24. 24. What makes it OSS- ome?• No per-seat licenses = scalable usage• Shared maintenance = lower TCO• Iteration & Experimentation• Ability to vet developers
    25. 25. One is the loneliest number
    26. 26. Don’t Hack What?
    27. 27. Don’t Hack What?• Drupal Core
    28. 28. Don’t Hack What?• Drupal Core• Contrib Modules
    29. 29. Don’t Hack What?• Drupal Core• Contrib Modules • ~16,700
    30. 30. Don’t Hack What?• Drupal Core• Contrib Modules • ~16,700• Custom Modules
    31. 31. Don’t Hack What?• Drupal Core• Contrib Modules • ~16,700• Custom Modules • Site-specific code
    32. 32. Hook everything, hack nothing!
    33. 33. Hook everything, hack nothing! • Contrib made possible by Drupal’s hook system
    34. 34. Hook everything, hack nothing! • Contrib made possible by Drupal’s hook system • Source of Drupal’s flexibility
    35. 35. Hook everything, hack nothing! • Contrib made possible by Drupal’s hook system • Source of Drupal’s flexibility • Functionality should be alterable from another module
    36. 36. Hook everything, hack nothing! • Contrib made possible by Drupal’s hook system • Source of Drupal’s flexibility • Functionality should be alterable from another module • This a bug, not a feature
    37. 37. Why not hack?
    38. 38. Why not hack?• Lose many of the major benefits of working with OSS
    39. 39. Flexibility & Scalability
    40. 40. Flexibility & Scalability• Can’t take advantage of improvements
    41. 41. Flexibility & Scalability• Can’t take advantage of improvements• Can’t interact with other modules
    42. 42. Flexibility & Scalability• Can’t take advantage of improvements• Can’t interact with other modules• Can’t use common scaling techniques
    43. 43. Long Term Costs
    44. 44. Long Term Costs• You broke it, you own it
    45. 45. Long Term Costs• You broke it, you own it• Not able to share costs
    46. 46. Long Term Costs• You broke it, you own it• Not able to share costs• Nobody will contribute to your private fork
    47. 47. Support & Vendor Lock In
    48. 48. Support & Vendor Lock In• Good shops won’t work with hacked code, & neither should you
    49. 49. Support & Vendor Lock In• Good shops won’t work with hacked code, & neither should you• Either get stuck with hackers or will have to pay to replace hacks
    50. 50. Quality Assurance
    51. 51. Quality Assurance• With enough eyes, all bugs are shallow
    52. 52. Quality Assurance• With enough eyes, all bugs are shallow• Peer review increases quality
    53. 53. Quality Assurance• With enough eyes, all bugs are shallow• Peer review increases quality• QA is a process
    54. 54. Quality Assurance• With enough eyes, all bugs are shallow• Peer review increases quality• QA is a process • internal reviews
    55. 55. Quality Assurance• With enough eyes, all bugs are shallow• Peer review increases quality• QA is a process • internal reviews • publish to d.o. issue queues
    56. 56. Security
    57. 57. Security• Doesn’t fall under community security processes / authorities
    58. 58. Security• Doesn’t fall under community security processes / authorities• Can’t easily apply security patches
    59. 59. Security• Doesn’t fall under community security processes / authorities• Can’t easily apply security patches• Lose “enough” eyes
    60. 60. Moar Benefitz Plz!
    61. 61. Moar Benefitz Plz!• Trial by fire training
    62. 62. Moar Benefitz Plz!• Trial by fire training• Community training
    63. 63. Moar Benefitz Plz!• Trial by fire training• Community training• Community recruitment
    64. 64. Moar Benefitz Plz!• Trial by fire training• Community training• Community recruitment• Marketing
    65. 65. Moar Benefitz Plz!• Trial by fire training• Community training• Community recruitment• Marketing• Employee development
    66. 66. Moar Benefitz Plz!• Trial by fire training• Community training• Community recruitment• Marketing• Employee development• Vet your developers & shops!
    67. 67. Moar Benefitz Plz!• Trial by fire training• Community training• Community recruitment• Marketing• Employee development• Vet your developers & shops!• Being awesome
    68. 68. Module or Patch?
    69. 69. Module or Patch?• Maintaining a module is both a personal & business commitment
    70. 70. Module or Patch?• Maintaining a module is both a personal & business commitment• Is there a business benefit?
    71. 71. Module or Patch?• Maintaining a module is both a personal & business commitment• Is there a business benefit?• Is it an itch you want to scratch?
    72. 72. Module or Patch?• Maintaining a module is both a personal & business commitment• Is there a business benefit?• Is it an itch you want to scratch?• If answer to either is no, we patch
    73. 73. Best Patch EVAH!!!-2522 lines, +148 lines
    74. 74. Will work for pay
    75. 75. Will work for pay http://zivte.ch/otddodcio
    76. 76. Will work for pay http://zivte.ch/otddodcio
    77. 77. Will work for pay
    78. 78. Will work for pay• DoD recomendation: Add contractual incentives for getting code committed “up stream” ( )
    79. 79. Will work for pay• DoD recomendation: Add contractual incentives for getting code committed “up stream” ( )• We still are asked for the opposite (i.e. to give a client a “break” on our charges if we are allowed to release it)
    80. 80. Will work for pay• DoD recomendation: Add contractual incentives for getting code committed “up stream” ( )• We still are asked for the opposite (i.e. to give a client a “break” on our charges if we are allowed to release it)• Ability to freely commit code is a non- negotiable part of contracts
    81. 81. Zivtech’s Project & Patching
    82. 82. Zivtech’s Project & Patching• Create specs
    83. 83. Zivtech’s Project & Patching• Create specs• Architecture plan
    84. 84. Zivtech’s Project & Patching• Create specs• Architecture plan• Evaluating landscape & whats available
    85. 85. Zivtech’s Project & Patching• Create specs• Architecture plan• Evaluating landscape & whats available• Determine approach
    86. 86. Zivtech’s Project & Patching• Create specs• Architecture plan• Evaluating landscape & whats available• Determine approach• Use all community code
    87. 87. Zivtech’s Project & Patching• Create specs• Architecture plan• Evaluating landscape & whats available• Determine approach• Use all community code• Create custom module to extend existing contrib modules (preferably)
    88. 88. Zivtech’s Project & Patching
    89. 89. Zivtech’s Project & Patching• Patch existing modules
    90. 90. Zivtech’s Project & Patching• Patch existing modules• Tracking the change and posting to d.o
    91. 91. Zivtech’s Project & Patching• Patch existing modules• Tracking the change and posting to d.o • Add to patches folder - deployed automatically
    92. 92. Zivtech’s Project & Patching• Patch existing modules• Tracking the change and posting to d.o • Add to patches folder - deployed automatically• Code and resolve issue
    93. 93. Zivtech’s Project & Patching• Patch existing modules• Tracking the change and posting to d.o • Add to patches folder - deployed automatically• Code and resolve issue• Review and iterate

    ×