Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

deprecate the OpenControl schemas? #87

Open
afeld opened this issue Nov 15, 2019 · 3 comments
Open

deprecate the OpenControl schemas? #87

afeld opened this issue Nov 15, 2019 · 3 comments
Labels

Comments

@afeld
Copy link
Member

afeld commented Nov 15, 2019

OSCAL seems to have reached a point of maturity where the format has surpassed the expressiveness and completeness of the OpenControl schemas. I'm sure they're not perfect, but unlike the OpenControl ones, they are actively being worked on. Might be time to thank the OpenControl schemas for their service and indicate they are deprecated, recommending people use OSCAL instead.

Note this does not mean deprecating of the OpenControl brand or community. In fact, without having the baggage of the schemas to (not) maintain, more focus could be put towards tooling or documentation or whatever else.

Thoughts?

cc opencontrol/compliance-masonry#343

@joshuamckenty
Copy link
Member

I'm supportive of this - it always makes sense to me to follow the community.

@trevorbryant
Copy link
Contributor

@gregelin -- something we briefly touched on last week.

@aegershman
Copy link

aegershman commented Aug 26, 2020

I realize this is older and maybe isn't fitting for bumping/resurrecting; I'm newer to the opencontrol / auditing & compliance community at large, so forgive me if I'm ignorant of anything here--

At this point I don't feel there's a reason to "officially" deprecate the opencontrol schemas any more than defacto deprecation by virtue of superseding formats and tooling. I'm sure OSCAL has years & years of experience and lessons being put into it, and it very well may be a more comprehensive format. But it's ... intense. It's hardcore. Hardcore can be good, of course. But it's still hardcore. It's more difficult to conceptually model OSCAL or the tooling, at least for me & my team, as folks going from "pangea of excel sheets and wikis" to "something with a data format".

The opencontrol schemas are structured enough to bring order and flexibility to content quickly, and straightforward enough to let folks jump in faster and at least get started on something tangible & iterate quickly.

I mean, I guess I feel like I'm saying things that are already known; the README points out everything I've said up to this point:

Where OSCAL's focus is precision, the OpenControl schema's focus is on usability.


So, with all this said: maybe as an alternative to deprecating the opencontrol schema, how do folks feel about changes-- if any at all-- which serve to keep opencontrol scooting along to provide value for a mindset of "getting off the ground", at least for the foreseeable future? Or just not make any schema changes and keep rolling on with v3.1.0. Or cutting v4.0.0 (or v3.2.0?) which has some of the deprecations officially removed, e.g. officially doing implementation_status: enum -> implementation_statuses: [enum], and then holding it there. I don't know, just putting out ideas.

But to "officially" deprecate the opencontrol schemas would be unfortunate at this point. Even if everyone's time and attention is put into OSCAL or other formats, that's fine, but as someone whose new to this entire community and idea of "compliance as code", I feel it'd be doing a disservice to folks wanting something different for their software systems / the bureaucratic organizations they belong to if we officially shut down a format as accessible as opencontrol.

... you know what I mean? any thoughts?

EDIT: alternatively, maybe deprecating anything below 3.1.0 (or cut 4.x, deprecate below it?) and cut a version of compliance-masonry cli which assumes a minimal version to "support"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants