Abstract: This article presents a succinct and minimal handbook of best practices of how to create and grow community open source projects. We start with the assumption that the handbook’s user has a minimal but useful piece of software at hand that they want to open source and build a community around.
Keywords: Open source, open source projects, open source communities, creating open source projects, growing open source projects
Reference: Riehle, D. (2020). Creating and Growing Community Open Source Projects. In Proceedings of the 27th Conference on Pattern Languages of Programs (PLoP 2020). ACM, 14 pages.
Abstract: Increasingly companies realize the value of using free/libre and open source software (FLOSS) in their products, but need to manage the associated risks. Leading companies introduce open source governance as a solution. A key aspect of corporate FLOSS governance deals with choosing and evaluating open source components for use in products. Following an industry-based research approach, we present 13 best practices in the pattern format of context-problem-solutions paired with consequences. In this paper, we cover an excerpt of the Component Approval section of our FLOSS governance handbook. This article builds upon our previous EuroPLoP publication covering Component Reuse in FLOSS governance processes, as well as other publications on the topic. Analyzing qualitative data gathered from 15 expert interviews, we derive and interconnect the common industry recommendations for reviewing, tracking, and approving open source components in a company environment. We conclude by presenting workflow templates that put various best practices in relation to each other.
Keywords: Commercial use of open source, component approval, FLOSS, FOSS, industry best practice, open source software, open source governance, pattern language
Reference: Harutyunyan, N. & Riehle, D. (2020). Industry Best Practices for Component Approval in FLOSS Governance. In Proceedings of the 25th European Conference on Pattern Languages of Programs (EuroPLoP ’20). ACM, article 33.
Abstract: Open source software usage in companies is on the rise, often resulting in lower development costs, higher quality, and quick availability of code. However, using open source software in products comes with legal, business, and technical risks. Experienced companies prevent and address these risks through corporate open source governance. In our previous work, we studied how top-tier companies got started with corporate open source governance. We proposed a set of industry best practices on the topic, using the practical format of interconnected context-problem-solution patterns. In this study, we put the proposed state-of-the-art practices to the test by evaluating their real-life application in a case study at a Germany-based multi-billion-dollar corporation with products in four distinct industries and more than 17000 employees worldwide. In the course of two and a half years, we conducted 35 semi-structured employee interviews and workshops in five divisions of the company to assess the initial situation of open source governance, the process of getting started with governance following our recommendations, and the outcomes. In this paper, we report the results of this longitudinal case study by presenting the artifacts created while getting started with open source governance, as well as the transferability evaluation of the proposed best practices, both individually and collectively.
Keywords: Practice-based information system research, best practices, longitudinal case study, corporate open source governance, open source software, OSS, FLOSS.
Reference: Harutyunyan, N. & Riehle, D. (2021). Getting Started with Corporate Open Source Governance: A Case Study Evaluation of Industry Best Practices. In Proceedings of the 54th Hawaii International Conference on System Sciences (HICSS 2021), pp. 6263-6274.
I’m happy to report that the 11th article in the Open Source Expanded column of IEEE Computer has been published.
Standardizing Open Source License Compliance With OpenChain
Cryptography, Distributed Databases, IEC Standards, ISO Standards, Legislation, Project Management, Public Domain Software, Software Development Management, Software Standards, Blockchain, Open Chain Project, ISO IEC JTC 1 PAS Transposition Process, Open Source License Compliance Standardization, Open Source Software, Standards, Licenses
Shane Coughlan, Linux Foundation
Computer vol. 53, no. 11 (November 2020), pp. 70-74
Over on Twitter, that endless source of distraction, Matt Asay asked: “Do developers care about open source?” Apparently, he is asking in response to an interview he had with a vendor who claimed that developers don’t care whether their service is available as open source (it is not). According to the vendor, developers just want to use a reliable service (and pay).
By all measures, the German Corona Warn app is already a highly successful software product. However, from the perspective of open source license compliance, it is defective. Using open source code in your product requires that you fulfill the obligations of the open source licenses of that code, and the Corona Warn app does not do that. Let me explain.
Open source code may be free to use, but it comes with strings attached, which are its licenses. An open source license spells out (1) permissions (you are allowed to use the code for free, among other things), (2) obligations to fulfill to receive the permissions (like giving credit to the original authors), and (3) prohibitions (for example, you are not allowed to claim endorsement of your work by the original open source programmers).
Open collaboration was popularized by open source projects, and since has made its way into wikis and Wikipedia, the mix and remix culture and open content, open educational resources, and so forth. Just what exactly is it?
Open source collaboration requires open communication, they say. Just what is open communication, exactly? Drawing on past research , here are the four principles that make communication open. Open communication is communication that is
Public: All communication takes place in the public eye, and none or very little behind closed doors; private side-discussions are discouraged.
Complete: All communication is complete to the extent possible. Assumptions are made explicit and conclusions of discussions are summarized.
Written: All communication is in written form, allowing folks to participate at their own pace; any non-written communication will be transcribed.
Archived: All communication is archived for search and later retrieval. This documents communication for those not around (or awake).