OpenVBX – product or code sample?

I usually write about the MV DBMS and related technologies here but I’ve created a new Twilio category in this blog and will try to take some time once in a while to blog on this topic, and the related OpenVBX. For now I’d like to comment on how I see OpenVBX, which seems to be different from how others see it. (I’ll define Twilio and OpenVBX later for those of you who don’t know – and if you don’t know you probably won’t be interested in this blog entry.)

I’m responding to statements I see once in a while where people say they can’t sell services based on OpenVBX because it’s missing some feature. It’s not my place to explain how OpenVBX is positioned, for Twilio or anyone else, but I can provide my understanding of this “ecosystem”.

OpenVBX is provided by Twilio as FOSS, not as a product. Issues are reported to the GitHub tracker and processed by whomever wants to take a stab at it, whenever there is time. While published by Twilio, the software is not a “product”, it’s a heap of code that they provide developers as a base on which to build.

Maybe it was a mistake for them to package it like a product because it immediately creates the perception that it is a fully working product, until people start using it to see just how much has not been implemented. As a result, what we see are people saying they can’t use it for resale or production purposes. Well, IMO, we’re not supposed use it for resale or production, it’s an incomplete work of art, a wireframe for modelling clay, an image in a coloring book. That perception or understanding makes me much more comfortable with the situation than I would be had I purchased software that needed as much work as OpenVBX does. I’m not saying OpenVBX is broken, deficient, or bad in any way. On the contrary, I’m trying to build upon it myself – but that’s the point. I see it as something to build upon, not something to reject because there are so many points on which building seems to be a requirement.

Maybe it was a mistake for Twilio to position OpenVBX in a manner which puts the burden upon them to provide support and process change requests. I don’t disagree with their approach but I think they went too far in that direction. To get more people to use their services they created a user interface. When people see a UI they think “final product” where developers should think “good start”. I think Twilio could have shifted focus just a bit to assert that OpenVBX is their gift to the developer community, but instead they advertised how easy it was to use out of the box (or compressed file) and they emphasized that this was a “Twilio offering”. So now people expect Twilio to fix and enhance everything, and (from my perspective) we’re seeing very few contributions to the core from developers in the field.

The issue there is that Twilio provides a service, an API to access the service, and they happen to provide some base code, a sample implementation in the form of OpenVBX to help kickstart development projects for those of us in the field who wish to build upon their platform. But they’re not in the deliverable software business where they build ready-made applications over their own platform. That’s how they’ve positioned themselves, and unless they intend to put more resources into more frequent OpenVBX updates, I think they now need to re-engineer some of their marketing messages to reposition the expectations for support back out to the community and away from themselves.

IMO, OpenVBX should be considered a model on which to build, with free code to save us time, but it shouldn’t be considered a finished product that is now missing “required” features. Twilio was generous in the beginning but now people expect them to maintain the package as though they own it, not as though it were a gift given to the developer community. With most other SaaS/SOA platforms we don’t get anything like OpenVBX. All app development is up to people in the field – because it’s positioned that way. As a similar but admittedly not quite exact scenario, there are sample projects included with Visual Studio, one of which is for managing a collection of videos. But people don’t put that code online to generate income and then contact Microsoft for enhancements. They use it as a base for other apps that might manage collections of something completely different – ultimately the code that developers produce looks nothing like the samples provided, but without those samples and some insightful code snippets, some developers would have had a hard time creating their own solutions. To me, that’s OpenVBX.

I’m not saying anyone is wrong to ask for features or report issues, etc. But with OpenVBX we pretty much have what we get, and we’re lucky if we get anything else. The Twilio people have given us x% of a solution to implement where we get zero% from everywhere else. Our approach should be “great, we only need to write another (100 minus x)% for ourselves” not “Twilio needs to implement the other (100 minus x)% or we can’t sell this”. In other words, our role here is to be developers over the Twilio services, perhaps making some use of their sample implementation, then to sell our offerings, not to try to resell the sample implementation as a product over Twilio services.

Two things that this community could really use are:
1) (Supply) Developers advertising themselves as professional OpenVBX developers, providing tweaks for the core, new addins, and fixes/enhancements for existing addins (which are also often provided just as a kickstart, not as a finished product).
2) (Demand) Recognition amongst OpenVBX users that they either need to code tweaks themselves, or they need to obtain services from someone else, whether for fee or with some other form of equity.

With supply I think demand will come, as more people recognize and work with the model. With more demand I think we’ll see more supply of developers gearing up to provide services to an eager market of service resellers.

That’s the way I see it anyway. YMMV.

Now, if this isn’t the way Twilio Inc sees it, then I would suggest that the fine support they provide for their services has not translated into similar support for their OpenVBX product. That’s no longer a marketing issue but now a management issue. I’ll leave it at that.