Re: Thoughts on a Wolfram Alpha package for ...
- To: mathgroup at smc.vnet.net
- Subject: [mg102481] Re: Thoughts on a Wolfram Alpha package for ...
- From: "Andreas Lauschke" <alauschke at rcn.com>
- Date: Tue, 11 Aug 2009 04:02:28 -0400 (EDT)
I'd like to pitch in on the issue of Wolfram's support of third-party developers, and related items. With regard to George Woodrow's first post, I can't see how "poor support in most cases" (the "inevitable lag" for updates, even for Wolfram packages, and this being "understandable" for a one-man shop, etc.) would sustain the claim that there was little market for M add-ons. If support for a package is poor, then ok, that would speak against the package (and maybe the author), and it *should*, but then this is only to the detriment of *that* particular slacky package, and this is only in line with sensible principles of the market economy: have an inferior product and lose market share! It's not true that this would contribute to there being only a "little market" for add-ons in general (there are much more severe reasons that limit the potential of third-party products, as I describe futher below). Some developers may pride themselves in high support and quick turn-around times. For my product CalcLink I have updates to OpenOffice or Java taken care of in my product in a matter of a few days, and I am a "one-man shop". The issue I am facing is actually exactly the opposite: people not upgrading on THEIR end as fast as I would like to *drop* support for old, buggy stuff. I'd LOVE to drop OpenOffice 3.0 support because it had a few bugs that were unfortunately affecting CalcLink as well, and in OO 3.1 these are all taken care of, but it takes AGES until customers upgrade to 3.1. I'd LOVE to drop support for Java 5, but Java 6 doesn't run on some Macs, and on some Macs Java 6 runs only on 64 bit hardware, not 32, and then there are leopard-vs.-tiger issues, and then I hear from a customer that a JDK 6 download intended for replacement of the Mac Java couldn't even be installed ... I actually see the "lag problem" as an issue where the feet-dragging is on my customers' side -- which of course isn't always their fault, as in the Mac case! The desire to customize is not always there. The developer may not *allow* you to customize the code, and in many cases it's also not possible to customize anything due to the nature of the product itself. The features of CalcLink cannot be changed by the user and shouldn't (and many customizations are already built-in through config files, e. g. for application behaviors or for pluggable look-and-feel by simply dropping an arbitrary l-a-f file in the CalcLink directory), and if people dislike something they can always suggest something to me by email. Hell, I can even send a customer a very "individualized" version if he really wants it, no matter how crazy I think the desired feature is. M and Java make rapid changes a breeze. We're not talking C++ here. Related to that, "rolling their own or finding something else" ... that is also not always a possibility. To proxy the functionality of CalcLink or Anton Rowe's excellent Mathematica Link for Excel you may be able to do things like exporting spreadsheets as files and reading them from M or vice versa ... but that is clumsy and the key features come from harnessing the kernel from the spreadsheet environment directly and interactively and, likewise, controlling the spreadsheet from M code. How would you "proxy" that? Not possible. Only a competing product would allow a user to have some alternative way of doing things, no "rolling your own" or "do something else". You'd have to reprogram it. And a competing product would be an enrichment for the market. David Park mentions that WRI is not a great help for third-party developers, and I can fully underscore that passionately. And indeed, they like to include work done for free by others and then basically "donated" to WRI, e. g. providing files for the library center (formerly "MathSource") or now asking people to become volunteer data curators for alpha. And I also fully agree that the business model corresponds more to a publisher's business model and is not appropriate for modern day software development and marketing. "WRI takes the vast proportion of proceeds and leaves only a small amount for developers" is moderately phrased for an 80/20 ratio. Needless to say, I walked away from that NDA. CalcLink can only be purchased from me directly through my website. On the issue of documentation and help browser, we can expect that to become better in the future with the Workbench (or Eclipse plugins) that are available now, although I acknowledge that is only for Premium Service users (but then again, we can expect most third-party developers to have PS, I believe most of us have it). The WB 1.2 beta 4 just got its help center/documentation substantially revamped, that should largely take care of the poor WB documentation issue raised in this thread. As for CalcLink, I don't think the lack of help browser integration is a big problem, because I supply a User Guide pdf that describes everything in detail. I *do* see the value of the interactivity in the help browser (evaluatable input, resulting output, and explanatory text all tightly together), but for a product like CalcLink you see the results in the OTHER front-end, so there is really no way to show the input/output relationship in a meaningful way together. And the use of M from the spreadsheet would *also* have to be explained in a pdf (you can't put the spreadsheet in the help browser), so a separate User Guide document seemed to me to be the best way to handle this. And for "M only" packages we will be able to harness the paclet mechanism together with the WB/Eclipse for that purpose in the future. WB 1.2 beta 4 looks very promising. On some items from AES, low-$$ packages should become available in the future through the paclet server WRI promised to host. Todd Gayley presented this on last year's developer summit. In the Q&A I had asked about the payment system for that, and I was told it wasn't finalised yet. Ever since then I have been asking in the partnerships group about any news of "payment system finalization" here, and I was always told that things weren't finalised yet. Unless the paclet server gets dropped, we can expect low-$$ packages (then paclets) to become a reality at some (possibly very distant) point in time. Regarding the more expensive items (a couple of hundred $), I agree that commercial M is too expensive, which severely limits its usage and curtails its customer base. I hear comments from dozens of people that tell me they'd consider M if it were much cheaper, like another math tool with much larger distribution that people use. This is particularly the case for big corporations where the use of this tool is, incomprehensible to me, very dominant and mindset is not along the lines of feature sets, but only cost comparisons, even in times of a booming economy. WRI were well-advised if they had a marketing person perform a study that tries to find out *why* people select the software they select, what drove them to that decision, and how to address this problem. It's a mere fact of life that the negotiating power is in the hands of the side that can walk away from the transaction. We encounter that as we bemoan WRI's low support of us third-party developers as it's easier for them to ignore us than it is for us to ignore them. And given that vast parts of the customer base prefer "low cost with low features" over "high costs with high features" (don't ask me why, I am just describing the reality), M loses out in substantial sales opportunities due to its commercial price. On a few points from robert, WS possibly becoming effective competition, I don't see that as a big item, because they have so few people and would be more interested in large-ticket, huge integration projects (which isn't our market), instead of package/paclet development (which is our market). And even if, a firm subscriber to the principles of the market economy could only conclude that this would ultimately be good for the customer. If there were serious competition between us and WS, that would only put the customer in the driver's seat -- as it should be! Regarding the suggestion to put this topic on the 2009 agenda, I have recently been informed that there will be no developer summit this year. I find this quite unfortunate. I found last year's developer summit a good idea in principle (and generally well done), although a couple of items on the agenda were not great at all. This topic we are discussing here would be a much better choice to discuss on a developer summit. However, given that there *will not be* a developer summit this year and even if there were one, it would only incorporate the problems and ideas of the attendees (and not all third-party developers reading this discussion group -- and I have already heard from numerous third-party developers that they won't come to this year's conference), we could think of a way to reach most third-party developers that would like to discuss this (probably outside of this discussion group), and I'd be glad to volunteer time and provide resources for this, if we believe that would be worth-while to do. Andreas