Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upcloses #181 add: definition of oss or iss project #182
Conversation
chtompki
requested review from
cewilliams,
gruetter,
lenucksi,
NewMexicoKid and
nyeates
as
code owners
|
I like the idea of writing down what aspects make InnerSource projects work. Two comments: If possible, it would be great to formulate this pattern as a pattern. You can either look at the structure of the other patterns. Alternatively there's https://www.youtube.com/watch?v=mMPdG2O-W2Y that I believe explains the structure and the reasoning behind that structure very well. I would refrain from including a definition of an Open Source project here. The Open Source definition is kept by another organisation: https://opensource.org/osd Maybe a starting point for rephrasing the content that was proposed here: Try to think about phrasing the pattern as one that helps increase community appeal? Also this pattern should be put into relation with #116 |
|
Good point. I didn’t know about that definition off hand. Should be able to get back to this later today. |
|
Hi @chtompki. Do you want any help? From the thread above it sounds like you were considering to describe the content that you already have as an InnerSource Pattern? |
|
Pardon me...I can try to get to it in the morning. Been a busy little while lately. Many thanks for the nudge :-) |
|
Working on this today. |
|
@MaineC - what do you think of my changes? Should we add a maturity model to this definitions section? I would think we might not, and instead create a maturity model that is separate referring to the definitions? |
|
Curious that the link checker failed. I just loaded all of the references just now in under 5s. |
|
The link checker fails with this error: The link you created in the main link: |
|
Hey @chtompki! I'm more than happy to merge this, however think there might a few quick additions that would be worthwile to add. |
| 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.com/resources/what-open-source). Further, | ||
| [RedHat also supplies a defintion of OSS project](https://www.redhat.com/en/topics/open-source/what-is-open-source). |
lenucksi
Aug 15, 2020
Member
As @MaineC already suggested I think using or at least adding the OSIs definitions here would have merit.
https://opensource.org/osd
As @MaineC already suggested I think using or at least adding the OSIs definitions here would have merit.
https://opensource.org/osd
| 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.com/law/13/1/which-open-source-software-license-should-i-use). |
lenucksi
Aug 15, 2020
Member
The OSI stewards a widely-accepted overview and list of licenses. I think they should be referenced.
The OSI stewards a widely-accepted overview and list of licenses. I think they should be referenced.
| 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.com/law/13/1/which-open-source-software-license-should-i-use). | ||
| 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. |
lenucksi
Aug 15, 2020
Member
While I agree that the licensing issue is less of a problem with InnerSource, there are problems with large corporate constructs and taxation issues that led to the evolution of a license. Maybe it would be worthwhile to have a word with the people involved with #147 (or on the Slack, @gruetter and @Danese might know more too.)
While I agree that the licensing issue is less of a problem with InnerSource, there are problems with large corporate constructs and taxation issues that led to the evolution of a license. Maybe it would be worthwhile to have a word with the people involved with #147 (or on the Slack, @gruetter and @Danese might know more too.)
| 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) |
lenucksi
Aug 15, 2020
Member
I entirely agree with this definition in the Context of OSS.
The context of ISS uses a slightly different, simplified set of terms though, which I think we should keep in the ISS context.
- Trusted Committers: This fuses Owners & Committers to a certain degree, there is no real separation in most of all cases.
- Contributors: External or Internal to the host project. What it sounds like.
- Users: What it sounds like.
I haven't seen the Apache PMC concept in the InnerSource domain yet. There is a role called product owner, however this might not be real match and still needs a bit of work.
The Learning Path repo has a bit more on those uses of terms.
I entirely agree with this definition in the Context of OSS.
The context of ISS uses a slightly different, simplified set of terms though, which I think we should keep in the ISS context.
- Trusted Committers: This fuses Owners & Committers to a certain degree, there is no real separation in most of all cases.
- Contributors: External or Internal to the host project. What it sounds like.
- Users: What it sounds like.
I haven't seen the Apache PMC concept in the InnerSource domain yet. There is a role called product owner, however this might not be real match and still needs a bit of work.
The Learning Path repo has a bit more on those uses of terms.
|
|
||
| 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 |
lenucksi
Aug 15, 2020
Member
I like this separation around network infra 😉 . Depending on the audience it might be a bit technical.
What do you think about cases of e.g. an ISS project in a private repo on the public GitHub instance (this one right here)? Network-wise this would be available, access restrictions come in at a different layer.
I like this separation around network infra
What do you think about cases of e.g. an ISS project in a private repo on the public GitHub instance (this one right here)? Network-wise this would be available, access restrictions come in at a different layer.
|
|
||
| #### 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 |
lenucksi
Aug 15, 2020
Member
I technically agree, however would think that we might ask corporates to please use a SCM.
I technically agree, however would think that we might ask corporates to please use a SCM.
| the features of the GitHub (or source control management system more generally) user interface as the project’s | ||
| primary website. | ||
|
|
||
| #### Asychronous Communications |
lenucksi
Aug 15, 2020
Member
Do you think it would it make sense to add a sentence around more synchronous / asynchronous or formalized/less formalized? E.g. issue tracker vs. mailing list or even IRC
Same goes with the text-based, archived, searchable, perma-linkable point that is often brought up. What do you and @MaineC think?
Do you think it would it make sense to add a sentence around more synchronous / asynchronous or formalized/less formalized? E.g. issue tracker vs. mailing list or even IRC
Same goes with the text-based, archived, searchable, perma-linkable point that is often brought up. What do you and @MaineC think?
|
Quite happy to make changes...will take me some time to carve out the time to sort it out. Changes will work their way in, in the coming days. |
|
Pardon my being remiss here. My $job became quite overbearing towards the end of the summer there. I have have more time on my hands :-) |
Absolutely no problem, we all have jobs, lifes and this review isn't running away anytime soon. |
For the sake of posterity: