closes #181 add: definition of oss or iss project - #182
Conversation
|
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: |
lenucksi
left a comment
There was a problem hiding this comment.
Hey @chtompki!
Thanks for creating this. I've added a few review comments inline.
In general I wonder if it might be good to think of this as pattern how to discern OSS and ISS projects.
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). |
There was a problem hiding this comment.
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). |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Curious here. In most cases I've found, there are system level distinctions that separate the ability to commit to a repository versus the administrative privileges of the repository (e.g. renaming it or deleting it). I was merely trying to capture that distinction here. That said, if we wish to collapse owner and committer I'm ok with that, but I don't think that it sufficiently describes all of the permissions afforded by most source control systems these days.
|
|
||
| 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 |
There was a problem hiding this comment.
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.
|
|
||
| #### 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
|
Hi @chtompki just checking in here again, if you would have the time and energy to continue work on this PR/pattern? |
|
Am working on this now |
|
@chtompki let us know when you feel like you got to a good next version and want an other review, or help in any form. |
|
hi @chtompki. I am wondering whether you want to continue work on this PR/pattern in the near future? Otherwise this PR is at risk of running stale. Also FYI there might be some overlap between what you are aiming to define here, and this pattern: Let us know how you want to proceed. And of course if you need any help, just ask :) |
|
@chtompki @MaineC wondering where this is at? Alternatively if you feel that you won't have time to work on this anymore, we can also close this PR, as I am suspecting that it would be a bit hard for somebody else to finish this PR? |
|
Closing this PR as stale now -- by all means re-open if still active. |
For the sake of posterity: