I used to be very entertained by stories given by different webrtc consultants. The “Cat roulette” example by L. Barr last year during a conference in Miami was exhilarating. I was thinking: those guys have all the fun!

What people don’t tell you when you go into that business is the wide variety of clients you end-up facing. Now that I am on the other side of the fence, the grass is not exactly greener. In an effort to give people a glance of how hard it can be sometimes, and to keep my mental sanity by letting it out, I’m writing a post about the horror stories we’ve faced so far, or, to put it in  amore diplomatic way: about the inherent bias clients can have about our perceived value, or WebRTC perceived value.

Client is king

“Client is king”. Except that being the client in a contractual relationship does not make one more knowledgeable, nor capable on a given subject.

When you are in the consulting business, most of the time people come to you for expertise, but keep that “client is king” attitude and expect you, because you’re the expert, to do the impossible. It’s very well known, and there are even some educational / caricatural videos about it. Here is my favourite.

“Hey, it’s very important that our product support <put-your-impossible-feature-here> because ours clients keep asking for it. Add it to the roadmap without additional cost for us. After all, we’re paying you for that and it should be there in the first place, since we told you it was important before.”

Yes, I heard you, and I recognise your expertise but I will still go with X

I think that the blog post Tsahi wrote about his frustration to see a client choosing peerJS is also spot on a shared pain among a lot of consultants: seeing a client that does not know better not only not following your expert advise, but also going completely against common sense … for people that have the minimum technical capacity to see e.g. that a GitHub repository with webrtc code that has not been updated for even 6 months, should be considered dead.

“Expert: I attended the standard committee with the representatives from MS, Goog, Moz and Apple, and they all said it will not work. I attended the bi-weekly meeting with the Jitsi team and asked them why they would not do it, and they said: ‘we tried, the quality was underwhelming and not at the level of quality we expect for an industrial product, we had too many support to do to manage client expectations, so we just decided not to support it.’, so I guess there is clear consensus from the field’s world experts that it is not something you want to do.”
“client: We’re not convinced. Can we have access to the code of Jitsi when they were trying that? Can you help us test it, because we don’t have the capacity to test it either.”

Open-source does not make you smarter or more capable.

Truth is: open source software gives you the opportunity to modify the source code yourself, but it does not give you the capacity to do so.

• If you are not familiar with the code base,
• if you do not know the specifications they are trying to implement,
• if you do not know how to tests your modifications,

  don’t even try, you’re wasting your time.

I keep buying Ikea furnitures to my mom. I keep building them up for her. The fact that the furniture is provided with the plan, and all the tools, does not make my mom more capable of building it by herself.

“How complicated can it be: webrtc is open source, I will do it myself.”
one week later:
“discuss-webrtc: where is the make file for the webrtc library?”
two weeks later:
“discuss-webrtc: why is it taking so long to fetch, and then so long to compile, every time I make a modification I need to wait 4 hours.”
three weeks later:
“how do I modify the build.GN file to add my own code? What are the args I need to pass to ‘gn gen”? Where is my dll when a build a shared lib?”
<cheat and just fork and hack libwebrtc directly>
5 weeks later:
“I have a project with a forked version of WebRTC 59, it does not work against chrome anymore. How do I rebase?”
6 weeks later:
“F*** it, let’s go back to our consultant, they were fast and apparently knowledgeable since we never bumped into all this problems with them.”

Reality-check

Unfortunately, when faced with clients that unreasonnably perceive what you do as easy and cheap, you can only fall back to a reality-check: go ahead, put your money where your mouth is, try, and when you will have failed, I’ll be here to help you.

We feel terrible to have to say that, and very often, we are perceived as arrogant a**holes, but first, we’re french, so we’re used to that reaction, and two when someone ask you for a Ferrari at the price of a Fiat punto because both are cars, there is so much you can do.

I recently had a client that asked us to do something quite complicated, namely to add WebRTC support in a flash streaming software that was otherwise open-source. A one point, their position became: it’s open-source, you are charging us too much, we can do it ourselves.

Anybody that has tried to deal with libWebRTC themselves is starting to giggle at this point and is securing some popcorn for the long story to follow. The tech lead was a great JS software engineer, who had never done any media coding, any network coding, and barely done any C++ in his life. Hey, it’s software, how difficult can it be, right? Here i mean to stress that those decisions are not the exclusivity of non-technical persons.

Long story short (see above), one month and a half later, they accepted our original quote for work. That’s one month and a half that could have been saved for them, plus an additional month because my resources were allocated elsewhere meanwhile, and they had to wait for them to be available again.

Conclusion

The knowledgeable WebRTC consultants out there, those with tracking records of contracts with the core WebRTC companies, which participate to the evolution of the technology and which are trusted enough by Browser vendors, and other webrtc open source projects alike to contribute code back, are few and far apart. I’m not sure I would need two hands to count them.

If you have the chance to be able to secure consulting or development time from one of them, well as steve jobs once said: ““It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.”

Moreover they are part of a long-standing small club that meet often on the side of the tech conferences, mainly to discuss technical points and push back further the definition of what is possible, but also to exchange their stories and feelings about who they are happy to work with, and who they’re not and might be avoided.