Drexel dragonThe Math ForumDonate to the Math Forum

Search All of the Math Forum:

Views expressed in these public forums are not endorsed by Drexel University or The Math Forum.

Math Forum » Discussions » Software » comp.soft-sys.math.mathematica

Topic: Re: Thoughts on a Wolfram Alpha package for ...
Replies: 1   Last Post: Aug 12, 2009 4:37 AM

Advanced Search

Back to Topic List Back to Topic List Jump to Tree View Jump to Tree View   Messages: [ Previous | Next ]
Andreas Lauschke

Posts: 7
Registered: 11/29/08
Re: Thoughts on a Wolfram Alpha package for ...
Posted: Aug 11, 2009 3:58 AM
  Click to see the message monospaced in plain text Plain Text   Click to reply to this topic Reply

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

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.


Point your RSS reader here for a feed of the latest messages in this topic.

[Privacy Policy] [Terms of Use]

© Drexel University 1994-2014. All Rights Reserved.
The Math Forum is a research and educational enterprise of the Drexel University School of Education.