Tuesday, August 11, 2015

Gun.io Sucks

Let me state that the concept of Gun.io is unique in that use your github.com repos to qualify as a developer and gun.io assists in the client coming up with the repo and determining if client has enough budget to get something developed. No worrying about the client having money, its handled by gun.io. And a guarantee for the client.

What could go wrong? Well, quite a bit actually if its the wrong implementation.

Let's do this the system analysis way. What is the intermediate product?  One is the project being developed, the process, and the rfp being developed, again the process. Why? Because that is the two things the client interfaces with and if those are not right than other competitors beat Gun.io in amount of projects completed and developers signed. Currently Toptal and UPwork do exactly that feat.

They key problems stem from having the client annonymous until a developer is chosen. Why? Because the expertise to determine if the rfp is technically feasible and costs feasible is not in Gun.io staff's hands as that expertise among specialized areas such as mobile native front ends and other front-ends is in hands of the developers who are members of gun.io.

Thus we have gun.io assisting in detailing the rfp without relying upon the expertise of the crowd of developers they have gathered. HOW THE EFF CAN THAT WORK? In fact it does not in fact work. I just ran into another example where the client wanted to do this experimental thing and it was mentioned in the rfp that Gun.io had a hand in detailing where client wants it done in Unity via a dll on android and the C/C++ apis are locked up by Google requiring root permissions and thus can only be done via java apis as a native android java application not a unity dll. Not to mention that fact that experimental projects are always rfp'd differently because in fact is experimental, often times its a retainer rather than rfp. How the eff could Gun.io miss that?

If Gun.io would have the client named instead of anonymous, one can use the contracts between clients and developers to enforce communication using gun.io, one could implement a RFP issues board where developers could open issues during the several weeks-to-months process of detailing the RFP to alert the client to technical and budget issues in the RFP. In fact some of Gun.io's competitors in factt do this feat.

The other major problem is that the RFP editing process is not git versioned. Why not? RFP's on Gun.io's system get changed all the time without any clues to the thought process involved or the assumptions made leaving the developer in the position of having to guess whereas if it was git versioned we as developers would be able to see some of the thought process in terms of changes to the rfp.  The other aspect is when that RFP changes the developer is not allowed to change their proprosal.  SAY WHAT THE EFF?

Another aspect is there is no two-way commuication, sending email to Gun.io is like sending it to a black-box where nothing comes out. A way around this is to set up an issue board where the Gun.io staff has two or three dasy to clear issues posted on a day. And this for both the developer and clients who are members of Gun.io.

Another aspect of the RFP system Gun.io has set up is that you may have thousands sending proposals which means essentially Gun.io's promise that developer's questions will get answered by the client during the project award process are somewhat meaning-less and somewhat naive. A better way to handle it is drop the anonymous client attribute and have an issue board set up for each open rfp combined with having the rfp git versioned so developers see the edits and allowing developers to modify their proposals after they are submitted(marked as a new proposal version, of course).


Another aspect of the product is the developer process as it touches both Gun.io and the client. Would it be so effing hard to set up a system whereas when the project is awarded to the developer and the developer accepts that a private https Slack channel be set up for communication between the developer and client. Slack has an api to do things like that.

Gun.io really could be a neat system to use for those firms needing development, if someone really paid attention to the effing product!

And I will not even get into the failing write for Gun.io project due to lack of action Gun.io's staff part.