3. Breaking down the term
"Open Source" – Something people can modify and share because its
design is publicly accessible.
"Open Source Software" - Software with source code that anyone can
inspect, modify, and enhance.
For programmers, by programmers.
10. For programmers, by programmers.
Risk Elements
● License Risk
● Operational Risk
● Security Risk
11. License Risk
● Compliance challenges
● Low Risk: No real limiting condition,
only the copyright notice must be
intact.
● Medium Risk: Explicitly defines what a
modification is.
● High Risk: Very Restrictive. May require
our proprietary software to be released
under the same license, royalty-free.
For programmers, by programmers.
12. Operational Risk
● How well supported a component is?
● "Stable" or "Dead" ?
● Are there more recent revisions ?
For programmers, by programmers.
13. Security Risk
● Vulnerabilities in components.
● Old component with multiple
vulnerability.
For programmers, by programmers.
14. So what could be some of the Best Practices ?
Not only from the open-source management point of view but also as
a contributor.
For programmers, by programmers.
15. ● Prioritize a policy.
● Update promptly.
● Emphasize quality.
● Use Binary Repo Manager.
● Participate in the Community.
● Control with Built Tools.
● Fork when possible.
For programmers, by programmers.
Managing Open – Source Components
16. ● Read the project's contributing docs.
● Ask all the questions.
● Do checks on your work and check your work again.
● Remember the why!
● Be patient and open to feedback.
For programmers, by programmers.
Contributing to Open Source Software
By AndreaGriffiths11, Community Manager,
GitHub Community Forum
