Your project doesn't mean your playground
Having your own open source project is awesome. You get to build a thing you like, obviously. But you also get to have your own little playground, a chance to use your favorite tools: your favorite VCS, your favorite test framework, your favorite issue tracker, and so on.
And if the point of your project is to share a thing you’re having fun with with the world, that’s great, and that’s probably all there is to the story (you may stop reading here). But if you’re interested in growing a legion of contributors to build your small side project into an amazing thing, you need to forget about all of that and remember these words: Your contributors are more important than you.
Your preferences aren’t that important: This means you probably shouldn’t use
bzr if everyone else is using git. You shouldn’t use your own home
grown documentation system when everyone is using Sphinx. Your playground
is a tiny thing in the giant playground that is the Python (or whatever)
community. And every unfamiliar thing a person needs to familiarize themselves
with to contribute to your project is another barrier to entry, and another N%
of potential contributors who won’t actually materialize.
I’m extremely critical of the growing culture of “Github is open source”, I think it’s ignorant, shortsighted, and runs counter to innovation. But if your primary interest is “having more contributors”, you’d be foolish to ignore the benefits of having your project on Github. It’s where people are. It has tools that are better than almost anything else you’ll potentially use. And most importantly it implies a workflow and toolset with which a huge number of people are familiar.
A successful open source project outgrows the preferences of its creators. It’s important to prepare for that by remembering that (if you want contributors) your workflow preferences must always be subservient to those of your community.