-
Notifications
You must be signed in to change notification settings - Fork 22
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
Comments
I'm supportive of this - it always makes sense to me to follow the community. |
@gregelin -- something we briefly touched on last week. |
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:
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 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" |
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
The text was updated successfully, but these errors were encountered: