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.
10. The Problem
• Wide spread confusion as to the
nature of Open Source Software
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. 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
16. What makes it OSS-
ome?
• Broad peer review = more secure &
better quality code.
17. What makes it OSS-
ome?
• Broad peer review = more secure &
better quality code.
• Flexibility over time- the world
changes & you must too.
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. 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.
21. What makes it OSS-
ome?
• No per-seat licenses = scalable
usage
22. What makes it OSS-
ome?
• No per-seat licenses = scalable
usage
• Shared maintenance = lower TCO
23. What makes it OSS-
ome?
• No per-seat licenses = scalable
usage
• Shared maintenance = lower TCO
• Iteration & Experimentation
24. What makes it OSS-
ome?
• No per-seat licenses = scalable
usage
• Shared maintenance = lower TCO
• Iteration & Experimentation
• Ability to vet developers
34. Hook everything, hack nothing!
• Contrib made possible by Drupal’s
hook system
• Source of Drupal’s flexibility
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. 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
48. Support & Vendor Lock In
• Good shops won’t work with
hacked code, & neither should you
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
53. Quality Assurance
• With enough eyes, all bugs are
shallow
• Peer review increases quality
• QA is a process
54. Quality Assurance
• With enough eyes, all bugs are
shallow
• Peer review increases quality
• QA is a process
• internal reviews
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
63. Moar Benefitz Plz!
• Trial by fire training
• Community training
• Community recruitment
64. Moar Benefitz Plz!
• Trial by fire training
• Community training
• Community recruitment
• Marketing
65. Moar Benefitz Plz!
• Trial by fire training
• Community training
• Community recruitment
• Marketing
• Employee development
66. Moar Benefitz Plz!
• Trial by fire training
• Community training
• Community recruitment
• Marketing
• Employee development
• Vet your developers & shops!
67. Moar Benefitz Plz!
• Trial by fire training
• Community training
• Community recruitment
• Marketing
• Employee development
• Vet your developers & shops!
• Being awesome
72. Module or Patch?
• Maintaining a module is both a
personal & business commitment
73. Module or Patch?
• Maintaining a module is both a
personal & business commitment
• Is there a business benefit?
74. 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?
75. 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
81. Will work for pay
• DoD recomendation: Add contractual
incentives for getting code committed
“up stream” ( )
82. 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)
83. 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
87. Zivtech’s Project &
Patching
• Create specs
• Architecture plan
• Evaluating landscape & what's available
88. Zivtech’s Project &
Patching
• Create specs
• Architecture plan
• Evaluating landscape & what's available
• Determine approach
89. Zivtech’s Project &
Patching
• Create specs
• Architecture plan
• Evaluating landscape & what's available
• Determine approach
• Use all community code
90. Zivtech’s Project &
Patching
• Create specs
• Architecture plan
• Evaluating landscape & what's available
• Determine approach
• Use all community code
• Create custom module to extend
existing contrib modules (preferably)