TokBox – onvural.net – melih

just thinking out loud, Technology, Uncategorized 2

Building a community by selling to communities

I had a phenomenal discussion with Bartosz Solowiej, formerly of TokBox and currently of Gigs.ly, about many a thing, but specifically about the community problem that I am having. Not a problem in the sense that something is wrong, but rather a problem in bringing horses to water. It really helped me realize that the problem isn’t about convincing the horse, but about finding the water.

Just to give a quick overview of the previous post, the goal was to bring the TokBox Platform to more developers in the hopes that it will bring video chat as a service to more people. I’ve been working on this problem for two years now, and have always focused on building out a developer ecosystem which is strong enough to both want to build video chat into whatever services they build, and welcoming enough to make developers want to be a part of the ecosystem.

After having a really amazing talk with Bartosz about connections, communities and their natural growth, I realized that the best approach may be to flip the whole problem onto its head. Returning to the horse to water analogy, I need to find pools of water, and convince them that they need video chat as a service.

Let me back up a bit. My big ah-hah moment this weekend was realizing that I made a big mistake in thinking that one could manually grow a community. Communities don’t have foundations of hard work, or aren’t a set of people just brought together. This approach to building community is very water/oil in nature. When you shake it just right, you’ll convince yourself that the different parts have mixed, but in the end the two parts end up separate. Realizing that I was doing just that, I stopped to think about a different approach. Taking two giant steps back, I came to realize that communities grow organically. People find a common interest, and from that common interest they build a foundation of mutual understanding from a set of beliefs. This, and not the actual work to maintain and grow the community, is the foundation. On top of this foundation, and here is where the hard work and luck comes into play, is where communities are acted out.

My efforts, so far, have been focused on setting in motion the actions of the community. What I have not realized is the fact that there isn’t a foundation. I haven’t found the mutual interest. I’m trying to get people to build a community without understanding what the common thread is. I assumed that having developers building video chat into their applications was the common thread. It’s not.

What then is the common thread? I’m glad you asked. It’s communities who can grow stronger because video chat, or video messaging, is a fundamental part of their genome. Behind the scenes are those will see that a better community will grow because of the services we can provide, and they will find a way to make it happen. From there, video chat will become something that is part of the toolkit of community builders, who can then continue to spread the technology.

Find the water, and when the horses see something they like, they will continue to come back. The next step is figuring out how to make them come back.

just thinking out loud, Technology, Uncategorized 1

Building a community

I was talking to someone today about the TokBox Platform that we’re building. It’s been something that I’ve been working on since I joined the Box, and something about which I’m very passionate. I was discussing with them my three goals for the Platform from a developer point of view over the next six months. The three goals are:

Build out a second layer of abstraction into all of the SDKs as has been done for the PHP SDK, and continue to improve the widgets to make them as customizable and flexible as possible
Write tutorials, blog posts and show off use cases on a weekly basis on the TokBox blog
Have a large, involved community on the developer mailing list who answer questions for each other

I think the second task is really the easiest one to do. Why? It comes down to organization and discipline. I’m going to spend some time this weekend working through six weeks worth of blog posts (at one per week, that isn’t too hard), and start outlining the content. I want to start with what a user can do with the basic embed, both the call widget and the recorder/player combination, and then work my way into some use cases and sample applications. Hopefully there will be some readership at that point which will allow me to understand what new posts the readers want.

That’s a weekend’s worth of work, and then of course somewhere between one- to two-hours of writing per week. I think the big win there will be driving traffic to our blog, and getting more exposure for how simple the Platform really is to use. I also hope that personally it will help me improve how I communicate technical concepts to a broader audience.

The SDK work, in my opinion, is just a labor of love that is necessary to improve the Platform, and to march towards my goal of doing everything in ten lines of code or less. Even if those ten lines of code come from layers of abstraction, I think simplifying the underlying actions of the Platform will make it much more attractive to potential developers, and that leads me to my final goal…

Building a strong community around the TokBox Platform. I’ve been working in the developer list and with partners for two years now. It’s a very humbling experience. I’m totally convinced that adding video chat, or video messaging, capabilities really adds a lot of value to a whole laundry list of services that are already out there. The amazing bit is that most of the individuals with whom I’ve spoken in those industries agree. They just don’t have time, money or a compelling use case to make it happen.

And so, humbled, I’ve focused on the little things, and making the little things count. Respond on the developer list as quickly as possible. Listen to feedback. Maintain good documentation. Build sample applications. All with the hopes of building a community that then starts to do these things for the Platform because the community has also discovered the potential of video chat and messaging. We still need to better address some of these issues, especially documentation, but we’re slowly starting to get to a place where I think the foundation is really well developed.

What then needs to happen to reach the tipping point, and go over it? I don’t know. I want to spend some time thinking about this over the weekend. I think the obvious first step is patience. I’m not good at that, but I’m learning. I think step one-a is luck. Sometimes you just need the ball to bounce your way, and of course laying a good foundation makes it more likely that when the time comes that lady luck will favor the solution we’ve built.

I’ll do a follow up to all of this at the end of the weekend, but would love to hear about any opinions or thoughts about the building of a community or the goals I’ve laid out. At the very least, let me know where you think video chat should be, and maybe that will be the idea that makes it all happen.

Technology, Uncategorized 0

Being RESTful ain’t that easy

This is a more technical post, and so if you aren’t interested in some nuances of browsers and Internet architecture, then you should pass on this one. It’s okay, you won’t hurt my feelings.

Man, we ran into a doozy today. We had one report from a user that people weren’t able to enter their moderated video chats. We weren’t sure that made any sense, and we couldn’t find any records of failure to enter the video chat in our error logs. It turns out we made two mistakes. First, we didn’t gather enough information. Second, we didn’t understand the errors we were getting back. Both, thankfully, are now fixed, but the journey was an interesting one.

First, let me give a little bit of background on our new architecture. We’ve just released our new call moderation stack at TokBox, and, to do so, we really sat down and thought through how to build this functionality in an Internet architecture appropriate approach. We came up with a really solid, RESTful API. The basic premise here is that all actions have a URI, and are a very specific contract between two endpoints (one being the user making the call, the second being our server). It was all very well tested on a Mac in both FireFox and Safari.

Here’s where the real journey begins. In RESTful fashion, we are defining the user’s role in a moderated chat by transitioning them from an “ASK” state where they are essentially knocking to get in, into a “PARTICIPANT” state where they have joined the call. The modify action uses the POST verb (though technically it should use the PUT verb, we weren’t confident in the Flex framework’s HTTPService class to handle this properly, and have instead limited ourselves to POST and GET), and then redirects to the user info action which returns the updated role, as well as any profile information about the user that might be pertinent to the video chat.

Now here is the gotcha. We use an HTTP 302 redirect to move between the actions. In all browsers not IE, it looks as if the 302 happens by first doing the verb of your choosing (in our case a POST), and then a GET to the redirected site. According to the spec as we read it, this is probably wrong. In fact, the redirect needs to ask the browser which verb to use in the HTTP/1.1 spec. Seems as if the HTTP/1.1 spec is either being misinterpreted, or the HTTP/1.0 spec is being maintained to enable backwards compatibility with how sites acted. Why did this cause us a problem? Because in IE7 & IE8, the 302 redirect does a POST (essentially repeats the original verb action). Our user info action was scoped as only accepting GET requests. The result… guest users couldn’t enter a moderated video chat from the IE family of browsers because the redirect fell into an error state, and didn’t return the proper response.

It took watching the TCPDump coming across the server across multiple browsers and API calls to figure this one out, but in the end we learned a very valuable lesson about how redirects work, making RESTful APIs work cross browser, and making sure we test across all combination of browsers and scenarios.