Henri Yandell wrote:
On 2/26/06, Jonathan Revusky <[EMAIL PROTECTED]> wrote:
Towards the end of the skit it is revealed that Cyril is some kid's pet
hamster.
Surely you see my point. The very "seriousness", the formality around
the pet hamster's funeral makes it far more of a joke than it could ever
be otherwise. Likewise, the "concept of release" can be serious and all,
but if the thing being released is something of a joke, some abandonware
that was left in some half-baked state, doesn't all the "seriousness"
just make the whole thing even more of a joke?
It doesn't seem like a joke to Cyril's owner.
Well, of course not. He, and everybody else taking part in the ceremony
is taking the whole thing *extremely* seriously.
But that is precisely what makes the situation so comical to an outside
observer....
Users of DVSL won't be
happy to learn that the binary jar in the Maven repository they have
been depending on is not reproduceable; there's no source and there's
no tag in CVS.
Well, it's not *really* unreproduceable. At least in principle. There
is, after all, a version repository, and in principle, you can
reconstruct the state of the code of any given date in the past from
that. And probably, since no further development ever took place, the
code in the trunk does correspond to the code in the .jar. Most
likely.... I dunno... But in any case, if I (or anybody) want to hack
the DVSL source code, I can get my hands on some source code to hack and
maybe do something with it. If I want...
But really, let's face it: somebody who has made a significant
investment in DVSL has bigger problems than the fact that the CVS wasn't
tagged when that specific .jar file was put up. That's a second-order
(if not, third or fourth-order) problem.
Or let me put it this way: somebody who made a significant investment in
using DVSL back when is not in a good situation really. He is relying on
something that is not being actively developed or maintained or
supported. Nor was a migration path offered to anything else.
Let's suppose that, contrary to fact, the release you mention had a
corresponding CVS tag. Do you think that the people (if there really are
any) relying on DVSL would be in a _significantly_ better position?
There's an informal promise from the ASF (and open source in general)
that binaries are released with source; there's no promise that
projects will be kept in active development when the community is not
interested.
There isn't an absolute promise of that, I guess. However, I think it's
safe to say that many people opt for ASF projects because they think
that the likelihood of them remaining active and supported is much
higher than with a random project they find on sourceforge.
Similarly, if I invest in a blue-chip stock, like General Electric or
Exxon or something, there is no absolute promise that the company will
not go out of business, and the shares will become worthless. In fact,
this kind of thing does happen. However, these companies are considered
to be blue chip investments precisely because the probability of this
event is reckoned to be extremely low. (In fact, this kind of belief in
this case looks to be pretty well founded. The likelihood of GE or Exxon
going bankrupt in the foreseeable future surely is negligible.)
Anyway, structurally, it's like you're arguing that, because investors
were never promised that the company could not go out of business (with
the investors consequently losing their money) the company going
bankrupt is therefore not an issue that should cause any concern.
That seems like extremely fallacious reasoning to me.
Meanwhile, it is a constant theme in my own private discussions with
people that, even when they recognize that a given ASF project is
technically inferior, they at least feel that the ASF project is somehow
the "safe" option. These people have this feeling that some random open
source project may easily just be abandoned tomorrow and that something
being on ASF provides some assurance (I don't say 'guarantee') of
continuity. This is quite important in people's decision making.
Fortunately your use of the term 'abandonware' above makes my point
for me - there is no such thing as abandonware in open source,
I can't agree with that statement. If I abandon a pet dog, it is true
that some animal lover could adopt this stray mutt and provide it a
loving home. However, the fact that somebody might do this doesn't
contradict the fact that the dog was abandoned in the first place.
Who can deny that there are open source projects that could be correctly
characterized as "abandonware"? Okay, source is available and somebody
*could* pick them up again, but they are currently in an abandoned
state. Moreover, I think it's safe to say that, in the vast majority of
cases, once abandoned, they remain that way.
a user
is free to continue on if the community in general stops being
interested. However in this case, it is abandonware. There was a
binary-only release (in fact, 4 of them, with 6 dated snapshot
releases) - meaning the users are dependent on shifting sand when it
comes to supporting themselves.
Well, I don't quite grasp this bit about "shifting sand". The sand sure
as heck hasn't shifted for a good while in this case. Frankly, it seems
to me that, if the sand really was shifting, this would be an
improvement in the situation (not for me but I mean a DVSL user) since
it would mean that something was actually happening, that the project
was alive.
But it's not. And that's the first-order problem, isn't it?
Regards,
Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org/
FreeMarker group blog: http://freemarker.blogspot.com/
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
