[Question] Why are InnerSource projects assumed to be public?

SAP / project-portal-for-innersource

Lists all InnerSource projects of a company in an interactive and easy to use way. Can be used as a template for implementing the "InnerSource portal" pattern by the InnerSource Commons community.

https://sap.github.io/project-portal-for-innersource/

Apache License 2.0

143 stars 71 forks source link

[Question] Why are InnerSource projects assumed to be public? #5

Closed spier closed 3 years ago

spier commented 3 years ago

The documentation states that the following projects should be included in the portal:

?q=topic:inner-source is:public

I understand that everybody has to adapt the portal to their own use case. So in my scenario it might be different from what the docs state.

However I am wondering if it would be a more common default to list projects that are private rather, as projects that are already public would not be considered InnerSource anymore, would they?

Michadelic commented 3 years ago

That depends on where the projects are hosted but i guess we can adapt the documentation and be more verbose here:

For an enterprise GitHub instance hosted within a company network all projects are by default InnerSource, except the ones that intentionally chose to be private and not listed to others for various reasons, that is what the query above is referring to
For using GitHub.com with company plan, one could say public repositories are open source (and implicitely also InnerSource) and private repositories are InnerSource. But there might be other reasons for keeping them private, for example to prepare an open source launch.

Does that make sense? I think we can remove the public flag from the query and explain when to use it in a note below

spier commented 3 years ago

This makes sense.

I personally know the "GitHub.com with company plan" scenario best, that's why I was confused by the "is:public".

So yeah, I think leaving the "is:public" away would be least confusing.

The people that are building their own crawler to write repos.json will have to decide anyways which projects they want to show in the portal and which not. And if they are going through this effort, it is very likely that they know their own setup pretty well :)

If you wanted to document the GitHub Server vs GitHub Cloud difference that you are eluding to above, I personally would not do that in the main README. Feels like too much much detail.

It raises an interesting question though, that can help with onboarding to this project: What type of setup will people that are using this project likely have? Then one could optimize the documentation towards the most-likely scenarios.

Michadelic commented 3 years ago

thanks, I updated the documentation based on your feedback in commit ed19e9011578a5fa466a05f47bb04e38a88498e0 and added a note on possible scenarios.