Perhaps unfairly, I will group crowdfunding campaigns and bounty-based development incentives together here, not because they are the same thing, but because to the extent that they are problematic as ways of funding free software development, their problems are similar.
Crowdfunding refers to many funders — often mostly individuals — coming together to fund a particular piece of development. Crowdfunding campaigns are usually either "all or nothing", meaning that each funder pledges money toward a total threshold and the pledges are collected only if the threshold is met, or "keep it all", which is essentially traditional donation: funds go immediately to the recipient whether or not a stated goal amount is ever met. https://goteo.org/ and https://kickstarter.com/ are probably the best-known examples of all-or-nothing crowdfunding services, though there are many others (I like Goteo because their platform is itself free software, and because it is meant specifically for freely-licensed projects, whereas Kickstarter does not take a position on restrictiveness of licensing). There are also sites like https://www.indiegogo.com/ that support both models
Bounties are one-time rewards for completing specific tasks, such as fixing a bug or implementing a new feature. Bounties are often offered directly by the interested parties, since there is no need for a pledge-collecting system, but the site https://www.bountysource.com/ also serves as a clearinghouse for open source development bounties.
While both crowdfunding and bounties have funded some open source work, they have not been a major economic force compared to salaried or contracted development. This does not mean you shouldn't consider them: depending on the problem you're trying to solve, and on the shapes of solutions you're willing to accept, crowdfunding or bounty funding might be a good answer. The problem they share is that they are structured around development as a one-time event rather than as an ongoing process. This would be problematic for any kind of software development, but is especially so for open source development, which if anything is is optimized more for low-intensity, long-term investment rather than for high-intensity burst investment. Both crowdfunding campaigns and bounty prizes are more compatible with high-intensity, one-time bursts of activity, and do not provide for ongoing maintenance or investment past the completion of the campaign goal or prize condition.
A crowdfunding campaign can sometimes be a good way to get a project launched, but generally is not a way to fund development after the initial launch. Successive crowdfunding campaigns for later stages of development or for releases will inevitably tire out even a willing and supportive audience. There is a reason why long-running charities, for example the public radio network in the United States, seek to develop sustaining funders (euphemistically called "members" even though they often have no governance role) to provide a long-term, stable revenue stream, and then raise funds for specific one-time efforts separately from that.
If you do launch a crowdfunding campaign, take a close look at
how other open source projects have run theirs. There are a number of
useful techniques that can be learned from the successful ones. For
example, most campaign sites have a mechanism for offering different
rewards to backers at different monetary levels. You could offer a
mention in a
SUPPORTERS file in the project, and
perhaps at higher levels a mention on a thank-you page on the
project's web site. But more creatively — I first
heard this idea from Michael Bernstein, and used
it — you can offer to dedicate a commit to each backer
at or above a certain level, by thanking the backer directly in the
commit's log message. The nice thing about this is that it's
decentralized and easy to administer: any developer on the project can
help fulfill that reward. Individual developers can also offer free
or discounted consulting about the project as a reward, though be
careful not to sell too much of your time: the point of the campaign
is to raise funds for development, not to turn the development team
into a consulting team.
One thing that many crowdfunding campaigns do that I think is not appropriate for free software projects is to sell early access. That is, one of the rewards will be a "sneak preview" or "beta access" to in-progress versions, before the public release. The problem with this is that, for open source projects, the public is supposed to already have access to in-progress work. Access to an open source project should be limited by the time and interest of the parties seeking the access, not by the project. So learn what you can from other crowdfunding campaigns, but remember that some of the techniques used by most campaigns may not be suitable for an open source project that wants to keep the good will of its users and development community.
Finally, word of caution: if your project accepts donations, do some public planning of how the money will be used before it comes in. Discussions about how to allocate money tend to go a lot more smoothly when held before there's actual money to spend; and anyway, if there are significant disagreements, it's better to find that out when the money is still theoretical than when it's real.
 One service trying to solve that problem is https://snowdrift.coop/, which aims to provide sustainable funding for freely-licensed works using a carefully designed matching pledge model. Whether Snowdrift will succeed is unknowable as of this writing in mid-2015, since the service is still in a preliminary stage, but I am watching it with interest. Snowdrift also did a thorough survey, in the Fall of 2013, of funding platforms for free software, and posted their results at https://snowdrift.coop/p/snowdrift/w/en/othercrowdfunding; it's worth a read if you're interested in this topic.