Ask HN: What's next for this codebase?
18 comments
Add support for other phones and the ability to migrate between them. The more major devices you support, the wider your net. The ability to sync/migrate blackberry to whatever phone I get next (and back if it doesn't work out) in a common interface would be your main USP.
Other stuff - small scale library management for media. Let me drag and drop music, ebooks etc. onto my phone window and have them sync over into the right folder regardless of which phone model I'm using.
That consistency is something that the vendors can't do. That's your second USP.
The first one is good for new customers, the second is good for retention/upgrades.
Just my 2c worth, you've probably got a better idea of the market than I have.
Other stuff - small scale library management for media. Let me drag and drop music, ebooks etc. onto my phone window and have them sync over into the right folder regardless of which phone model I'm using.
That consistency is something that the vendors can't do. That's your second USP.
The first one is good for new customers, the second is good for retention/upgrades.
Just my 2c worth, you've probably got a better idea of the market than I have.
Agreed. Many people juggle with multiple devices: personal iPhone + work Blackberry. A "hub" would be useful.
To be perfectly honest, if you open sourced it but just put up the source to download (and not precompiled binaries for OS X), you'd probably sell close to as many copies as you do now.
Another alternative is to port it to Linux and try selling it through Ubuntu's new software store. I imagine that BlackBerry don't make a native Linux app yet?
Another alternative is to port it to Linux and try selling it through Ubuntu's new software store. I imagine that BlackBerry don't make a native Linux app yet?
To be perfectly honest, if you open sourced it but just put up the source to download (and not precompiled binaries for OS X), you'd probably sell close to as many copies as you do now.
Although it is also possible that someone would compile the source and put a binary on the Internet for free, undercutting sales.
Although it is also possible that someone would compile the source and put a binary on the Internet for free, undercutting sales.
Yeah I can see this going both ways, really. (That is, similar sales volume or drastically reduced sales volume.)
And, as I say, I think there's a real benefit to taking something like this and opening it up, I'm just not sure I'm willing to risk it - for now - especially since I'm already competing against _one_ free alternative.
And, as I say, I think there's a real benefit to taking something like this and opening it up, I'm just not sure I'm willing to risk it - for now - especially since I'm already competing against _one_ free alternative.
Interestingly enough, a Linux build _was_ one of the pivots we'd experimented with. Maybe it was because we chose the wrong distro, or our general ignorance of what Linux users might want, but this seemed to generate little to no interest amongst the Linux market/s. If anyone here knows better, or wants to tell us what we did wrong, I'm happy to hear it.
It probably does depend a lot on what distro you target - Ubuntu being the most "consumer-focussed" one, that's the one I'd suggest. They also have their Ubuntu Software Store, which allows you to sell apps through a desktop application, something like the Ubuntu version of the iTunes app store. It's early days yet for that though, so hard to tell how it'll go.
Can one do this and distribute a closed-source app this way? Is it practical to do so?
In addition to the feedback we got on our choice of distros, we also got a number of complaints about our offering a closed-source app for Linux.
Again, that's probably my ignorance of the Linux market in general, but I have the sense users are pretty evenly divided on this point.
(Thanks, BTW!)
In addition to the feedback we got on our choice of distros, we also got a number of complaints about our offering a closed-source app for Linux.
Again, that's probably my ignorance of the Linux market in general, but I have the sense users are pretty evenly divided on this point.
(Thanks, BTW!)
That's the intention - (eg. http://www.workswithu.com/2010/09/10/fluendo-dvd-player-for-... ). Like I said, it's early days though.
There are a significant number of Linux users who highly value the ability to see how the software they use works, and modify it as they see fit. Many of these users consider it a moral imperative that all software they run is open to inspection and modification. You won't sell anything to the people in this latter category - and you'll probably get a few angry emails, too.
On the other hand, there are also plenty of Linux users out there running closed-source NVidia drivers, Oracle databases and more.
There are a significant number of Linux users who highly value the ability to see how the software they use works, and modify it as they see fit. Many of these users consider it a moral imperative that all software they run is open to inspection and modification. You won't sell anything to the people in this latter category - and you'll probably get a few angry emails, too.
On the other hand, there are also plenty of Linux users out there running closed-source NVidia drivers, Oracle databases and more.
Perhaps the market for this type of software is going away, as you described. In that case, focus on getting as much revenue out of it with as little work as possible, while moving on to other things. No point in fighting an uphill battle that'll get harder with the years if the market is indeed going away.
Agreed. It just seems a shame to let a reasonably robust, mature codebase which is all-knowing about a very widely-used piece of technology go gentle into that good night. Surely someone out there has a new and previously unimagined (by me) use for it.
I also doubt you'd raise as much as you might want to open-source it through Kickstarter -- but it's low-risk to try, since if your chosen threshold isn't reached no money changes hands. It'd only be a bruise to your project's cachet, and perhaps reveal your 'reserve price' for future negotiations.
Tools to migrate BB data to Android or iOS devices might be of interest in those app-markets. Even just something that migrates the data to some standard outside file-format might be of interest, or work as the 'first leg' of a transfer that requires a new app-store-bought-app to import to the new device. (Is there a 'blackberryimage' format?)
Could it be used to provide a 'cloud backup' of your BB, either over-the-air or over-a-cable?
Tools to migrate BB data to Android or iOS devices might be of interest in those app-markets. Even just something that migrates the data to some standard outside file-format might be of interest, or work as the 'first leg' of a transfer that requires a new app-store-bought-app to import to the new device. (Is there a 'blackberryimage' format?)
Could it be used to provide a 'cloud backup' of your BB, either over-the-air or over-a-cable?
I would look at either making the source code available to the forensics community, or pivot and release a program geared towards forensics.
There is a market for tools to pull data off mobile devices. Currently its somewhat fragmented with a lot of players, but (having used your software, and working in digital forensics), I'd say you probably have the codebase to distinguish yourself in pulling data from blackberrys.
If you want to see what else is out there, look at paraben forensics, guidance software, and cellebrite.
If you want to see what else is out there, look at paraben forensics, guidance software, and cellebrite.
Ah, interesting idea!
I looked at the apps you recommended, and it seems like at least Paraben has some BlackBerry support already.
How might we distinguish ourselves?
I looked at the apps you recommended, and it seems like at least Paraben has some BlackBerry support already.
How might we distinguish ourselves?
The paraben tool requires blackberry desktop manager to be installed, and just hooks into their application for support. It then puts the data into a paraben-specific file format, preventing someone from being able to analyze the data with other tools. If you are interested and want more specific ideas for development, id be happy to talk about this in a less public venue than an open internet forum.
Ah! That's certainly something they don't make clear on their pages!
Yes, please. If you're willing to contact me off-list (see profile for email address), I'd be most grateful.
Yes, please. If you're willing to contact me off-list (see profile for email address), I'd be most grateful.
Long time lurker, first time poster.
I'm looking for some brainstorming help on a possible future for some code which has reached a sort of crossroads.
This codebase is commercially known as "PocketMac for BlackBerry". If you're not familiar with it, it was the first Mac app that allowed users to sync a BlackBerry with a Mac. RIM licensed it for several years to give it away to users, until they eventually came out with their own app. It includes the drivers (of course), the low- & high-level communication stack, and a pretty robust sync engine.
This code probably represents the most comprehensive knowledge of the BlackBerry's internals found outside of Ontario, Canada.
The problems facing this codebase are:
- With RIM making their own software -quality of same aside- it will potentially become more difficult to sell this, at some point.
- Additionally, as with all devices, the future of the BlackBerry is uncertain.
- Finally, syncing mobile devices, as a market, seems to be something that 3rd parties are being crowded out of. More and more devices talk to Macs (or a good cloud service) right out of the box.
So, that brings me to the question of what's next.
Here are some very rough (~40 grit sandpaper) ideas I've been considering:
1. Pivot. Agreed, but, to what? As I said, devices are now shipping with this sort of functionality built-in, so it's not as simple as just porting a piece or two to a new platform, generating a new driver, etc. if there's not really a need or market for such a solution.
2. Wholesale sale/licensing of the code to another party. Maybe Google wants to offer a way for Android phones to connect to a BlackBerry and slurping in all of the user's data? Some of the recent headlines suggest there might be a foreign government interested in slurping up data from citizens' BlackBerry devices. (Remember, we're just brainstorming here.)
3. Open-source it. I'd love to. I really would, but I can't afford it right now. The software still sells and paid support doesn't make enough on its own. I'd consider some kind of Kickstarter project to open it up, but I doubt it'd raise enough money to be worthwhile.
That's as far as I got.
I'm hoping you will have some additional ideas, since I'm almost certainly "too close to it," as they say.
I welcome any and all suggestions.
Thanks in advance!