The tough thing thing about unsponsored open-source projects is often that - by necessity - they're left to be completed in one's spare time. For me, Deacon began as a something akin to a personal "20% project" - the analogy being that available time not dedicated to work or school could be spent working on Deacon. But in the final weeks of the final term of graduate school, the volume of such time starts to feel like negative 20%!
Clearly, the last few weeks haven't afforded much time to work on Deacon's beta release, nor will the next few - between work, final exams, preparation of my "mini-thesis" and the celebrations that friends and family have planned. Of course, this period isn't without its downtime - which often finds me making plans or cooking up ideas for Deacon. At this point, I'm planning to push hard toward the Beta in August, after life calms down a bit. This push will include working on a Deacon-powered app - mostly as a means of trying out the library myself - as well as several other enhancements and features.
Once Deacon reaches Beta status, the ball will be in the community's court. Motivation for open-source developers is often derived from adoption, and Deacon is no exception to this rule. Testing, feedback, participation and - ultimately - adoption by developers will drive the level of development that's put into Deacon: basically, "ask and ye shall receive"! Blog comments, bug submissions, feed subscriptions, link-backs and other such digital expressions of interest are the currency of the open-source world - and they're what will keep the Deacon Project going.
It's no secret that the newspaper business is hurting these days - subscription rates and readership of "dead tree" newspapers have been on the decline since the mid-1990s, and some companies are rethinking the decision to provide free online versions of their content. As the population ages and society becomes more-connected, people continue to find and rely on new ways to keep informed, and new delivery channels. While my parents subscribed to our local newspaper for decades, my wife and I have never had a daily paper delivered to our home.
If there's one thing technology such as web delivery and smart phones should catalyze, it's the development of novel business models around content delivery, monetization and specialization. News can already be more customized than ever, whether along topical, geographic or other special-interest lines. It can be delivered via more channels, and the rise of smartphones, eBook readers and MIDs has only expanded the means by which we consume journalistic content. At the same time, all this choice and connectivity has come with a steep price - news outlets still need to pay to keep the lights on, and in recent years it's gotten much harder to charge for the value they generate.
There's a key differentiator that smartphones, and their near-ubiquitous connectivity, can offer: push notifications. (How'd you guess?!) Just as web browsers supplanted newsprint for those in search of digital delivery, push notifications can offer a more real-time alternative. In 1995, your local newspaper could bring you breaking news the morning after it happened. In 2000, they published it to their web site, and you found out if you happened to point your browser there. 2005 brought the rise of RSS feeds, letting software take care of all that repetitive polling for you - but feeds are still a little too geeky for mainstream. Today, however, mobile apps and push technology offer a disruptive opportunity to actually reverse the pattern of consumption.
So, newspapers of the world - do we have your attention? Turning off your online editions, choking back your feeds or continuing to rely on banner ad revenue are not the ways to stay relevant in today's digital marketplace. Offering real-time, pushed news that's tailored to users' unique interests and gets them informed before other news outlets can? That just might set you apart.
[Image: Sanja Gjenero, used under license]
Note: This post is part of a series on the Deacon Blog that will address topics in implementing Push Notification systems. Naturally, this coverage is oriented toward the Deacon Project, but the topics and issues discussed are often widely applicable.
"Software security" - it's been a hot topic in the mobile phone world (or at least my feed reader) lately, what with multiple iPad and iPhone related security snafus at AT&T, and the release of the first major-label security software for Android phones by Norton/Symantec. With lots at stake in the mobile world - sensitive little things like GPS locations, contact lists and phone records - security should be a consideration in any mobile computing endeavor. Push notifications are certainly no exception.
Bass, Clements and Kazman define a system's security as it's "ability to resist unauthorized usage while still providing its services to legitimate users."  We can decompose this requirement into two equally-important areas: determining which users are "legitimate", and restricting access to only those users. In push notification systems (and those based on Meteor in particular), there are also two types of users: push subscribers (those that receive notifications) and channel controllers (those that send notifications). Last in the rundown of areas to consider comes data transport: push notifications can traverse untrusted networks as they are generated, sent and received.
But before we dive into the security mechanisms that can be used with Deacon and Meteor, there's something important to keep in mind. For efficiency's sake, remember that push notifications should be as small as possible to minimize the load on the server. This is Google's advice when using Android's C2DM system; a notification's payload should only contain a "tickler" for the receiving app (such as an ID number or URL), which should then handle subsequent retrievals or processing after it receives the push. To enforce this behavior, Google limits C2DM payloads to 1024 Bytes - no such limit exists in Deacon, but it's still a good idea to follow the "tickler" approach.
So what can be done to secure push notification systems? It boils down to three relatively-simple practices: don't accept subscriptions from unauthorized users, use secure connections for channel controllers, and don't send data payloads that require secure transport. We'll take a look at all three after the jump...
A huge opportunity for mobile push technology is in professional sports - there are few other topics where real-time updates mean so much to so many. After I bought my first Android phone last November, I searched for apps that could provide real-time coverage of the Winter Olympics: there weren't any. The few apps in the Android Market that promised coverage of the Games were disappointing. They either used battery- and bandwidth-hogging polling techniques (we're looking at you, SportsTap!), or just encapsulated browser-based data with no notifications. Not long after, Deacon got its start during the run-up to the NHL playoffs. March Madness came and went, as did the Boston Marathon, the Kentucky Derby and the Preakness, and (in a few days) the 2010 World Cup.
Tomorrow, the 2010 Tour de France will kick off in Rotterdam - and the Android Market remains disappointingly devoid of apps that can push real-time updates to eager fans. While the Tour does offer an official iPhone app, they're missing out on a substantial customer group - one that represents possibly the fastest-growing smartphone platform with a 160,000 handset-a-day activation rate. Third-party app developers are missing a significant opportunity too - with no "official" app in contention, independent developers' chances of offering the must-have app for following the Tour are much greater.
This is a call to Android developers that goes beyond Deacon: The Android ecosystem needs push apps! So far, the vast majority of Android handsets don't run Froyo - and while Cloud-to-Device Messaging from Google isn't a long way off, the opportunity to deliver push-based apps now using Deacon, Xtify, Urban Airship or whatever framework you choose is ripe for the picking!
(Image: Wikimedia Commons, public domain)