The Economics of PIMs
< Next Topic | Back to topic list | Previous Topic >
Posted by Stephen Zeoli
Jun 3, 2009 at 05:36 PM
Very interesting topic. Thanks for bringing it up. Here are a few thoughts:
1. I think you’re looking for stability in an environment that is simply inherently unstable. No business model ensures stability, as far as I can see, other than open source with a huge, devoted user base, perhaps. Take GrandView, the terrific DOS outliner that was owned by Symantec, a huge company. When Windows bowled over DOS applications, Symantec never committed to moving GV to Windows. ECCOPro was purchased by a stable company, NetManage, then promptly shut down. Countless small operations with strong applications have come and gone—from ADM to HyperClip. As we all know, I could go on for a long time listing the ways in which all of us, in one way or another, have been burned by developers… which is not to say that in all cases the developers were unethical. Nothing can guarantee the continued development of an application that no longer has the support of its developer. Period.
2. The subscription model may seem promising, but to me that’s even worse, because I do not trust that ANY developer will guarantee further development and support. Therefore, a subscription model puts you at greater risk, because once the developer shuts down, your subscription will expire and you’re out of luck. I would NEVER buy into a subscription model, because that very danger lurks continually around the corner. I don’t mind, and am even happy, to pay a reasonable fee when there is a significant upgrade or update.
3. For those reasons, I think the best approach is to pick that application you most enjoy working in, and which best suits your needs—as long as the following are true:
a. You can get your data out reasonably (although, as you say, it will never be perfectly); and
b. You have at least a reasonable expectation that this isn’t a fly-by-night operation.
4. As for paying for support, I’m sort of ambivalent. I can see why a developer of an application that costs $30 would not want to continually field support requests. On the other hand, a product that generates a significant stream of support requests may not have been well designed in the first place. These days, it seems to me, many if not most developers rely upon the user-base to provide support in their online forums. That seems a reasonable alternative to me, especially for small or one-man outfits.
The bottom line, for me, is that I fully expect to be moving data from one application to another. It’s just the nature of the beast, especially when the hardware and the operating systems are not static, either. And, in a way, that fits into my need for CRIMPing.
Steve Z.
Posted by Stephen Zeoli
Jun 3, 2009 at 05:41 PM
JohnK wrote:
>And we’ve seen it happen all to many times. One new program I’m
>keeping a close eye on is CintaNotes (http://cintanotes.com/), a light-weight,
>plain-text notes manager that seems to be going in the right direction. It’s still in
>beta, but I’m hopeful. One of the reasons is that the developer is being very careful
>about the features he adds, and encourages conversation in the user community when
>any new features are considered.
I agree that Cinta Notes is worth watching. I first read about it last week on Manfred’s blog, and have been using it at work. I’ve found that it behaves just as the developer claims it will in his roadmap. It feels like some sort of a hybrid of Zoot, Personal Knowbase, and Evernote… basically a stripped down clipper and note taker. Fast and efficient, so far, with only a minimal amount of data.
Steve Z.
Posted by Chris Thompson
Jun 3, 2009 at 09:50 PM
This is a great thread. Personally, I’m not comfortable paying annually for software because it reduces the incentive for the developer to improve it. (I think Word is a false example… the problem I have with Word is that it stagnated for so long, without any real new features, just surface changes. e.g. We have to wait until 2010 to get ligatures? Seriously, it took nearly two decades of development to finally add that? I have the same beef with OneNote. Could be a solid product with a little fundamental work, but it’s just not moving forward in areas that matter, and the 2010 beta is no better. As another poster mentioned, Outlook is another classic example.)
Tools that work with open file formats are the safest way to go, IMHO.
—Chris
Posted by JohnK
Jun 4, 2009 at 12:40 AM
Chris Thompson wrote:
>Tools
>that work with open file formats are the safest way to go, IMHO.
>
That may well be true for, say, a word processor. But for PIMs, it is unavoidable that developers will have to use some form of database engine (certainly for any PIM that claims to be scalable to any serious degree).
As I understand it, if a PIM uses a common database engine (say SQL), then you would be able to use a variety of database readers to examine/extract your data. So in theory, your data would never be trapped in the database, even if you no longer possessed the PIM, or the PIM had no export options.
In the real world, however, most users, including the fairly knowledgeable crowd gathered in this forum, are not going to go hunting down specialised tools to extract data from databases. I think Steve Z’s practical approach is the only one to take—to expect that, over time, you may have no alternative but to move data from program to program. As Steve points out, this means that one of the vital features in any PIM is the array of export options available. Thankfully, these days, many developers seem to appreciate that fact.
Posted by Manfred
Jun 4, 2009 at 01:40 AM
I also agree with Steve Zeoli that you will always have to think about how to move your stuff from the application you use now to the one you will be using in a few years. Even if your hope is that the application you are using now will be the one that you will use until you die, it’s smart to keep your options open.
One of the principles I observe with regard to data and pim-like applications is: “easy in, easy out.” And at the moment text (Including CVS) and HTML (possibly XML) seem to be the best bet at this time.
“More complicated” usually is worse.
Manfred
P.S.: I also find that the relationship with the developer(s) must be based on trust. I still remember how betrayed I felt when the people who developed ECCO just sold it to Netmanage, who promptly let it die. I still wonder what would have become of the program, if they had no sold out to be people who did not care about the product nor about the customers who bought it.
It’s not that I don’t understand that “the economy of a PIM” is important, it’s just that, “if that’s all there is, then let’s keep dancing ...,” i.e. move on. I hope this doesn’t sound too naive.