Some Thoughts and a Suggestion:

[afcarl]

Ice Developers (and especially Bernard):

Closing in on 30 years professional experience, four years of which spent working in the QA department of a commercial software company developing test suites and QA testing for approximately two dozen engineering analysis programs supported on approximately one dozen unix platforms, some thoughts are pro-offered for your consideration.

a) ICE is an impressive package in terms of functionality,
b) ICE has a VERY non-trivial learning curve,
c) ICE user's are your unpaid friends, and can vastly expand your QA test/debug/test case generation/corner case identification (i.e. effectively money in your pocket),
d) To effectively derive the benefit of the user base, some mechanism is needed to efficiently convey and automate environment and problem identification (i.e. optional flag to trigger consolidated debug output file for email transfer to your QA staff, etc.),
e) To effectively derive the benefit of the user base, do not alienate your users (i.e. "be nice"),
f) The greatest income per man-hour expended is obtained by licensing,
g) The more robust and intuitively obvious the software, the less need for technical support,
h) The more obscure or incomplete the documentation, the greater the need for technical support,
i) Technical support is not very cost effective due to the primarily one-on-one nature of the information transfer, unless it can be translated/leveraged into one-to-many by way of more robust/intuitive software or more effective/complete documentation, both of which tend towards reducing the need for technical support (see "f" through "h" above),
j) In the context of "Open-Source" middleware, maximizing income generation per man-hour expended, is tied to licensing ICE for commercial applications, which is maximized by maximizing the number of knowledgeable/effective/productive User's developing applications.
k) The elements which contribute income generation via Technical Support, are in opposition to the elements which contribute to the more profitable income generation via licensing,

Now for the more pointed observations:
1) ICE documentation is redundant and contains a profuse number of coverage holes and lack of unique use-case examples,
2) ICE software while impressive, is still very far from Robust and intuitive,
3) ICE Technical Support pricing model is prohibitive for small number of programmers,
4) The required commitment for a perspective ICE user is non-trivial, with the documentation status only increasing the effort relative to what more complete documentation could facilitate,
5) The perceived "bed-side" manner of ICE Help Forum respondents conveying a objective of income generation via Technical Support, rather than facilitating more Robust/Intuitive software and/or effective/complete documentation resulting in a greater number of knowledgeable/effective/productive User's developing applications.

It is common knowledge that the factors which make for an effective developer are usually not one and the same as those required to effectively generate a profit. The appearance from the outside is that ZeroC maintains a very short-sighted perspective by emphasis on income via Technical Support rather than doing everything possible to facilitate development of knowledgeable/effective/productive User's developing applications. Yes, and often times they will not be commercial applications. But then, ZeroC has made the choice to go "open-source".

At this point, I am hard pressed to recommend ICE for any new applications due to the required learning curve and the almost hostile attitude towards user's unless they are willing to pay for Technical Support. There are other alternatives, while not as capable, have smaller learning curves (perhaps due to lesser capabilities), better/more alternative sources/more complete documentation that would/could be "good-enough", and would work better with the available skill sets that are available. That being the case in spite of the fact that I am the one who sold management on using ICE for the current task. For the time being I'm stuck with ICE with only myself to blame for a poor judgment of ZeroC.

Regards,
Andy

[kwaclaw]

b) ICE has a VERY non-trivial learning curve,

2) ICE software while impressive, is still very far from Robust and intuitive,

Andy,

You made some very good observations, but I would like to comment specifically on the two quoted above.

In defence of ICE, I think that the problems ICE enables you to solve are non-trivial, and so any software powerful enough to solve them will require a non-trivial understanding.

Secondly, I am very interested where in your experience ICE is not robust. I have never used ICE in a production environment, only for technology demos, so I would really appreciate real-world feedback about the robustness of ICE.

Karl

[afcarl]

Karl,

I agree that the functional envelope for middleware is non-trivial, and intuition would tend to suggest that by definition a tool adequate for the task would be also. But then, API design, QA testing, facilitating user experience and corner use-cases, complete documentation, a multitude of explained graduated unique use-case examples (in the documentation), all combine together to precipitate a robust and intuitive software tool. It is also a non-trivial task to present a complex subject in a simple and easily understandable manner.

The importance of the concept of scalability does not apply only to middleware functionality. It also applies to the process of graduated tutoring a perspective user through the spectrum of complexity from simple to advanced, primarily through a strenuous attempt at developing dead-simple documentation, secondarily through a multitude of graduated complexity unique use-case explained examples, and lastly through technical support.

The ICE documentation is composed of 1900+ pages, largely redundant via multiple language support, a trivially small number of explained simple examples, and minimal explanation of the nuts-and-bolts stuff that makes-up the bulk of getting a project "breathing".

Instead, ZeroC has eliminated their newsletter which was helpful towards shoring up the documentation shortcomings, instituted a policy "No-pay, No-help" ( see Important note: Change in support policy ), instituted a Tech Support pricing model which is prohibitively expensive for the onese-twose programmer projects, and all-the-while not making any significant efforts to improve the above referenced shortcomings, other than updating new version specifics (which does not count that much).

It appears to be a policy shift towards income generation via technical support, rather than doing everything possible to facilitate multiplication of productive users, from which a portion will develop into commercial licensing income. The ingredients for success of one equate to the reduction of the other. The "vibe" has definitely changed from their earlier years.

In a production environment, the emphasis is getting from point "A" to point "B" as quickly/cheaply as possible. If added functionality comes at inordinate increase in learning curve and does not support the objective (i.e. point "A" - point "B"), a less capable tool may very well be "good enough".

Regarding ICE robustness, a good start is take a look at the "Help Forum", especially the non-responded-to threads.

I am impressed with ICE's functionality. I based my "vibe" assessment on the early year newsletter's "tone", which is unfortunately very different from the present day "tone". It is unfortunate that a short-sighted policy may doom a product with so much potential to other than mainstream market share and small open-source obscurity.

Regards,
Andy

[marc]

I resent the comment that we have an "almost hostile" attitude towards users unless they pay for technical support. Even a cursory reading of this message board will show the opposite, namely that we provide a lot of free support here on these forums. In particular, we have always provided support to open source projects. It is true, however, that we will not give free support to commercial users indefinitely. If for some reason you think that you are entitled to free support from us for an indefinite period, then we really cannot help you, and you should look elsewhere for other middleware solutions.

Also, our support policy is certainly nothing new. The post you quoted above is many years old. Our support prices, as listed on our Web pages, even predate this posting--they have remained unchanged since the first versions of Ice were published.

As for our user manual, we have received both a lot of praise and a lot of criticism. I guess the truth is somewhere in the middle: I think we have pretty good documentation, but clearly there is still a lot of room for improvement (and we are constantly improving our documentation AND our software). The reason why we stopped publishing the newsletter is simply conflicting priorities: it took too much of our resources that were needed elsewhere. However, we still do publish new articles (albeit not as frequently as the newsletter), and as I write this, we are also in the process of updating old newsletter articles so that they make use of the latest features in Ice (but these things take time).

As for your comments about robustness, I strongly disagree. Ice is very mature and robust, and is used in many mission-critical applications in many different industries. Clearly, no software is bug-free, and if there are any problems with Ice, then we work with our customers to provide a solution as quickly as possible. That being said, we definitely won't jump on every bug report posted by closed-source users who are not willing to pay us for our time, and of which the vast majority are not bugs in our code but rather bugs in the user code.

Andy, I assume you are upset with us because we told you that if you continue to need our support services, you must pay us for our work. Apparently this is something you find objectionable. I find it rather objectionable that you expect others to provide you with services for free and, when you don't get free support any longer, you start to trash Ice and ZeroC instead of giving us a word of gratitude for all the unpaid support we've given you so far.

[kwaclaw]

Andy,

<snip/>
The ICE documentation is composed of 1900+ pages, largely redundant via multiple language support, a trivially small number of explained simple examples, and minimal explanation of the nuts-and-bolts stuff that makes-up the bulk of getting a project "breathing".
<snip/>

I would agree with you in basically everything you said, but would add just one comment: What applies to ICE applies to middle-ware in general. Anyone who understands middle-ware issues does not really need the kind of learning support you so aptly described. But if a new ICE user needs learn the ropes of middle-ware architecture and design first, this should be done in an ICE-independent way. Really, what would be needed is some form of generic middle-ware tutorial which the ICE documentation could refer to when describing how ICE maps to generic middle-ware solution patterns.

My understanding was that ICE really is targeted at the experienced architect or designer. This may be a strategic error, but I thought it was intentional.

<snip/>
It appears to be a policy shift towards income generation via technical support, rather than doing everything possible to facilitate multiplication of productive users, from which a portion will develop into commercial licensing income. The ingredients for success of one equate to the reduction of the other. The "vibe" has definitely changed from their earlier years.

I have suffered from this too, as I was reminded of paying for support more than once, and it did not seem an acceptable excuse that we were not using ICE in production.

<snip/>
Regarding ICE robustness, a good start is take a look at the "Help Forum", especially the non-responded-to threads.

I will take a closer look, but my general impression was that ZeroC took pride in their product and wanted to keep it as bug-free as possible.

I am impressed with ICE's functionality. I based my "vibe" assessment on the early year newsletter's "tone", which is unfortunately very different from the present day "tone". It is unfortunate that a short-sighted policy may doom a product with so much potential to other than mainstream market share and small open-source obscurity.

I definitely share your concerns regarding ICE and it general acceptance. Just recently I had a conversation with a former boss (enterprise architect) and somehow we got talking about middle-ware and when I mentioned ICE he kind of smiled in the way you would do with a silly child, implying that I could not be taken seriously in this regard.

What I find so strange is that there aren't any real alternatives with the same range of capabilities, and still ICE has not taken over... Just think of web services with call-backs using "long polling". What a hack, but seriously considered by many.

Regards,

Karl

[afcarl]

I resent the comment that we have an "almost hostile" attitude towards users unless they pay for technical support.

This was primarily directed to Bernard. But your "honeymoon" period approach hardly disproves the point. But it is your product to do with as you deem best. I'm only an engineer working for a company of over 120,000 employees, which maintains a company-wide database of employee skill sets and software usage experience(s), with a multitude of management-types that effectively block the vast majority of reasonable expenses (i.e. Technical Support). That's the reality. You can chose to work with or work against it. In the end, the tasks will get done. The only question is which tools will be used.

In one respect, I can appreciate your emotional response. You obviously take pride in your work and that is to be commended. But as I stated in the opening post, the qualifications required to excel at development are commonly known to be not one and the same as those required to make a profit.

There comes a time when to you have to take a step back from the task, and try to look at things from the perspective of the targeted end user, and this can be hard to do. I have only been objective and not pulled any punches, and that even that from one explicitly stating a favorable assessment of the product's functionality.

Perhaps you should change the heading for the "Comments" section from:

"If you have ideas for how we can improve Ice, you can discuss them here. All suggestions are welcome!"

to:

"Only praiseful comments are welcome!"

All kidding aside, if ZeroC took just one revision cycle time period and did absolutely no development, but rather focused exclusively on "dead-simple" documentation with graduated examples as stated previously, I think you would be surprised at the long-term dividends!

[afcarl]

What applies to ICE applies to middle-ware in general. Anyone who understands middle-ware issues does not really need the kind of learning support you so aptly described. But if a new ICE user needs learn the ropes of middle-ware architecture and design first, this should be done in an ICE-independent way. Really, what would be needed is some form of generic middle-ware tutorial which the ICE documentation could refer to when describing how ICE maps to generic middle-ware solution patterns.

I don't think such an animal exists, and even if it did, it's utility would be limited by the simple fact that middleware is non-trivial and largely middleware specific.

My understanding was that ICE really is targeted at the experienced architect or designer. This may be a strategic error, but I thought it was intentional.

Perhaps so, but maximum income per man-hour expended, in the open-source arena, is achieved via licensing of commercial applications. The pool of perspective "non-experienced architects/designers" is two orders-of-magnitude larger than the pool of perspective "experienced architects/designers". Profit motive would dictate a strenuous attempt at broadening the size of the pool of perspective ICE users. How much do you stand to lose in the attempt? And how much to gain.

The incremental effort is small. Good documentation and helpful explained examples will be useful and appreciated long after the incremental new features will be forgotten. Freeing up development man-power for development, rather than throwing Technical Support hours to cover-up weak documentation. In a perfect world, there would be no need for Technical Support. Only paid consulting and software development. The fact that Technical Support is needed, is indicative of the underlying problem.

Regards,
Andy

[OrNot]

Hi,

I would like give some comments on this topic.

1) I don't think the learning curve of ICE is steep. It is easy to start your work even only by studying the demo code. Of course if you want very sophisticated functionalities, such as implementing your own ,say, Grid, more efforts are surely needed. But I still think it is easier and cleaner than other stuff, for example, DCOM.

2) ICE is robust enough from my experience. Yes, Indeed.

3) It is rare for ICE guys not to response for your questions here. In most cases they will explain much details for you. But sometimes it depends on who the ICE guy is. Michi is the nicest guy, who never said no to your questions and his reply often was 3 times longer than your questions. Benoit is also very patient and seldom let you ask the commercial supports. But Marc is like a bomb who may explode at any time, so be careful especially when you want to say some words on ICE critically. You can check all posts by Marc, most of them end up with asking you to commercial supports. .

4) The ICE license policy doesn't change. Now is same as several years ago. I think I can assert this because I nearly read every post in this forums.
So far the pricing model, It did make us have to pick other technical options.But I understood it since zeroc must gain their money. Hopefully they will find a more flexible solution .


5) I think ICE document is very good. It is not only for ICE, but also for middleware, networking programing and even more. But as afcarl said, the newsletters once published are also very very helpful as a good reinforce. Unfortunately, they are gone.