Seriously, I spent a lot of time on this "digital humanities" (how I hate the term) stuff in the latter part of the last decade, and I came away from it with one major takeaway: when the grad students who are working on and advocating for a DH project move on to their next gig, then it's up to a professor or two to constantly recruit the next generation of grad students to replace them and make this piece of software Their Thing that they can put on a CV and get tenure with. But it never really pans out, even if there's some money behind it, because if you want to stand out in academia and move up then you have to do Your Own Thing and not Somebody Else's Thing.
Making matters much worse if the fact that few professors outside of CS departments are equipped to understand why what you're doing is The Future and you deserve to be hired into a humanities department for it. And to the profs within a CS Dept., it's really clear that while what you're doing may matter for the humanities you're not solving a Hard Computing Problem so shop it somewhere else please. So the project eventually goes in the archives, or becomes open-source abandonware. But one or two cohorts of grade students get a few journal articles out of it in specialized DH organs that nobody reads, so all is not totally lost.
What I'm describing here is endemic to the academy, so it's not like you can fix it by waving the "open source" wand over a project, or throwing money at it.
Anyway, I won't ramble more because I once gave a talk on this topic called "Why Most Digital Humanities Computing Projects are a Waste of Time". You can see it on YouTube: https://www.youtube.com/watch?v=7OeC8qGT8DI
Again, the TL;DR is this: if you want to collaborate and annotate texts with the ability to cite specific versions, track changes, etc., then use a commercial or open-source version control platform that is actively maintained.