Re: Thoughts on a Wolfram Alpha package for ...
- To: mathgroup at smc.vnet.net
- Subject: [mg102539] Re: Thoughts on a Wolfram Alpha package for ...
- From: Armand Tamzarian <mike.honeychurch at gmail.com>
- Date: Wed, 12 Aug 2009 04:37:53 -0400 (EDT)
- References: <firstname.lastname@example.org>
re: "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" If you mean the other math tool I'm thinking of, then to a certain extent it is an apples and oranges comparison. The math tool I am thinking of might be cheaper to buy but to actually do anything useful you need many toolboxes which can raise the total cost to double or triple the M cost. Mike On Aug 11, 2:58 am, "Andreas Lauschke" <alausc... at rcn.com> wrote: > 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 df > (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 wouldbe > 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