RE: [cti] Status of CTI OASIS Open Repositories

["Back, Greg" <gback@mitre.org>]

Thanks for the feedback, Trey. 

> I *thought* we were talking about #2. 

Bret seems to be talking about #1, which is why I was confused.

> The biggest advantage I see is the
> ability to deal with issues and pull requests from non-TC members on open
> source projects initiated up by TC members.

This is possible in OASIS open repositories today. The CLA that open repositories require is similar to that required by other prominent open source projects.

> If we're going down the road of hosting things like the STIX 1=>2 upgrade
> utility and the STIX Patterning reference implementation, eventually (I
> suppose) the next generation of python-stix and libtaxii, then the entire
> ecosystem (including the TC membership) stands to gain by making it
> straightforward for non-TC members to contribute bug fixes and feature
> enhancements to these open source tools.

Concur. In what way is this not addressed by the current Open Repositories?

> I am *not* including things like JSON schemata and STIX/TAXII issue tracking
> in this category. I fully support the stuff that really falls under the rubric of
> the standards being subject to the normal IPR rules.

I've heard a consensus desire to keep JSON schemas out of work products, and consider them non-normative. If that has changed, we need to re-evaluate having the https://github.com/oasis-open/cti-stix2-json-schemas repo. 

> > Specifically regarding #2, the strongest argument I've heard is that
> > it would help keep the CTI open source repos separate from other TC's,
> > even though this can easily be done by searching for "cti-"
> > [1]. From a user standpoint, nearly all interaction with GitHub is
> > done on a per-repository basis, not per-organization. You can't watch,
> > star, or fork an organization, nor I have I seen any way to
> > automatically follow new repos that get created in an organization.
> > The only exception is the "dashboard" view
> > (https://github.com/orgs/<ORGNAME>/dashboard), which is only available
> > to members of the organization. For Open Repositories, under current
> > policies only the maintainers become members of the organization. I
> > personally never use the dashboard view for any organizations I am a
> > member of. The result is that each repository would need to be handled
> > individually, regardless of whether it's in the same organization as
> > repositories sponsored by other TCs.
> >
> 
> That's your experience, Greg. Mine differs.
> 
> While I do often interact directly with a single Git repository, I also frequently
> look at the parent Github org for new and interesting projects or when I
> forget the name of a specific project.

Fair point. I do this as well. Granted, I spend enough time browsing GitHub that I don't mind non-CTI projects in the same organization at CTI projects (I've found a lot of interesting projects by just browsing random organizations), so my experience may be atypical.

> Interested to hear what others have to say.

Agreed

> > On the other hand, in my experience maintaining multiple organizations
> > is significantly more work than maintaining multiple teams within the
> > same organization. Since I imagine OASIS staff will be maintaining
> > these organizations, I'd like to make it as easy on them as possible.
> >
> 
> If OASIS sets up a TC-specific Github organization for supporting open source
> tools and libraries, they can delegate the day-to-day maintenance of that to
> trusted members of the CTI TC, given that we establish a clear line as to what
> falls under the rubric of the standards (e.g., JSON schemata and the like) and
> is subject to the normal IPR rules. In this case, there would be no additional
> workload on OASIS staff.
> 
> In case we do proceed with option #2, if that is in fact an option, then we
> should put it to a TC-wide vote and in establishing this CTI Github
> organization all agree that projects hosted there be subject to licenses
> amenable to both open source and commercial usage, such as the Apache
> 2.0 or MIT licenses.

This is exactly what exists today with open repos (day-to-day maintenance trusted to TC members, with licenses amenable to open source and commercial usage). I don’t see a scenario where administrative rights for such an organization would be granted to non-OASIS staff (if so, then a lot of my arguments are moot).

Greg