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.
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)
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.
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.
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 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 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.
As a rule I try to be nice and constructive when people show their projects, so don't get me wrong: there is a need for a better freelancing portal and it's great you guys are on it. I'm just not sure how I can give any meaningful feedback based on what you're showing us today.
Dipping into personal experience and anecdotes, I don't recognize the names of any of the people organizing the site. To me, this means that the site probably doesn't have the very best hackers running it and so cannot guarantee that they have some of the very best hackers on there. But, I suffer from the paradox/curse of Blub as well, so I have no idea if the people running this are skilled in their hacking abilities or whether it is just a few grad students who put something together last weekend.
N.B. This comment falls into the same pitfall that the original essay does in that it only considers the field in question to have one dimension. Hackers come in all shapes and colors just as programming languages do.
This means offering the right tools to help companies and freelancers make educated decisions (rating systems, reviews, programming tests, etc). It having dedicated staff to vett programmers and companies.
Specifically in terms of the Blub paradox, I can say that sabalaba and I have used a myriad of different freelance services and have a pretty good idea of the services they are missing. If we are able to curate and nurture a ecosystem with better hackers than any of our competitors, I'll feel proud that we've been able to at least offer our clients a superior service.
I really appreciate your points and I admit this is something we're going to simply have to prove. That's why we're not earning any commissions for our first batch and are keeping our network small enough that we can resolve problems one at a time.
As a hacker and freelancer I can tell you that I would not appreciate programming tests.
There are two reasons why I put up with computers and code:
1)I feel like it. I want to make something interesting
2)There is an incentive. Someone is paying me money for my skills and services.
Taking a test falls under neither of these categories. I see it as a waste of my time and there is nothing to show for it
Also, every single programming test that I have seen is just plain terrible. Not to mention there is no way to enforce against cheating. Therefore making the entire process pointless and a hassle for everyone.
Just my two cents..
EDIT: And I wonder, are the people listed freelance hackers? They all say they're CEO and CTO somewhere. That sounds like a fulltime job.
 At the time I asked this the HN title was "Freelancing, solved."
My co-founder (sabalaba) and I have been working on Hackerlist (http://hackerlist.net) - a selective network of great freelance engineers.
This seems like something many of you have been looking for as there are a shocking number of "freelance" posts (from both clients and programmers) on HN each month -- HN ids: 4596379, 4463692, 4323612, 4214767, 4184757, 4053078, 3914001 3783658, 2539892, etc.
We admit, at this stage Hackerlist is an experiment. We're only asking for your time and patience -- we'll help you land contracts with top companies, handle the logistics, and you'll keep 100% of your earnings. No catch. We'll handle the vetting process, source contracts, and continuously work one-on-one with you to improve our tech until it serves your needs. Unfortunately, to preserve high quality, we're unable to accept more than 32 candidates and 6 of these spots are already filled.
If you'd like to be considered for Hackerlist, email me at email@example.com or submit your github username on http://hackerlist.net
Our long-term vision is to create a realtime system (think the intersection of mechanical turk, stackoverflow, oDesk) where trusted freelance engineers can immediately clone a git repo, start hacking on a technical problem, and upon completion, get paid what they're worth.
P.S. Suggestions and feedback are appreciated -- we don't want to build something you don't need.
So just curious how you are planning to make this marriage work?
As suggested before, we're keeping our first batch of acceptances small so we can better understand the challenges which you face and help you overcome them.
I'm in a similar position to Ewan, so this comment comes as a relief to me. I have a portfolio site that's also limited to only projects clients have approved to be made public. Whereas my LinkedIn has more information on what I've done.
I've sent an application with my LinkedIn.
where trusted freelance engineers can immediately clone a git repo, start hacking on a technical problem, and upon completion, get paid what they're worth
The problem needing to be solved in this field is not exactly where you're aiming. I can count on one hand the number of good clients I've had who had a DVCS ready to clone and work on :)
The market you mention is probably fairly small, and not hugely lucrative. (as you noted, you are keeping your initial pool of hackers small)
But if you want a wider problem to solve: there are many many small companies looking for hackers to come in and get them on the right track (DVCS, proper deployment mechanisms, backups, security, etc.).
Just food for thought, good luck with the site!
In the future, we'll provide an interface which is very similar to oDesk. The main difference will be, we plan on changing the process to remove a lot of the pain points that clients and freelancers currently face (vetting, interviews, payment, and all the other time wasting blockers).
If you'd like to setup a time to chat, I'd be happy to tell you more about our next steps and would love to listen to your suggestions and needs. (firstname.lastname@example.org)
Edit: Nice, just noticed changes on your site. You guys are fast.
Also limiting the slots has no point at all.
The whole thing seems like a totally incomplete concept that was created in half an hour.
And "a selective network of great freelance engineers"; seriously? It's a single static page with images and a couple of links per person...
You're right about one thing -- the service is very much incomplete. Our philosophy is to continue to talk to customers (hackers and companies) and minimize the amount of building we do without their blessing.
In terms of the limiting the network size, we know we're going to encounter problems (we're counting on it!). As a result, we want to make sure we'll have the resources to spend time with each of our customers during early alpha stages.
I'd love to hear your feedback on how we can improve the site. Do you hire contractors or are you looking for opportunities? Let me know how I can help.
"Hackerlist allows you to hire a skilled worker without the need to interview them one by one. Join, define a task, price it, and get results from great engineers. Hackerlist works with a pool of some of the best technical talent to deliver what you need. No resources wasted on poor results. Streamline your work process by taking care of finding the niche talent you need to get things done"
1) Claim a project you like
2) Clone the repo, start hacking
3) Get paid
1) Apply to a project
2) Wait for a response
3) Schedule a skype interview
5) Start hacking, email a zip file (I've honestly been asked to do this)
6) Get paid
The open alpha is desktop Mac/Win/Linux only for now as we use dynamic compilation tricks not available in the mobile build targets till we do workarounds or modify Unity's source code. We're going to release the beta on Steam.
We need coders with C# and Unityscript skills sufficient for turning the Unity runtime into an MMO IDE. We're at 4 coders right now plus 3 volunteers.
I'm as much interested in having the community highlight Unity game programmers for other Unity game developers with similar hiring needs as I am for our own.
Many developers use github as a private repository of code (by choice or by necessity from their clients) or don't use github at all. Does either of these make them a bad developer? Not in my opinion.
I understand you have to draw the line somewhere (we do at matchist too) in terms of setting a base qualification but I personally don't feel github is that base qualification.
Just curious how this is differentiated? That it's restricted to users on HN?
Geeklist is a great idea for building community and sharing. This just isn't a problem we're trying to solve.
Hackerlist provide a premium network to match skilled engineering freelancers with companies. It seems like a lot of people currently rely on hackernews freelance posts to accomplish such. Current competitors like oDesk tend to underpay, lack the same quality standards, and don't specialize exclusively in skilled engineering jobs.
I think toptal.com does something similar but it is focused on recruiting freelancers rather than providing a useful odesk-like interface.