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: <email@example.com>
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.
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
> 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.
Prev by Date:
Re: Generalized Fourier localization theorem?
Next by Date:
How to get plot Exclusions for a numerical function?
Previous by thread:
Re: Thoughts on a Wolfram Alpha package for ...
Next by thread:
Re: Lisp Macros in Mathematica (Re: If Scheme is so good