Services & Resources / Wolfram Forums / MathGroup Archive
-----

MathGroup Archive 2009

[Date Index] [Thread Index] [Author Index]

Search the Archive

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


  • Prev by Date: Re: Re: video on Presentations by Williams and Park
  • Next by Date: Re: Re: Re: video on Presentations by Williams
  • Previous by thread: Re: Dynamically create array and display data graphically
  • Next by thread: Re: Thoughts on a Wolfram Alpha package for ...