A few weeks have past since making some major product direction/staffing/technology-stack changes at Gnip. Most of the dust has settled and here’s an update.

What Changed Externally

api.gnip.com is alive, well, and fully supported. From a product standpoint we’re now also pursuing a decentralized data access model to broaden our offering. The original centralized product continues to serve its customers well, but it doesn’t fit all the use cases we want to nail. It turns out that while many folks want to be completely hands-off WRT how their data is collected (“just get me the data”), they still want full transparency into, and control of, the process. That transparency and control is on its way via Gnip Data Collectors that customers configure through an easy to use GUI.

To summarize, externally, you will soon see additional product offerings/approaches around data movement.

What Changed Internally

A lot. api.gnip.com is a phenomenal message bus that can reliably filter & move data from A to B at insane volumes. In order to achieve this however, we left a few things by the wayside that we realized we couldn’t leave there any longer. Customer demand, and internal Product direction needs (obviously coupled with customer needs) were such that we needed to approach the product offering from a different technical angle.

GUI & Data

We neglected a non-trivial tier of our customer base by almost exclusively focusing on the REST API to the system. Without the constraint of a GUI, technical/architectural/implementation decisions that come with building software were blinded by “the backend.” As a result, we literally cut our data off from the GUI tier. Getting data into the GUI was like raising the Titanic; doable, but hard and time consuming. Too hard for what we needed to do as a business. We’d bolted the UI framework onto the side, and customized how everything moved in/out of the core platform to the GUI layer. We weren’t able to keep up with Product needs on the GUI side.

Statistics

Similar to GUI, getting statistics out of the system in a consumer friendly manner was too hard. Business has become accustomed to running SQL queries to collect information/statistics. While one can bolt SQL interfaces onto customized systems, you have to ask yourself whether or not you really want to? What if you started with something that natively spoke SQL?

So…

We introduced a stack that supports a decentralized data collection approach, as well as off-the-shelf GUI, statistics collection/display, and SQL interface; “Cloud” instances, running Linux (obviously), MySQL, and Rails. We have prototypes up and running internally, and things are going great.

Product Details

I’ve been vague here on purpose. We’re still honing all the features, capabilities, and market opportunities in front of us, and I don’t want to commit to them right now.

The People

I want to end on a personal note. My mind was blown by the people we decided to “let go” in this process; all of them incredibly high quality.

All I can say here is that it’s all in the people. You build teams that meet the needs of the business. For the sand that shifted, Eric and I are to blame. We undoubtedly burned bridges with amazing people during this process, and that is excruciating. Those no longer with us are great, and all of them have either already jumped into new projects/companies, or are weighing their options. The best of luck to you, and I hope to work with you again someday.