OP here: I, like many others, experience times of great abundance and shortage of freelancing work. The idea of having a vetted/endorsed network of freelancers I can trust to send overflow work was something that appeals to me on both sides. I thought using GitHub as the vehicle for maintaining such a community was an open and hacker-friendly way of doing it.
Just curious as to how the payment part of this would work? It's a great idea - something you could build out (a vetted list of top-quality freelancers available to work on your project? People would love that).
If there is a vetted list of freelancers all of the same, trusted, standard, it could be that having individual minimums creates a 'race to the bottom' thing that other places have. I would have a fixed price per hour which is slightly above average, with a guarantee of high-quality return and efficiency.
If you can get members to work with and look over projects they're not attached to (feedback etc) you could increase the value of the service as a whole.
The original concept was to scale via the open and self-administered community itself while keeping a hands off approach to all other aspects. Truly just a simple network of solid folks and not a product trying to solve every problem (though I imagine it could be productized). The hope was that by only letting in solid freelancers that these items could be handled by the freelancers themselves without too much worry about getting screwed over or hassling one another.
You bring up a valid concern about the race to the bottom, which is exactly one of the things I want to avoid. The thought around the minimum rate information was to inform others about what type of level of compensation one would need to even consider work. I think I might rework this right now and also inform folks that only developers with rates above XYZ are allowed.
3 comments
[ 3.9 ms ] story [ 14.0 ms ] threadI welcome any feedback on the concept!
If there is a vetted list of freelancers all of the same, trusted, standard, it could be that having individual minimums creates a 'race to the bottom' thing that other places have. I would have a fixed price per hour which is slightly above average, with a guarantee of high-quality return and efficiency.
If you can get members to work with and look over projects they're not attached to (feedback etc) you could increase the value of the service as a whole.
You bring up a valid concern about the race to the bottom, which is exactly one of the things I want to avoid. The thought around the minimum rate information was to inform others about what type of level of compensation one would need to even consider work. I think I might rework this right now and also inform folks that only developers with rates above XYZ are allowed.