diff --git a/README.md b/README.md index c0ea89ee7..efa0307f2 100644 --- a/README.md +++ b/README.md @@ -30,6 +30,7 @@ The below lists all known patterns. They are grouped into three [maturity levels * [Common Requirements](patterns/2-structured/common-requirements.md) - *Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.* * [Contracted Contributor](patterns/2-structured/contracted-contributor.md) - *Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.* * [Dedicated Community Leader](patterns/2-structured/dedicated-community-leader.md) - *Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.* +* [Definition of an InnerSource Project](patterns/2-structured/definintion-of-iss-project.md) - What are the core elements that make up an InnerSource Software project? * [Gig Marketplace](patterns/2-structured/gig-marketplace.md) - *Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements. This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.* * [Maturity Model](patterns/2-structured/maturity-model.md) - *Teams have started adopting InnerSource. The practice is spreading to multiple departments. Understanding of what constitutes an InnerSource project are wide spread though. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.* * [InnerSource License](patterns/2-structured/innersource-license.md) - *Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An **InnerSource License** provides a reusable legal framework for the sharing of source code within the organization. This opens up new collaboration options, and makes the rights and obligations of the involved legal entities explicit.* @@ -112,4 +113,4 @@ We welcome your contribution - be it small or huge! To learn more about how you ![Creative Commons License](https://i.creativecommons.org/l/by-sa/4.0/88x31.png) -InnerSourcePatterns by [InnerSourceCommons.org](http://innersourcecommons.org) is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-sa/4.0/) License. +InnerSourcePatterns by [InnerSourceCommons.org](http://innersourcecommons.org) is licensed under a [Creative Commons Attribution-ShareAlike 4.0 International](http://creativecommons.org/licenses/by-sa/4.0/) License. \ No newline at end of file diff --git a/patterns/2-structured/definintion-of-iss-project.md b/patterns/2-structured/definintion-of-iss-project.md new file mode 100644 index 000000000..3c8e73447 --- /dev/null +++ b/patterns/2-structured/definintion-of-iss-project.md @@ -0,0 +1,58 @@ +# Title + +The Definition of an InnerSource Software (ISS) Project. We will largely take the ideas that follow +from the definition of an Open Source Software (OSS) Project. Note, the definition of an OSS Project +follows from [opensource.com's definition](https://opensource.org/osd). Further, +[RedHat also supplies a defintion of OSS project](https://www.redhat.com/en/topics/open-source/what-is-open-source). + +Our goal here is to mimic the [open source way that opensource.com](https://opensource.com/open-source-way) +provides. In doing this, we foster collaboration and community inside our enterprises. + +## Definition(s) + +The following are the components are essential for a project to be declared an InnerSource Software +project. Note, the distinction between Open Source and InnerSource is merely +the network topology surrounding the source control management system instance. If the world at large +can view the code base, the project is Open Source. On the other hand if any portion of the project's source +code lives on a restricted network topology such that it is not available to be read by the world at +large then we deem it InnerSource, and refer to it as "private." Also, most OSS projects contain a +[license (list taken from opensource.com)](https://opensource.org/licenses). +The licenses are legal parameters that developers and users adhere to for the development and consumption +of the project. Luckily we need not worry about licensing because we are concerned with "private" repositories. + +We will use the term "population" in the following definitions +to reference the user base that has readership based upon the respective network topology. Further, we +will use the term "owner" to refer to one who has privileges to delete the code base; we will refer to anyone +who has commits in a repository or documentation or issue list as a "contributor"; we will refer to any person who can +push code to the repository a “committer”; we call any person using the repository a “user.” Naturally, the progression +of trust follows (most to least trusted) as: + +1. Owners (commonly referred to as project committee members) +2. Committers +3. Contributors +4. Users + +### Tenets of an OSS/ISS Project + +#### Code Base +For a project to be considered ISS, it's code base must be entirely browsable by the population +of users on a given network. It may or may not be hosted in a source code management system. That +is left up to the project owners. + +#### Distributions +Clearly a project must be distributed for it to be used. The mechanics of how a project releases its +distributions is left to the owners whether it be the source itself or more formally packaged convenience binaries. + +#### Website +Without a project website there is unlikely to ever be any users. However, a considerable number of projects use +the features of the GitHub (or source control management system more generally) user interface as the project’s +primary website. + +#### Asychronous Communications +Project communication is a must. There may be singlly owned projects that can be ISS, but they are few and far +between. More often than not, other people are involved. Thus, a mechanism of communication is a requirement. +Furthermore, one’s user base may live in a different time-zone. Thus, we find it a requirement for a project to be +able to call itself ISS that it have an asychronous communication paradigm. For example, many projects use GitHub +issues, while others use messaging applications, and some rely on plain old email. Although, we have yet to stumble +upon a project solely relying upon paper mail as its communication mechanism, such a communication mechanism indeed +falls within our definitions.