Skip to content

closes #181 add: definition of oss or iss project #182

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
chtompki wants to merge 10 commits into from
Closed

closes #181 add: definition of oss or iss project #182

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
235ac10
#181 add: definition of OSS or ISS project
chtompki Jun 25, 2020
c815880
#181 fix: nits with my forgotten formatting
chtompki Jun 25, 2020
2485023
#181 fix: Inner Source -> InnerSource
chtompki Jun 25, 2020
db1cdea
#181 fix: spelling Tenents -> Tenets
chtompki Jun 25, 2020
45f5c76
(update) #181 edit for suggestions
chtompki Aug 1, 2020
e34f804
(fix) README.md link and description defns
chtompki Aug 2, 2020
ee3fc2f
(fix) put the proper link to the open source project definition
chtompki Dec 9, 2020
8b800e5
resolve merge confilicts in README.md
chtompki Dec 9, 2020
b1f4edd
(update) move definition to structured
chtompki Dec 9, 2020
a6ac507
(fix) use simpler licenses page
chtompki Dec 9, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.*
Expand Down Expand Up @@ -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.
58 changes: 58 additions & 0 deletions patterns/2-structured/definintion-of-iss-project.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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.