Most people do not appreciate the scale of the JCL disaster. I think it's important that people who have experienced JCL problems first hand should publicize their experiences. Until recently, the common belief was that JCL had no serious problems, because:
1) so "few" people complain about JCL,
2) those complaining were not using the latest JCL version or did not know how to set up JCL correctly,
3) other plaintiffs had "impure" motives and hence could safely be ignored.
Over the years, those who can act to improve JCL have internalized a set of world views and eventually became immune to criticism. I'd call it "self-perpetuated group dynamics in presence of diluted responsibility." The history of JCL would certainly fascinate any aficionado of social studies. I am also beginning to think that email is not such a perfect means of communications. Many of the problems could have been probably solved ages ago by direct face to face communication.
It would be unfair to single out JCL in particular. Most popular projects suffer from the same illness. The project becomes popular, in some cases by pure luck. Popularity leads to self-confidence, which can lead to arrogance, fatigue and ossification, or a combination thereof. Thus, success in software projects may paradoxically result in the loss of the capacity to innovate. I think this is particularly true in open source projects, even here at Apache. However, the lack of ability to innovate should not be considered a fatal flaw because most users of software crave for stability, not necessarily the latest gimmick, a.k.a. innovation.
Coming back to the issue at hand, developers suffering from software bugs in product XYZ should report them profusely. Developers of product XYZ should not be expected to somehow guess those bugs by virtue of their infinite wisdom.
At 12:45 PM 3/25/2005, Jeff Turner wrote:
Yes - but unfortunately a large number of open source projects have adopted JCL, without understanding the pain they're inflicting on users. Not understanding, they have no reason to migrate to something different. However if there were a 'JCL 2.0' available, there is a clear migration path. Switching becomes the safe, officially endorsed option.
I wonder if anyone appreciates the scale of the commons-logging disaster. Personally I have spent *weeks* fighting commons-logging issues. Our company's product (JIRA) ships two .war's, one with and one without commons-logging. Just this week I ended up forking an open source project for internal use to get rid of the commons-logging dependency, because I simply could not get its logging working under Tomcat (which ships JCL). Multiply this experience across the whole industry (JCL is that pervasive), and you see that a *ridiculous* amount of pain has been caused by a stupid little log wrapper.
So please don't let egos or politics screw up any chance of a solution to this mess. Take something that works (UGLI sounds the best candidate), call it 'JCL 2.0', encourage everyone to use it, and we can all get on with life.
--Jeff
> -- > Ceki G�lc� > > The complete log4j manual: http://www.qos.ch/log4j/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ceki G�lc�
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
