I agree we need to attack this problem, but is another proprietary service to connect via proprietary APIs to your other proprietary services really the best answer? This looks like even more complexity than before (when something breaks, who do I go to for help?), except now I'm paying yet someone else to stand between me and my data.
We didn't get where we are today, in any field, using this approach. We don't have 30 different measurement systems, and a company whose job it is to coordinate conversions between them. We don't have 30 different text file encodings (any more!), and a company whose job it is to automatically convert them as necessary. We say: here's the standard, and now you can use it or be ostracized in the market.
If writing custom adapters to interface with GitHub/GitLab/Jira/... is anything other than a temporary solution, while you work on some grand plan to get issue-trackers all on the same page, then it's just a money-grab on the road to failure. Someone will cut off API access, or drive up your costs, or refuse to offer an API, and users will be stuck with "one command center (for the 3 most popular services they use), plus 3 oddballs", and it's just not going to be worth the hassle.
It's a band-aid. Normally you stick a band-aid on something that will heal itself, and then rip it off tomorrow. This particular problem is getting worse. This is a very pretty band-aid, but you've applied it to a sucking chest wound.