Mini-Book: Open Source in the Enterprise

“Open Source in the Enterprise” by Andy Oram & Zaheda Bhorat

• Benefits of for using, supporting, and creating open source software:
  • Multiplying the company’s investment: “Evidence that open a project pays off financially comes from a recent report prepared under World Bank auspices (http://bit.ly/2/Favs4). Careful tracing of contributions to their project–a form of geospatial software called GeoNode (http://geonode.org/)–showed that the World Bank’s subsidiary had invested about one million dollars in the project but had benefited from an estimated two million dollars invested by other organizations.”
  • Benefiting from the most recent advances: “There is no need to reinvent the wheel in-house. Furthermore, your company can innovate more quickly by using tools and existing code that you can get with a simple download and installation process.”
  • Spreading knowledge of the software: “When the code is open–and especially when a robust community grows up around it–adoption is broader.”
  • Increasing the developer base: “Broader adoption, along with wide discussion of the source code, translates into a larger pool of talented developers from which the company can hire to work on the code and related projects.”
  • Upgraading internal developer skills: “Developers already recognize that the best way to learn good coding skills is to work on an open source project because they can study the practices of the top coders in the field. These benefits spread to the company that employ the open source developers.”
  • Buidling reputation: “And if you can release your own code as open source and win adoption for it, you prove that your organization is a leader in your field, adept at the best development practices.”
  • Recruiting and retaining developers: “Good developers want to work on exciting projects that affect large groups of people. They also want their skills and contributions to be widely recognized, and they enjoy the interaction they can have with peeers around the world. All these considerations lead them to gravitate toward open soruce projects, and if your competitors are more successful than you in supporting such projects, developers will bring their talents and reputations to those companies instead of yours.”
  • Faster startup of new companies and projects: “Working with a community, both on existing software and on your own innovations, saves you time and lets you focus limited employee time on critical competitve parts of your product.”
• “If you have great code and a dysfunctional community, people will leave and the code will atrophy. If you ahve dysfunctional code but a great community, people will improve the code.”
• See also: https://www.linuxfoundation.org/resources/open-source-guides/open-source-guides-reading-list/
• See also: https://paypal.github.io/InnerSourceCommons/
• See also: https://github.com/todogroup/guides
•  “But the key issue is that strong open source projects adopt strict quality processes, which your organization can also adopt for your own benefit. As for security, flaws occur in both open source and closed software. Neither is guaranteed to avoid breaches. Experience suggests that transparency and a large community in open source lead to faster fixes and faster distribution of the fixed software.”
• “The open code is a great advantage because you are not locked into a single company for support. Smaller and younger projects might not have yet developed this ecosystem of support, so getting support here might require you to devote more developer time and draw on informal help from the community.”
• Points of consideration for strategy
  • “Open source governance and policies that clarify to the broader company how and when it can use open source”
  • “Policies specifying how developers can contribute to external open source projects: role and time spent”
  • “Encouraging an open policy in applicable software projects from the start among technology leadership and enterprise architecture groups”
  • “Starting an InnerSource model in tandem, in which you adopt open source practices for internal development across your entire company”
• “It is important to find a senior sponsor who will help open doors and champion your cause.”
• “Developers and others who have worked in open source communities can do this at a grassroots level, with or without support and guidance from management. The advocates spend time evangelizing and educating other employees about open source through activities such as regular lunchtime sessions, webinars, and presentations at team meetings.”
• code hosting: GitHub, GitLab
• see: www.linuxfoundation.org/using-open-source-code/
• Project readiness
  • Code quality, active development, project maturity, level of support, public decision making, governance/commit access, security reporting
• “It’s crucial to align the goals and incentives within the company with success factors on the open source project.”
• When developers joining an open source community
  • “Check the code of conduct and contributor agreements, which are important to adhere to”
  • “Become adept at the tools used by the project”
  • “Review the project’s documentation (which varies in comprehensiveness and completeness), starting with the README file”
  • “Become comfortable with the process for making contributions provided by the project”
  • “Ask questions and become familiar with other contributors through participation in mailing lists or groups”
  • “Start taking items to work on from the project’s TODO list”
  • “Submit bug fixes”
• Best practice example: See: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md
• Why: “You need a story that justifies sthe investment of checking the code and community and then participating as community members. Thus, you need to explain clearly how the use of the code contributes to the business goals of the organization, and you need to check regularly to make sure that the local goals of the developers stay aligned with these larger goals.”
• “Open Source Archetypes: A framework For Purposeful Open Source”
  See: https://drive.google.com/file/d/1woaZ0wjQMbLQhyfB8ZOYveh8cW-jlDPG/view
•  Sample code of conduct: https://aws.github.io/code-of-conduct.html
• “When developers are accustomed to making designs in hallway conversations or over the telephone, they might need some time to learn to make decisions in more open ways and to use the less-intuitive communication media provided by mailing lists and bug trackers.”
• “Decisions can take longer when the crowd become involved. If you short-circuit the open source discussion process and make a quick decision in order to get a product out the door, you might need to roll back some of the work done later so that the code can be maintained and can adapt to future needs.”
• “An important side benefit of diligently recording decisions is that the project becomes less dependent on particular individuals and can recognize itself gracefully if key individuals leave. No single person has unique or irreplaceable information.”
• metrics
  • “Number of contributors and contributions, and what people and places they come from”
  • “Number of users, which you might be able to calculate roughly from statistics on downloads, mailing list participation, and other proxies.”
  • “Growth or shrinkage of the contributor mailing list”
  • “Number of reported issues, bugs, and fixes”
  • “Number of forks and stars on GitHub”
  • “Page views of web pages, blogs, and tweets associated with your project”
  • See also: https://github.com/chaoss/metrics/blob/master/activity-metrics-list.md
• dashboard: https://bitergia.com/opensource/
• attribution builder: https://github.com/amzn/oss-attribution-builder
• See: opendatacommons.org

Advertisement