It's pretty surprising that they are using CVS for a new project
Using CVS over git in this day and age is a very dumb decision. They may make up for it in other, good decisions. But this decision is a dumb one.
What is it with this obsession with telling people how to get sh't done? If they write their code on used kleenex using wax crayons and share that using carrier pigeons, I don't give a sh't as long as the finished product is fine.
Most readers have no way of evaluating their crypto primitives, or their nuclear power plant, or a zillion other things.
But we can evaluate their source control!
The main reason is that CVS works well enough for our purposes. Most of the diff sharing and discussion happens over email anyway. That's where all the action is.
The main use case is that CVS distributes OK'd patches and allows us to revert them if they are later found to cause problems.
Everyone works on the head branch so there are never any surprises caused by delayed integration. Instead of using branches, the workflow switches between development mode and release mode when the time is right. Release branches receive only a handful of patches (usually less than 10) for the most critical issues discovered during their 1 year maintenance period. Again, CVS is entirely adequate for that.
It's not like there was no usage of git at all. Some devs actually use git in private and even mail git-generated diffs around. If those diffs fail to apply to the CVS tree the burden is on them to fix that. Since x.org runs git, all the X11 and other graphics code is ported to OpenBSD in git branches by our X maintainers and committed to the main CVS tree once it's ready to go live. This can be cumbersome but there's always a price to pay when integrating code from third parties that use different tooling.
But, if you don't think you can contribute code or money to the BSD folks, but really think that they are stupid, you can certainly convince them that moving to git is a good idea by developing a roadmap and reconfiguring their infrastructure. I'm sure they'd appreciate your effort.
(Most) people don't use git (or hg, or whatever) because it's shiny and new, but because it gives them a better workflow and higher productivity.
Probably migration to svn would be smarted since it doesn't change current workflow, granted they actually have a need to migrate.
You don't provide any compelling evidence to the contrary.
Whether that's because there's a demand to host the code on Github as well, or because they like Git, or a little of both is something I wouldn't presume to know.
http://www.openbsd.org/papers/anoncvs-paper.pdf
http://www.openbsd.org/papers/anoncvs-slides.pdf
It makes sense, if you consider the fact they have been using for the last ~18 years.
The release cycle is illustrated here: http://www.openbsd.org/papers/asiabsdcon2009-release_enginee...
They do branch and tag the tree for releases, but development is done in HEAD not in branches as would be customary for git.
I'm not an OpenBSD developer but my understanding is that the branches are used for subsequent patching of that release, not as part of "normal" new development work.
But this is not all that much of a problem in small cohesive teams where everyone with commit rights knows what the others are likely to be working on.
At Arbor, the last CVS job I worked (back in ~2003), we did release and dev branches no problem. I don't remember fretting about it much.
The big issue I remember is, it was a much bigger deal not to break the build.
I have heard that a lot of their devs will use git or hg on their local checkout to help manage their own dev environment.
You can find out more about the openbsd philosophy by reading some of the presentations on it at http://www.openbsd.org/papers/
And having used CVS myself, I strongly disagree with any connotation of "productivity loss because of old SCM" etc. — it all depends on workflow. Kind of like Vim certainly isn't inherently less productive than a shiny new Visual Studio 2022.