Echove: An Introduction
About 18 months ago I set out to simplify interaction with the Brightcove API within PHP, and ended up developing the Echove SDK. The outcome and reception has been more than I imagined, and it's become a great source of personal pride.
Beginnings
Echove's exact beginnings are hard to describe, but essentially the framework was thought of as a solution to a typical problem we were running into at work. While the Brightcove API is one of the best I've ever dealt with (probably second to Flickr), I knew that the power behind PHP could be applied to make things incredibly smooth and seamless. I began discussing the idea of a PHP SDK with my co-worker Brian Franklin, a gifted programmer who thinks a lot like I do and has a lot of the same coding experience I do, and we both became quite excited about the idea in a relatively short period of time. Eventually our Seniors Solutions Architect, Jesse Streb, overheard some of our conversations and informed us that a bare-bones PHP implementation had already been created by another one of our co-workers, Brandon Aaskov.
Like most internal projects in our department at the time, the API bridge Brandon had written was effective and solid, but could use a little love to bring it up to its full potential. I immediately grabbed his code and started tossing around some ideas on paper with Brian looking over my shoulder, and we decided to keep going in the direction Brandon had started.
After just a few hours of planning and coding we had the initial SDK completed, immediately popping it into a project we were working on to try it out. We fixed bugs along the way and added helper functions as we came across a use-case. The SDK was quite effective, and we jokingly named it "ColdPhusion", a mix of "PHP" and "ColdFusion", the latter being a programming language our company CEO had invented in 1995.
Not long after creating the SDK we received word that Brightcove was looking to start reaching out to developers in preparation for the BC3 release, and one of the items tasked out to the general employee population was creating SDKs. Brian and myself quickly documented and cleaned up our SDK, and of course rebranded to something that our CEO might find less offensive; I came up with "Echove" as an amalgamation of "Echo", a standard language construct in PHP, and "Brightcove". We then sent the code over to Ashley Streb, Brightcove's VP of Technology, and he immediately got excited over what we had built.
Within a matter of days we had added on numerous features to Echove, created a barebones website with documentation, and got the license copy from Legal. Echove was released to the public as the first iteration of the SDK on February 12th, 2009, with a total of 180 lines of code (license text included).
Growth
For the first month or so I watched the download count slowly creep into the double-digits with a little bit of sadness; I had really loved working on the project and wanted to see it used around the world, but Brightcove's client list at the time was nothing short of elite. It's understandableh that Fox, Sony, AOL and others weren't searching the web for "Brightcove PHP SDK" and hurriedly grabbing the Echove ZIP file. The SDK continued to sit idle for another month before it needed an update for a new project we were working on, and I casually released the new version expecting to see another slow rise in downloads. To my surprise, though, within days of the release it had already been grabbed by a few different users. It was at that point that I realized that though the number of people using Echove was low, inherently due to the small number of Brightcove customers using PHP, they were actually quite interested in using the code and keeping it up-to-date.
Version after version was released as my sense of purpose was rekindled for the project, and each time the number of immediate downloads grew. It was around this time that I received an e-mail that had been forwarded down from the highest levels of the company, specifically thanking me (and my "merry band") for the work on Echove; it turned out to have originated from a very, very important customer in the government sector. Finally I had received confirmation that the code base was not only being downloaded, but also being used by some of the big players of the world. Since that moment Echove has undergone frequent and extensive updates, averaging a release every two weeks.
Major Changes
The most difficult parts of developing any sort of public-facing code base are of course keeping it simple and understandable, and maintaining a direction that makes sense based on the past, the present, and the future. The latter has been the challenge I've struggled with the most, at times regretting numerous function names, required parameters, and global settings. The frustration surrounding the inability to make changes without forcing others to update their code base, and the embarrassment of having to publicly fix something that should have been correct from the start, were never more apparent than when I began development on the Gold (1.0.0) release.
What was to become the Echove Gold release got it's start when Kristen McGregor began altering Echove to support various media types for possible Brightcove product expansion (you never know, we might one day be supporting images, Power Point presentations, music files, or any number of other media types). She kept me abreast of the changes and I began to take a keen interest in the direction she was heading. Around the same time a community contributor named Luke Weber began making suggestions for some major changes to the code base, especially surrounding error reporting, to be more professional and stable. The only move that made sense at that point was to drastically change the direction that Echove had been heading to take these new ideas into account. The Echove Beta code was heavily modified to support error exceptions, and even more heavily modified when we began changing every instance of "video" to "media". Method names were changed, settings were added or removed, and some functions were erased altogether.
It was a difficult decision to make, and I tried my best to understand what kind of trouble all of our clients using Echove would have to go through in order to support the new release. In the end, though, I figured that having the flexibility to support more situations was critical, and that it's always better to fix something sooner rather than later when there's been a mass-adoption and reliance upon the code. Fortunately the Gold release, after three and a half months of development, seemed to blow over without the slightest hint of backlash.
Future
At this point in time it's hard to imagine Echove ever reaching a version number near 1.5, mainly because the Gold release was so effective in allowing for every possibility we could foresee. The SDK has been utilized in over half a dozen Professional Services projects, and countless projects by our clients or third-party developers, and no one has come up with any productive or pressing changes for the code base. I can honestly say that the only changes I expect for Echove, at this point in time, involve code clean-up, stricter checks for user error, and possible work-arounds for idiosyncrasies with the Brightcove API.
It's a rather sad realization after I've devoted so much of my free time in the office to Echove, but I figure it's a testament to the hard work and brilliance of those who worked on the project from beginning to end (obviously excluding myself from the latter attribute).
The moments in between bits of work usually delegated to Echove have now been turned towards BCJS, a Brightcove JavaScript framework to include our most-used functionality, and incorporating the Kudos JavaScript SDK created by Brian and based loosely on Echove. Perhaps it will be the next item generating all the buzz within the company.
Comments