The point I am making is this: I will continue to use Orion, whether or not it is open
source. Nor do I feel I am better then the people at Orion or those on this list.
However, if the Orion code were open source, perhaps I or you may solve an error they
can't, partially due to the environment we are running in or we are not caught in the
syndrome of tunnel vision. How many times have you focused on the bigger picture,
only to have a coworker look at the problem and point you in the right direction?
Many times. The people are Orion are very bright. So are the founders of Jboss and
openEJB. Yet I wouldn't expect them to solve all the zillion different combinations
of problems, given all the different environmental variables, by themselves. They are
happy for the bright people out there -- such as yourself. And yes, you can pat
yourself on the back -- as you have made some very good insights in the past into
server issues. So whether Orion is open source or not, is a d!
!
!
ecision for them to make. I respect what they choose either way, but I still feel
open source is better.
-----Original Message-----
From: Jeff Schnitzer
To: Orion-Interest
Sent: 2/17/01 4:25 AM
Subject: RE: ms access & Orion?
>From: Joseph B. Ottinger [mailto:[EMAIL PROTECTED]]
>
>Why do you say "pity?" (I'm assuming you don't mean "piety" here.) Why
>should it be open source? Do you think you can apply patches
>faster than
>the Orion team? (I don't think I could, nor do I think you
For me, the value of source is not that I would be able to fix bugs -
although I might very well be able to do so. The real value is that
source code substitutes reasonably well for documentation.
Here's a hypothetical exception for you:
com.evermind.server.rmi.OrionRemoteException: CrypticMessage
at something.you.recognize.if.you.Are.lucky()
at com.evermind.server.http.d3.sw(JAX)
at com.evermind.server.http.d3.su(JAX)
at com.evermind.server.http.ef.s1(JAX)
at com.evermind.server.http.ef.do(JAX)
at com.evermind.util.f.run(JAX)
We've probably all experienced this at least once. Probably it was a
silly mistake in the deployment descriptor, but the error shows up as an
exception in the wrapper or somewhere else. I know I've seen posts to
this list of exceptions which were obfuscated all the way up to the
throw statement. Rare, but annoying as all hell.
I've spent a lot of time in trial and error when a quick glance at the
source code would have answered my question. Nothing documents like the
code.
I've even found the JDK source to be necessary - I had to comb through
the RMI-IIOP source code to figure out what the error codes I was
getting meant. Using RMI-IIOP is like using Orion, but without the
(usually) verbose error messages and support community. :-(
>it, and their model fits them. Going open source means that they get
>relegated to supplying services only, which may indeed be
>profitable, but
>is profit the only motive? (I say no, because if it were, they'd sell
>Orion for more money.)
I should point out that shipping source does not mean the product has to
be free. Resin is a good example.
It does open up the opportunity for competitors to see potential trade
secrets. I don't know what black magic is under the covers, so I have
no idea if this is a concern. Given how far ahead of the pack Orion is
regarding the emerging j2ee specs, I suspect it might be.
Personally, I've never seen a development tool or library documented
sufficiently well that I didn't feel a need for source code. I *hate*
trial-and-error programming, but it always consumes an inordinate amount
of my development time. Believe me, I read manuals cover-to-cover, but
even the good ones haven't stood up under fire. And the bad ones have
just been plain wrong :-)
I'm happy to continue using Orion, even without source code, mostly
because I've already gotten over the worst of the learning curve. But
there were times when I would have jumped on JBoss in a second if it
supported EJB2.0. I wonder how many people who don't need the new spec
features or have bigger pocketbooks have bailed because of documentation
issues, and I wonder if shipping the source would be a quick
half-solution to this problem.
Jeff
