Why would YOU need access to that backup? That is entirely Kitware’s business and not yours.
Kitware has taken all the proper precautions to keep on-going backups configured for both on-site and off-site disaster recovery and preservation. Maybe you do not like their decisions, but that does not mean that the infrastructure that they have setup is wrong. Just that you don’t agree with it.
I think it would be useful at this point to go ahead and drop your CV down below. Apparently, you are simultaneously a sysadmin, software engineer, contract lawyer, and backup/disaster recovery expert.
Oh, it is certainly a of a lot more people’s business than just Kitware’s. Kitware didn’t raise their own money and develop VTK in vacuum and then share it with the world out of the goodness of their heart. They’ve taken countless government contracts and corporate contracts alike under explicit terms that the software and work products would remain open source and publicly available.
I don’t think Kitware’s customers would be too happy to hear that people in this community don’t think it’s anyone’s business but Kitware’s whether or not this repository is accessible.
Thanks, but I’m not on the market 
have my hands full building a company.
I may have a bit of an orthogonal perspective here, but maybe it can help Kitware or someone else who’s looking to evaluate self-hosting git vs. GitHub.
I’ve been quite disappointed by GitHub’s availability over the past several months (see The Missing GitHub Status Page) and I would have been absolutely crushed by GitHub’s threat to charge $0.002/minute fee for self-hosted runners for my closed-source development. That being said, I think GitHub is the best current platform for open source development. However, for closed source, I’m deeply worried about Microsoft training their AIs on closed source regardless of what their TOS state. I’m also worried about data security especially given the state of affairs with LLMs.
What I’ve done is completely self-hosted using Gitea for all my closed source development and rely on GitHub for all open source development (e.g. PyVista. For local backups, I have a NAS with RAIDZ2 and then a full nightly incremental backup to Backblaze along with a second isolated geographically server.
I don’t think it’s one or the other (complete self-hosted or complete GitHub) as each has its drawbacks. Instead, I think it’s best to be flexible and able to move to different infrastructure as platforms evolve. After all, at the end of the day it’s just git.
What I’ve done is completely self-hosted using Gitea for all my closed source development
What has your experience been like with gitea? I was put off by the fact that they host their source code on GitHub instead of gitea. Forgejo seems promising in that their code is hosted on Codeberg, although I think they are quite a bit less mature.
IMO, GitHub is still the best place to host open source. It’s huge, it’s not going anywhere, and it’s free. The relatively small downtime is worth paying absolutely nothing to have the code hosted by someone else. There’s so much that must go into effective remote and distributed source control. Backups, both geographic and historical, is one thing that almost broke me. On GitHub, that’s all handled for you and incredibly for free.
I think gitea sees this and probably thinks, why not use a free resource rather than reinvent the wheel. Where it does well is private hosting and having full control and customization of the entire stack, something made trivial now with a decent LLM. I have a self hosted runner management page and dashboards that would be next to impossible to integrate with GitHub all locally deployed, on an isolated VLAN, all exactly how I want it. It’s fantastic. I can make domain and team groups for customers and I never have to worry about someone upstream changing an API or UI. It’s not for everyone, but I think gitea is fantastic for self hosting with self-hosted runners.
OK. I have been very patient with these conversations but this crosses a line Bane. First of all, you need to learn how to differentiate between comments made by individuals at Kitware as individual contributors and those made by Kitware representatives as Kitware representatives. You worked at Kitware long enough to know the difference. Second of all, you need to stop attacking Kitware in ways that are not appropriate in a community forum and recognize that we are doing our best to make this work for everyone. I have been trying to believe that you have the best interest of VTK in heart but I am now starting to think your intention is to attack Kitware. Please be open about what you are really after. Once we resolve this, we can then have a proper technical discussion about what is in the best interest of VTK.
Hi James,
I am not sure what you mean by “administration of the project”.
I would like to see more contributions to the project in terms of dashboard runners. It does require quite a bit of commitment though as these runners execute code from anyone’s MR and need to be isolated properly for security.
We would also welcome contributions in other areas such as reviewers, help with release notes, etc.
The infrastructure is also open for those that want to be involved more deeply in the management of the project but there has been fewer and fewer core developers outside Kitware over the last few years. I would like to see this change and I have been scratching my head about it for a while now. I am slowly making progress on addressing some of the community aspects like creating code of conduct, review guidelines, and of course a governance process. I don’t know if these are enough to attract more developers though. I suspect the core of it is that there are fewer and fewer C++ developers interested in visualization.
I provide some feedback here to represent a more diverse set of views from the community.
I find Kitware’s efforts of making it possible for external contributors to follow and participate in VTK development very reasonable. I don’t love gitlab (mostly because I don’t use it often and does not feel as familiar as github), I occasionally experienced that I could not access some tools probably because I’m not in Kitware’s internal network, I’m worried when some services become unavailable (which happened to me with github more often than Kitware’s gitlab, probably because I use github more), and speed, reliability, simplicity, etc. could be always improved. But I completely understand if Kitware does not want to improve these further. Not because they don’t care or could not do better, but because the current infrastructure is good enough and there are other things that need attention.
I don’t want to describe our infrastructure in detail here (which I can’t anyway) but the gist of what I learned is this: The DDoS was significant and our admin team had to setup something quickly to restore web services. This had a side effect of significantly slowing down Gitlab because the response was using a shared resource (a proxy) with Gitlab. This has been resolved since then and a future attack on any web sites should not affect gitlab.kitware.com.
I wish that folks, especially those that know Kitware well, would have some faith on the team that has stood up many resources for the community for almost 30 years.
Thank you for the input Andras.
We are trying to improve things but sometimes it is a two step back and one step forward thing. Especially since the community started pointing their AI agents to our resources. Don’t get me wrong. I also use AI and regularly point to gitlab and github. I just hope that we can find ways of doing it in ways that also support performance of servers. I have no doubt that most of the github issues come from the same thing. As is, we are trying to walk a middle ground that keeps performance acceptable while supporting AI agents.
We have also been considering moving VTK to github.com but we are hesitant because of many reports of performance issues there. My personal opinion is to move to github because that’s where the community is. But not compromise quality (i.e. CI).
To be clear, I was not referring to backups. We believe that the backups we perform for Gitlab are sufficient to ensure recovery in a disaster situation. Furthermore, these are backups of the whole system which also include all private repositories. Not something that can be shared.
It sounded more like you want a read-only representation of Gitlab so that you can search for issues or MRs, historical or new. I am not aware of such a representation for Gitlab or Github projects but if such a thing exists and does not put an undue burden on the Gitlab server, it may be something to consider.
I would also like to hear the justification for such a thing. Why does the PyVista community (or just you?) need another way to access and preserve VTK issues and MRs? It would be useful if others from the PyVista community spoke up here and explain their needs? We’ll do our best to accommodate them.
I don’t understand it that way. I understood the goal as “something happens that results in Kitware as an entity suddenly and unexpectedly ceasing to exist (i.e., all Kitware-controlled instances and backups of VTK’s GitLab cease to exist, or at least cease to be accessible); how is VTK GitLab preserved?”. Having an additional, read-only mirror may be a happy side effect, but isn’t the primary goal.
One point I’ve tried to make is that such a backup can’t depend on Kitware to exist, as that defeats the purpose. (Aside from Kitware facilitating the transfer of data, which I don’t think is an issue.)
@berk.geveci Regarding both of these items it would seem beneficial if the public Open Source project stuff could be separated from the Kitware private closed source stuff.
In regards to the runners, free GitHub hosted runners for open-source projects (or GitLab equivalent) would seem to fulfill any security issues because they are isolated. They of course have their own downtimes, but the transparent nature and open-source standard of the GitHub hosted runner “Ubuntu-26” or any of the Windows x86-64/arm or Mac x86-64/arm runners seem to provide a good diversity that is available for all to use. With transparent workflows, immutable tags, etc many open source projects on there are successfully releasing new packages to the community. It would be lovely for VTK on GitHub to have its CI runners defined and then when I fork VTK there I could reuse the same infrastructure to run CI in my fork using those GitHub hosted runners. My usage of them would be using Microsoft resources and not taking up Kitware’s resources. It would be understandable that Kitware would continue to use their own self-hosted runners for their private Kitware GitLab repositories to fully hold the data associated with that private work.
It’s interesting that GitHub - Kitware/VTK: Mirror of Visualization Toolkit repository · GitHub has >3200 stars from the community while https://gitlab.kitware.com/vtk/vtk has only 306 stars.
I don’t believe that this is the place to discuss this but to answer briefly: we do have a separate gitlab for internal projects. However, people create plenty of private project on gitlab.kitware.com for various reasons and not limited to Kitware folks. One common reason is working on a VTK branch that one does not want too open yet but still want testing. Our CI infrastructure is only tied to gitlab.kitware.com. So there will always be private repos there.
@jamesobutler I totally agree with you that Github is the better place from a visibility and community convenience perspective.
This is an interesting idea. And I would encourage all of us to explore it. All it takes is a fork of VTK with different permissions and a few scripts to setup the CI. At this point, we are thinking about doing more with the Github mirror - enabling MRs and maybe even issues. Those would by sync’ed to Gitlab for CI etc. Note that Github does not offer enough resources to properly test VTK. Current resources would likely take a half day to test all the combinations not to mention the lack of GPUs. So Github CI testing would be a precursor to even the runner group that we call “quick” on our CI infrastructure.
I believe that we need to wait for the dust settle (if it ever does!) with the interaction of AI use and CI resources on both gitlab.kitware and github before we anything more.