Package-maintenance: Inner vs. Open Source

[ahmadnassri]

I see all the guides here being a great resource for both open source and inner source packagae maintainance, how can we ensure we cover both use-cases in the language / advise offered?

e.g. in the comments of #160 a suggestion was made to infer that maintainers should not mark projects "unlicensed", but that is unapplicable for inner source projects.

_Definition Reminder:_
Inner source is the use of open source software development best practices and the establishment of an open source-like culture within organizations. The organization may still develop proprietary software, but internally opens up its development. The term was coined by Tim O'Reilly in 2000. source - wikipedia

can we add Inner Source as part of the objectives / target coverage for topics produced and discussed in this project?

I only see it as a partial incerement in effort to ensure the language / examples / etc... are inclusive of that context.

[ljharb]

What is ”inner source”? Do yo mean “closed source”?

[ljharb]

Reading the Wikipedia entry, yes, it seems like that’s a kind of closed source, which is entirely out of the scope of this project, and need not follow most of iur recommended practices.

[ahmadnassri]

I personaly read the scope as "package maintenance" in abstract, and the call to action posted by @mhdawson doesn't seem to limit the context to open source, but rather focuses on friction of pacakage maintenance and adoption in abstract, especially referencing enterprise users, where inner source practices can most leverage the guidlines we're publishing here ...

the only difference between inner source and open source is the license, everything else is intended to be the exact same, as per the difinition and personal observations of inner source in practice at large companies.

I would love to discuss this more at the next meeting and get more on your thoughts @ljharb

[jasnell]

InnerSource, as a term is very different than Closed Source. InnerSource is the application of open source development principles within an organization.

[jasnell]

License really isn't the differentiator for Inner Source... as the same open licensing considerations apply. The differences lie in organizational/community boundaries only.

[ljharb]

@jasnell i understand the distinction, but i don’t see how this group’s principles would be aimed at anything non-open.

[ljharb]

@ahmadnassri the major and imo critical difference is the audience - “everyone” versus “not everyone”. Anything only visible/available to an exclusive subgroup of humans (modulo a license) isn’t something i think node should be focused on.

[vweevers]

If the guidelines published here are applied to Closed or Inner Source projects, it can increase their quality and chances of being "promoted" to open source (but I realize making more code open source is a non-goal). Perhaps we could we say something like "These guidelines can be applied to Closed or Inner Source as well, at your own discretion" and leave it at that?

[mhdawson]

In the spirit of trying to limit scope initially, my approach would be to focus on Open Source but be open and to keep inner source in mind and accept tweaks to the guidance that help make it applicable assuming that they don't have a negative effect (add to much complexity, double the size of doc etc.). Once we are well underway we could then take another look and see if adding more focus on Inner Source makes sense.

@ahmadnassri would that approach work for you?

[ahmadnassri]

it does, thanks @mhdawson