On Developer bias
Definitely agree with @burrrata and @decentralion on that it creates a stronger developer bias.
Even if it may be a perception difference, as @anon60584824 mentioned, signing up for an account and adding comments isn’t too different between these platforms. It’s still a real bias.
However I feel like this makes a lot of sense at this stage.
OSS as a natural fit
Like is being described in the manifesto drafts, open source is a niche where SourceCred can find the right environment to develop. It’s by no means the only place where it could apply.
Imo, the situation where Owners systematically exploit Workers and Resources is rampant everywhere. And they could all benefit from the premise of being recognized and rewarded more fairly. In the future I would be massively proud if SourceCred can make a difference for nurses, teachers, farmers, miners, nature, wildlife, and all those others currently undervalued and exploited.
But, we need a springboard that offers:
- Open data
- People who are already willing to work permissionlessly
- Technical affinity to be able to grapple with graphs and game theory and algorithms
- Funding
And focusing on OSS let’s us dogfood SourceCred.
So I think SourceCred v1 should be a tool / protocol that delivers on it’s promise in the Open-Source Sustainability space. And expand from there.
Users of a tool vs having an influence
One gotcha I think there is here, is that developing applications is very multi-disciplinary. SourceCred is no exception here. And I think GitHub doesn’t cater to all of these disciplines. Tools like GitHub / Bitbucket / you-name-it, in the teams I worked with are used by primarily developers and project managers (in a business setting). In my experience designers (usually), lawyers, business people, communications managers, rarely if ever touch a Git repository.
That doesn’t mean that the designs, business needs, market, copy, legal concerns have no effect on what gets merged in a Git repo. Heck if you’re a developer that disregards these, you’ll probably be out of a job soon.
It also doesn’t mean Git makes a bad tool for the task at hand. Just that other people on the team don’t use it directly. They’ll debate their wants and needs through different channels and ask the devs to make the changes to incorporate them.
We have several of these other channels in place as well. The changes in Git will be reflected in the canonical cred explorer, we have GitHub, Discourse, Discord, and soon CredCon (woo! 
) as places where you can get in touch and share concerns. I think this is absolutely critical to maintain. It’s much more important than finding a unicorn free-of-bias platform. This topic is a good (meta) example of that :]
So long as we maintain a culture and practice of broad inclusion, the properties of a particular medium become much less important for that inclusion.
Teaching people to use GitHub as @decentralion suggested, I think helps as well. But ultimately I think multiple channels is the way to go.
Technical notes
Aka, this is where I start nitpicking.
In that regard the Git part of GitHub is very much an improvement over Discourse. Git’s decentralized design has made it useful with and outlive many of the transport protocols. Whether you’re using USB sticks and sneakers to transport your repo’s, emailing commits, using a HTTP/web2 portal or want to store them on IPFS/Blockchains. Git has a track record to be an excellent fit for all of them.
I wish Discourse could fork and merge the way Git does. I’ve been considering a bounty for this.
that was not designed for that use case.
GitHub is exactly designed as the type of collaboration tool we’re looking for. When the choice is between Discourse and GitHub, it’s clear that GitHub has a collaborative review process (the PR) as a first-class concept. Which would need to be retrofitted into Discourse.
PRs welcome
With the above as context, I think we should still go forward with file-based Initiatives tracked on GitHub. As I think it’s an improvement. By we I mean, I’ll champion that and should have the first PRs ready soon.
But in OSS style. No permission is required to work on an alternative if someone has a better idea 
And to be inclusive, I’ll remain open to feedback.
For now though, I have enough input here to work on this change.