OpenCCV: An Inclusive Approach for the Canadian Common CV
The research community has justly criticized the Canadian Common CV (CCV) for its cumbersome interface, unreliable up times, slowness, and other shortcomings [1, 2, 3]. These problems are of course solvable, but can also become even worse if we don’t have a proper understanding of how we got here. The first step to addressing the current shortcomings of the CCV is to make a distinction between the definition of a Common CV and its implementation by the “CCV website,” because they are two very different problems that demand different solutions.
The importance of separating the concepts of CCV and CCV website can be best explained with an analogy. Think of the JPEG format used for digital pictures. You might think that creating and showing JPEGs is a software problem, but it is not just that. There is a committee of scientists behind the JPEG standard that dictates in an abstract form what a JPEG file is. This committee is unrelated to the many software teams developing solutions for creating and displaying JPEG pictures. If these two problems were treated as one, then software like Photoshop would probably look like the CCV website.
The expertise required to develop a professional standard is different from that needed to develop software based on the standard. Standards are an effective way to fostering competition among alternative software solutions by requiring them to follow specifications and rules designed by experts.
We propose an open CCV standard that would define the data collected by the CCV, the rules and constraints behind the data capture, and the definition templates used by the granting agencies for their funding competition. The OpenCCV standard would be able to evolve over time to meet the changing demands of agencies, universities and researchers. Everyone in the Canadian research community should be allowed to submit a proposal for the standard, as is the case with all other open standards.
For this proposal to achieve its true potential, the team of people behind the OpenCCV standard should not have any overlap with the teams developing software solutions for it. It has been argued that the CCV is managed by a central government authority because of the privacy of the data captured by it, and because of the complexity of its multi-agency rules. Interestingly, the Canada Revenue Agency (CRA) faced a similar challenge with the tax filing software, but took a different approach. The CRA deals with the private data of Canadian citizens and companies, while accounting for many different rules and demands for different types of submissions. Since the security and privacy needs of the CCV are not higher than that of the CRA, and the submission process has comparable complexity, it is reasonable to argue that the approach follow by CRA would be valid for the CCV as well.
The method that the CRA employs for developing software is an open competition among third-party software companies. This approach has been successful for well over a decade. The CRA offers free paper forms for tax filing, and then software companies produce commercial solutions like Turbo Tax and UFile. The CRA could have chosen to make software for tax filing on their own, but instead they created the conditions for software companies to do it, which facilitated innovation in the sector over the years.
What I suggest is to adopt the same model of the CRA, and to separate the problems of creating the submission rules and processing the submitted information (OpenCCV) from that of producing the software used by researchers to input the information (CCV software). The OpenCCV “backend” software is the sensitive element and should be made by government IT, as is the case with the CRA backend. In turn, different front-end software solutions can be made by software companies and by government IT. In this respect, this proposal is different from the CRA case, because CRA does not to make its own front-end software for filing taxes.
In this vision, the “free” front-end software made by government funding agencies will have to compete against professional software made by private companies. This would be at no cost to the agencies because all the risk is assumed by the companies willing to compete. Since the needs of the research ecosystem are varied, there is room for having different pieces of software tailored to specific niches.
The key aspect of this proposal is the separation of problems: the government teams in charge of setting the rules and writing the backend software (the OpenCCV) should be completely independent from the teams making the CCV software solutions used by researchers. For this proposal to work, the OpenCCV standard must be provided in the same form and time to all teams in charge of front-end software, regardless of whether they are in the government or in the private sector. This aspect is essential for software companies to compete on a level playing field against government-made software. Furthermore, the separation of responsibilities is strategic because it “decouples” the solutions, leading to robust and well-defined systems. It also avoids the abuses of power from large teams that control the entire pipeline.
The competition against paid software will provide a measurement system to evaluate the quality of the free front-end software made by the agencies. This is important because the isolation of front-end IT teams from users leads to poorly designed software and dissatisfied users. Sheltering IT teams from external competition eliminates the much-needed forces that lead to innovative software solutions.
The CRA has demonstrated how the Canadian government can benefit from the breadth of knowledge of software scientists and engineers by letting the forces of competition play their part. By adopting the approach of a fellow Canadian agency, the granting agencies can work towards advancing the standards of software infrastructure for the conduct of research.
