10 November 2007

Type of support required for gSOAP on OpenVMS?

Please indicate through a comment how and if you would like support for gSOAP from the OpenVMS engineering group.
Some possible items:
  • support should be part of the OpenVMS support contract, similar to the Apache Web Server
  • support can come from a group other than OpenVMS for which a small fee (how much?) can be paid
  • support must be available 24x7, 5x8 (office hours), world-wide
  • the gSOAP news list and other sources on the Web suffice
  • no support required

5 comments:

Russ said...

Gotta be option 1, "support should be part of the OpenVMS support contract, similar to the Apache Web Server". The issue isn't $$$ so much as the time to review T&C with legal. I'd think even a "small fee" wouldn't cover the collective lawyer time pouring over "indemnification" and "transferability" clauses. Also my company is bias against "Open Source", so the bundle with OpenVMS provides me with a figleaf - it isn't Open Source I am selecting, it is Open Source my vendor (HP) is selecting. Make sense?

Brett Cameron & John Apps said...

Absolutely makes sense and what we wanted to hear, I think.
Thank you!

Russ said...

Hey, what ever happened to this?

JohnA said...

We've been speaking to the powers that be about the support options and hope to achieve an understanding in the foresseable future. As always, it is a question of "funding".
Thank you for the reminder; I think we slept on our laurels here a bit!

John

DaveCarew said...

I expect that you might get a lot of "my employer has a prejudice against open source"-- and inclusion with OpenVMS is obviously the solution to that. HOWEVER-- that prejudice will die (is dying) over time as surely as progress advances--my own best guess about support for open source on OpenVMS is that you should try to adhere to successful open source models--on large successful open source products--there are "committers" who stand willing to port any new release to their environments-- Python on Mac and OpenVMS are examples of this. Building community (however that is done) and use of standard opensource tools and modalities such as sourceforge and listservers seems to be part of it as well. It is not so much "no support required" as it is the gSOAP (or XYZ opensource) community must suffice, and OpenVMS becomes a subculture within the gSOAP (XYZ) community.


We have open source elements within core, mission critical OVMS software on our site. The vendor responsible for the proprietary source code simply incorporates the open source components and assumes support responsibility for it all. I am sure that in a crunch, the expertise of the relevant open source community would be and could be brought to bear, but whoever wrangles the source and builds the system can do the first level "support" for both the source written in-house and the open source, as a practical matter on many (most?) OpenVMS installations. Especially for open source which is rather more a component than it is a standalone subsystem in itself (think gSOAP versus Apache), I believe this could be a practical support solution going forward.

No Widget