Jack Woehr wrote: >There's no customer, no partner. Conceivably that could change via the VSE-L mailing list, depending on the level of interest there in Ublu.
>Ublu is written in Java. I'm looking at extending it to support IBM MQ and >now, since I've found your Java bridge to z/VSE, well, why not z/VSE, thought I. Why not indeed? One approach you could take is to go ahead and code, but document that new section of code as "experimental" (or some other suitable marker). If Ublu generates log messages, for example, you could even add a log entry that says something like: "Ublu's z/VSE Connector Client/Server support is experimental. Please contact the Ublu project team to let us know about your experiences. Visit https://ublu.org/vse for more information." You might even require setting a special, documented parameter before the experimental code path is available. Paul Allen, Bill Gates, and Monte Davidoff famously created their first BASIC compiler in 1975 for the MITS Altair machine without having an Altair. They had to write an Altair emulator first then code on top of that. Then Paul Allen flew to MITS in New Mexico to run his very first test. They forgot to write the bootstrap code, so he had to write it during the plane ride. Coding to the z/VSE Connector Client should be a lot easier. :) >(((Parenthetically, off topic, IBM might consider looking at the licenses >currently used for the Java clients for both IBM MQ and z/VSE as they make >it very hard/impossible to incorporate those .jar files in Open Source >offerings, even those such as mine which have no use whatsoever outside the >context of interaction with fully licensed IBM host systems. Of course I >can compile the code and put the onus on the user to download the .jars for >runtime but perhaps IBM could consider explicitly licensing Open Source >offerings intended to support IBM systems to incorporate the jars with the >distribution.))) Licensing aside, one key issue is that the IBM code, like all living code, is subject to change for security, performance, functional, and other reasons. There's at least some technical, maintenance-related merit in having IBM handle distribution (and support) of its code, and you yours.(*) The Android ecosystem comes to mind as an analogy. In my personal view (as always), the Android ecosystem has not served end users nearly as well as it could in terms of getting security patches into their hands as expeditiously as possible. We live in a world where, at any/every moment in time, most of the Android devices people are carrying around have known security defects. The reason why Android isn't working well in that respect has to do with distribution complexities, fundamentally. Another recent example is OpenSSL. I'm sure there are still massive numbers of end user instances of OpenSSL, embedded in myriad products, that don't have security fixes. There probably "always" will be. :-( That said, the software world is "interesting." Sometimes it makes technical sense for other parties to (re)distribute code downstream or upstream, and sometimes it doesn't. From what I can tell IBM tries to make the right call depending on the circumstances. Sometimes, for example, that means striking a deal that the distributor has a particular obligation to get IBM updates into its end users' hands in timely fashion. (*) But you can make it easier for end users. Here are some examples of how you might: 1. Documentation, with a nice landing page (e.g. ublu.org/vse and ublu.org/mq) that then links to the right part(s) of IBM. 2. Warning messages when an end user tries to use a version of the z/VSE Connector Client that you know to be backlevel, at least at the point in time when that particular release of Ublu appeared. (Although be careful how you perform version/release checks.) If Ublu does its own automated release checking periodically, probably on an opt-out basis (i.e. enabled by default), then the z/VSE Connector Client and MQ Client release checks can be incorporated into the same mechanism. That is, when Ublu contacts the "mother ship" to find out what's current, the mother ship can send release information not only about Ublu but also update Ublu's knowledge of current IBM releases. The warning message mechanism then simply checks the local parameter table. Or, if the z/VSE Connector Client and/or MQ Client do their own release checking, that's fine. (I don't know if they do or not.) Ublu could simply try to make sure they do -- issue a warning message if they have their release checking disabled, for example. 3. Kicking off a subsidiary installation script as part of Ublu's installation, to install the z/VSE Connector Client and/or MQ Client. The end user just points Ublu to a particular path (or internal URL?) where the client code is available, and events proceed from there (or not if Ublu's installation script cannot find the client). If the IBM client isn't installed, the end user can skip over that step but then see a warning message ("You'll need to install the IBM client before....") 4. Use operating system packaging (.deb, .rpm, SMP/E, etc.) to specify/drive pre-reqs and co-reqs, at least on a warning basis. These are just examples. I've seen some nice implementations of these and similar approaches. -------------------------------------------------------------------------------------------------------- Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
