Missing Open Implementation Section/Tag

[s-laugh]

There is (or could be) a difference between the code being open or the implementation being open of software, and there doesn't seem to be a clear distinction between the two on the site. It requires the searcher to investigate each repository.

For example, Slack is a closed source SaaS tool that is being used.

So if a gov entity developed a tool and for some (stupid) reason decided to not open it's source, but still make the solution alliable via SaaS, Packages (node, nuget, gem...), APIs, or other. It would be great if we could clearly identify them as such, as they could still be freely used.

But also on the other side, where the implementation is just for the team that built it, but the code is open for forking to be customized and made into their own.

[s-laugh]

@gcharest @smellems, what we were chatting about the other day.

[nschonni]

For example, Slack is a closed source SaaS tool that is being used.

Agreed, that wouldn't end up here

So if a gov entity developed a tool and for some (stupid) reason decided to not open it's source, but still make the solution alliable via SaaS, Packages (node, nuget, gem...), APIs, or other.

Think those would end up in the API store or some other place like APM, as it's not a open source solution.

If they're using an open source plug-in for Slack, then it would end up in Open Software (even if the base platform isn't). If they write a plug-in themselves, it would end up in Open Code for the department.

[s-laugh]

I guess that's my point, packages or API resources could be open for re-use (but still have protected code), so they should have a place on this site.
Now maybe the best course is to link to the API store (being the source of truth) - but then there is a reason this doesn't just have a link to GitHub.

For example, our group is prototyping a 'policy as code' engine for all benefits. Due to the sensitive nature of policy before it becomes public we may not be able to fully open the code. However we do want this implementation to be open for others to re-use at their will (as the source of truth for benefits). After some preliminary research, other than building our own "Reusable Components Catalogue", this is the best place to share that - but it might not be possible.

[gcharest]

Interesting, I can see that the Open Resource Exchange could provide a pointer to all things open, no matter the degree. On the other end, could it make it a bit convoluted?

What would you propose the section(s) be?

@nschonni Part of the initial scope of the ORE has widened a bit as well so maybe there's an opportunity to support different use cases?

[s-laugh]

What would you propose the section(s) be?

Might I suggest Open Services ?? -- "open" to other suggestions

[s-laugh]

I could also see a future state - longer term - where these categories are displayed in one list and filterable.

[smellems]

I think if it's an API then it should be on the API store, we don't need to recreate that list
https://api.canada.ca/en/homepage#all-apis

For SaaS hosted or maintained by the GC, for example GCcollab, GCmessage, maybe also GCpedia (internal to GC only), that could be a separate section. OSS or not, it's available by GC. Notify would be another example, also an API I think.

It could be a general section for XaaS, packages, or others "open" things. What else that already exists could we list there?

[s-laugh]

What else that already exists could we list there?

CDTS (while some code is on GitHub, it isn't the code used to publish, they have a closed repo on GCCode), it's complimented by the .NET & Java Templates

Our team is looking at building a few solutions that would likely fit under this header, which is my primary reason for suggesting it, so we can share them here rather than just on our own site.

[s-laugh]

I'm just wondering if there is any sense of a consensus on this, to take some action on?