3. Motivation
• Image
• Benefit from Open Source innovation
• Active participation in Open Source community
• Reduce risks and vendor dependencies
• Developers
• Developers want it – we want Developers
• Reduce cost and effort for maintaining internal
forks
• Affect product direction
• Collaborate on software
• Get external review and improvements for own
software
• Simplify internal processes
3
to Contribute
4. Just do it?
• Legal risks
• Financial risks
• Compliance risks
• Liability
• Software Patents
• Protect intellectual property
• Leak internal information
• Lost earnings
• Lost business opportunities
• Distraction
• No business value
Trust
our
employees?
4
5. Learn from others
https://opensource.google.com/docs/
• Creating – Using – Growing
• Internal tool for approval workflow
• No approval and no review required
• For patches to
• Any project which is a public repo on GitHub, and is
under the Apache 2, MIT, BSD, LGPL*, GPL*, MPL,
EPL, ISC, CC-BY, CC-BY-SA, OFL, MS-PL, Boost
Software License, or Artistic licenses, and does not
require you to sign anything not found on the pre-
approved CLA list below, and is not on the list below of
projects that require SVP approval.
• Any repo for which you’ve already been given blanket
approval from OSPO or used the approval form once.
• Any Google-maintained open source project like
Chromium, Android, Go, etc.
• Snippets (<100 lines of code, especially if not checked into
a repo)
• Stack Overflow, bug reports, …
https://opensource.zalando.com/docs/using/contributing/
• “Don’t contribute code which gives us an edge over
competitors”
• “Upstream code contributions are also encouraged and is a
natural extension of our dependency of open source projects
in our tech stack.”
• “Non-code contributions … are all sanctioned and
encouraged as part of your employment at Zalando”
• “[Contributions] are sanctioned and does not require a
review. Simply ensure that the project you are contributing
to is not licensed under AGPL.”
See https://github.com/todogroup/policies for other examples
5
6. Design goals
• Open Source Steward governs process
• Contribution is a business decision
• Legal and compliance requirements
must be fulfilled
• Line managers and product owners
approve contributions
• 2nd approval for „large“ contributions
• Limits for approval similar to
purchase order limits
• Paperless workflow
• Central tracking and reporting of contributions
• Release early, release often
• Features by user demand
• Public review process
• Pairworking
• External feedback
6
Implementation
7. Contributions
Contributions and New Open Source Projects
7
Code
Code
Code
Code
Name
License
Check License Check Code
New Open
Source
Project
Policy version 2
8. Next steps
• Small contributions
• Stack Overflow
• Small patches
• Documentation
• Build Scripts
• < 100 lines of code
• More specific definitions for handling copyright notices …
• Whitelisting approved Open Source projects for future contributions without review
• Approve projects or contributors?
• Code of Conduct
• Inspect and Adapt
February 2019
8
9. Q&A
DB Systel Open Source Policies
github.com/dbsystel/open-source-policies
DevOps
bit.ly/5pdops
Contact
@schlomoschapiro
schlomo.schapiro@deutschebahn.com
Slides
go.schapiro.org/slides