As someone who's hired several freelancers before (and is continually hiring), the process has often been very time consuming and frustrating.
I welcome new solutions.
For me, the main problems are centered around communication and trust.
In my experience, freelancers are difficult to work with because they're hard to communicate with as they may have several projects going on at once, enjoy living a rather unstructured lifestyle, don't like to email, amongst other things.
If I have a good spec sheet that details exactly what I need done, when I need it, at a fair price, will you deliver?
I find that question to be very hard to answer when reviewing people. Though, I believe a major reason for that is because I'm not technical (my background is in interface design and not backend stuff).
I'm aware that part of the problem stems from me. As freelancers are worried about new features being added on later, changes being made, new problems arising, lack of payment, etc.
With that said, I've have some good experiences. The best being when the spec I've written is in fact good and not making any changes to it until it is delivered as written, on time. Payment being promptly made. And then discussing changes.
On the other side of this, I've had clients that can't provide needed information, want me to wait for some other contracted individual to finish part of the job or provide information, then can't understand (after the two week project has run to six weeks because of their own delays) why I can't now give them 100% of my attention and blame me for the delays.
Now that they've pushed this whole thing so late that it's interfering with other projects, or plans that existed prior to taking Delay Client's project. They had me three weeks ago and chose not to utilize me. Why's that my fault? (not directed at parent - directed at Delay Client)
I've been contracting for several years and I think perhaps enough time to emphasize with my clients even when they can't tell me what they want, so permit me to offer the other other side.
People can't provide a spec because they don't really understand what they want. Sure. And certainly, part of that in many projects is poor communication between stakeholders and a refusal to make decisions.
But especially for public facing sites it's often difficult to impossible to figure out what behaviors or workflows are effective and which are not. Prototypes have to be built, put before the public, A/B tested, etc. This process is time consuming and often results in fundamental changes to the spec that can affect large amounts of code. A spec can't really be written, handed over, implemented, signed off on. So communication and flexibility really has to be built in to the relationship between the stakeholders and the developers.
The thing that I found is really essential to a good relationship with clients is instant messaging. All developers and stakeholders need to work regular hours and be available on IM. Projects where everyone is on IM, in my experience, go much more smoothly than projects where IM isn't used or is only used by part of the team.
The real magic behind IM is that it's a communication method that doesn't necessarily demand immediate attention when a message is sent, so it doesn't interfere with a developer's day the way the phone does. It just changes the status icon color and allows you to respond when you get to a stopping point. But then when you do respond it seamlessly turns into a two way conversation.
I've gotten to the point where "is everyone on IM?" is my principal litmus test for deciding if a project is going to be a pleasant one to work on or not. This is far more important than pretty much anything else, including the quality of the initial spec.
You have to deal with that sort of situation proactively. Ring them up and explain their delays have pushed the project into a period where you have other commitments. Ask how long it will take them to resolve their delays etc. and offer to reschedule the contracted time after that. If they screw you around later politely decline their work.
If you don't respond to the blame they are giving you then they will continue to heap it on you. And that is not a working relationship.
I don't think there's one magical solution. The more we work with you guys, the better we will become at reducing friction and eliminating wasted time in the process. It shouldn't take 5 days for companies to vet potential contractors, like is often the case with oDesk.
You mention a lot of important issues like trust. I'm hoping by being extremely selective (and limiting the number of accepted hackers initially), we'll be able to keep quality and trust high (or make necessary adjustments).
The central value proposition here for employers is delivering talent that you can put faith in.
This definitely offers an interesting solution for those on the other end of the equation as well. As a contractor, a service like this would enable me to work like I was employed by a company without the corporate bullshit. Ideally I would get paid for the tasks I complete with little upfront time investment and know how much I'll get for it. Maybe if this project is really ambitious they could even do only part of the task and someone could do the rest, paying the developers appropriately by percentage.
"If I have a good spec sheet that details exactly what I need done"
If you have this you are way ahead of most and most.
If you are not technical then the timing should probably be up for discussion rather than being part of the spec. The developer has the expertise there.
Pricing should (imho) always be up for discussion.
I've been presented with similar versions of your question -- "If I have a good spec sheet that details exactly what I need done, when I need it, at a fair price, will you deliver?"
I think the proper approach, especially if you are not technical, is to just go over the spec. Talk about what I feel is properly fleshed out and where there may be some ambiguities. This way, hopefully, we end up with a situation where I understand your interoperation of the spec and you understand my approach. Any questions, we write down and either go over before commencing work or structure things such that we can address those questions in a reasonable way.
When freelancing, it really is about delivering what the customer wants, not my interpretation of what they want.
I welcome new solutions.
For me, the main problems are centered around communication and trust.
In my experience, freelancers are difficult to work with because they're hard to communicate with as they may have several projects going on at once, enjoy living a rather unstructured lifestyle, don't like to email, amongst other things.
If I have a good spec sheet that details exactly what I need done, when I need it, at a fair price, will you deliver?
I find that question to be very hard to answer when reviewing people. Though, I believe a major reason for that is because I'm not technical (my background is in interface design and not backend stuff).
I'm aware that part of the problem stems from me. As freelancers are worried about new features being added on later, changes being made, new problems arising, lack of payment, etc.
With that said, I've have some good experiences. The best being when the spec I've written is in fact good and not making any changes to it until it is delivered as written, on time. Payment being promptly made. And then discussing changes.