Helping the VA navigate VistA's open road

No readers like this yet.
old postcard highway

Opensource.com

Since the Department of Veteran Affairs (VA) is doing the brave work of open sourcing VistA, we felt we owed it to them to practice the open source way in our response to their draft request for proposals (RFP). Here are the questions we sent in to the VA, along with a few additional points at the end that we continue to ponder.

Scope

Is the VA's intent to fold the private sector efforts together under the Custodial Authority, or to use the CA as a mechanism for incorporating their improvements in VA's VistA?

Will the code under the CA's aegis be the canonical version of VA VistA, or will VA's VistA exist as a downstream consumer of the CA's work product?

What is the nature of the "certification" envisioned by the VA? How does it differ, if at all, from the kind of approvals normally required under the usual open source contribution process?

Under what circumstances does the VA envision "certifying" contributions that are not incorporated in the canonical version?

Will the CA be responsible for tracking the intellectual rights (patents, copyright, etc.), or will that work be performed by another VA entity?

The Community Activity

Does the VA envision the CA as an organization that directs development efforts, a certification authority that creates consensus amongst the various VistA interests, or both?

Sustainment

In typical open source ecosystems, the task of building a sustainable business is often distinct from the task of building a sustainable community. Has the VA considered divesting the CA of its responsibility to sustain itself commercially?

What mechanisms are in place to encourage internal adoption of the CA's services within the VA?

Should the CA be unable to fund itself after one year, what contingency funding plans are in place?

What exit strategies have been considered for the CA, should the project be dissolved?

Questions We're Asking Ourselves

Why is the CA designed to hold all the power instead of distributing power amongst the VA and other community members? Why is the CA designed to be an arbiter for all members, including the VA?

Since the CA is the only source of certification, it is "unforkable," meaning the community is always beholden to the CA for approvals. How should the CA grow a contributor community, which is strongest when built on trust, while simultaneously imposing this certification regime?

How does the CA get sponsors and project members for ideas it approves?

How flexible does the VA intend the CA to be in responding to organizational and leadership evolution opportunities? Can the bureaucracy be quickly adjusted to respond to community needs?

The fast-track timeline for the project has a lot of legal work resolved in the first two-week time period. Since this is a contributor community, the usual boilerplate legal documents may not work as expected. Is the VA flexible on these legal milestones?

The CA is evaluated on a number of metrics that may not be relevant to the community over time. There will also be additional metrics that may prove useful in the future, but are not currently relevant or known. This kind of growth and change is natural in a transparent open source project. Is the VA open to changes in how and which metrics are tracked?

[This article was co-authored by Gunnar Hellekson and Karsten Wade.]

Tags
User profile image.
For the last decade Karsten has been teaching and living the open source way. As a member of Red Hat's premier community leadership team, he helps with various community activities in the Fedora Project and other projects Red Hat is involved in.

Comments are closed.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.