× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Buck,

Inline...

At 2/11/2011 10:54 AM, you wrote:
On 2/10/2011 2:18 PM, M. Lazarus wrote:
> Joe, Buck,
>
> I'm not following this reasoning. It is fairly well established that
> RPG is the primary development language on the platform. I don't know
> statistics on the runners up, but Cobol is probably the next most
> popular. Putting exact numbers on it is futile. Why?
>
> 1) IBM needs to produce development tools for RPG, Cobol and other
> languages, regardless of the exact numbers of users. Otherwise, the
> platform dies.

They've done that, in multiple variants. The market overwhelmingly
prefers SEU. IBM gave away Code/400, they gave away WDSC and few were
interested. What should Rational do now that they /know/ the GUI IDE
market is pretty much a desert in the IBM i / RPG market space?

While adoption is slower than we would like, I do not believe that it's the "desert" that some make it out to be. One thing I can tell you for sure: Many more have abandoned it since the fee was imposed! Not by choice, but because management won't spring for it.


> 2) If IBM does not enable the system to *easily* conform to current
> standards (native GUI, browser interaction integrated with existing
> languages, web services, etc, as just a few examples), the user base
> will continue to erode. The cost to develop this should come under
> banner of "advertising, marketing and continued viability of the
> platform." It's currently under the "Well, if they really, really beg
> us we'll do them a favor, but they'll pay for it dearly..."

WDSC and the various follow-on packages coming out of Rational are
intended to do exactly this. As for the 'pay for it' part, the market
didn't exactly adopt WDSC when it was free. I can understand Rational
trying to recoup development costs for this new stuff.

For all practical purposes in this case, Rational = IBM. The divisional / moniker distinction is IBM's doing (for bookkeeping? revenue tracking? marketing?), but from our standpoint they should lumped together.


> 3) If IBM would spread out the costs over all OS purchases, it would be
> a very small bump. Instead, they are surprised when fewer than expected
> are successful in convincing management to spring for a cost they never
> had to pay for before. As a consultant, I can rarely walk into a shop
> where they have RDi. And if a few chosen programmers are allowed to
> have it it's usually considered a perk. Whether it makes sense or not
> is not the point. The point is that this cost model is make it more and
> more difficult for companies to stick w/ the i, let alone get new
> customers.

IBM DID spread out the cost across all OS purchases and it gradually
dawned on them that they were spending money to develop and maintain RDp
for an extremely limited audience. Look at it this way, if IBM were to
push Smalltalk for years and only a few dozen IBM i shops used it,
should IBM keep developing Smalltalk for i or should they abandon it as
an unprofitable experiment and reassign developers to something that
makes money - or at least satisfies more customers?

Of course, they shouldn't support an obsolete language. Witness the fates of Basic, Pascal and a few other languages. But language adoption is not the same thing as development tools adoption. If you don't have GUI tools to offer for nothing or next to nothing, you'll have little chance of attracting new developers. (I believe that it's part of the picture required, not the whole thing.)

Many features are included with the OS because they are considered vital and / or strategic to the platform. A few examples are: TCP/IP, SQL, DB2, security, multiple file system support. Of course IBM can try to charge separately for each one, but that would be another nail on the coffin.

Developers are the lifeline of any platform. No new development = a slow death. IBM should be trying to woo new blood into the platform, instead of trying to milk it dry.

When it was WDSc (included w/ development tools), anyone in the shop could have installed it on a whim and tried it out, without worrying about eventually having to make a case to management for funds. Then the power struggles kick in when a more senior developer also needs more funds to upgrade. Too much trouble for many.


This is probably our last chance as a market to influence the decision
makers at IBM. If they don't see a revenue stream, they're going to
conclude that it was good while it lasted and all good things must end.
It won't cost them hardly anything to put RDp on caretaker status and
let developers keep using it without further investment in enhancements.
Look at SEU; it is essentially unchanged from the day it was delivered
on System/38, yet many thousands continue to be very happy using it.
IBM isn't making product decisions based on a few emails on a list
server. They make decisions based on measurable profit and loss.

Measurable profit can easily come from a small rise in the OS cost. Separating it out might make it a little easier for the bean counters, but takes its toll on the total revenue. It also gives a false sense of need (or lack thereof) for the product.

Good development tools are essential. There should be little doubt of that. I don't need to know exactly how many people are using it. If IBM is selling or supporting the compiler or language, the development tool needs to be there for that product.

-mark

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.