At 22:28 26.01.2003 -0800, you wrote:
<my-opinion>
As it stands right now, log4j does not have enough active committers. We
have a number of committers listed, but not very many of them are actively
working to address issues, add features, fix bugs, etc. I don't know the
reasons, and I am not going to judge. But I strongly feel that we need more
active individuals to lead/take log4j into the future as a healthy
(healthier) open source project. There are all sorts of things that could
be worked on to make it a better tool/library/framework. Heck, if we just
had one committer that was dedicated to evaluating and applying submitted
patches from the user base, either in the core library or a sandbox, that
would be a step in the right direction.
Maybe bringing everyone together at "logging.apache.org" will help bring new
faces and energy to the project. But it might also drain resources from
log4j as well. If we start spending our time trying to figure out how to
inter-operate between the various languages/frameworks, what happens to
other important items we need to be doing for log4j? One important issue
right now is increasing performance. We've had some ideas and proposals on
several fronts. People only have so much time to devote to any subject,
open source projects included, and an issue like performance strikes at the
core of the log4j framework. It is going to take a fair amount of effort to
understand the issues, figure out the changes, and then implement them
without completely changing the current api. Are we going to be able to
focus on this issue, as a team, and make it happen for v1.3? v1.4? I don't
know. I want to make it happen, and I very much want to be part of the team
figuring it out.
I hear you. Now, bear in mind that log4j is competing against JDK 1.4
logging which offers similar functionality, at least at the surface.
We can take pride in having influenced JDK 1.4 to the extend where it
just looks like a pale copy of log4j. However, we must also
distinguish between hype and reality. When log4j was won second place
in Javaworld 2001 annual awards, there was a lot of noise but not many
contributions. Contributions come in many flavors. They come in the
form of participation, as actual code or as ideas. In the course of
time we have established log4j as the de facto logging
framework. Ideas and contributions continue to flow in. We don't
always act on them immediately but that does not mean they are
lost. They will surface again in due course.
Log4j has been around since early 1999. It started with one or two
downloads per day to about 1'000 (one thousand) per day in 2003. Log4j
is clearly a niche product. Nevertheless, sustaining its development
takes a lot of time and energy. Fortunately, the sales of the complete
log4j manual suffice to pay for my rent and food such that I can
continue to devote much of my time to log4j. (In case you are
wondering, writing a book will not get you rich although it will put
food on the table.)
It is true that there was not much coding activity in the last two
months or so. My log4j book is very near completion. We are making
progress. However, we are doing so slowly, organically...
Being a niche product, log4j cannot never attract hordes of
developers. Tomcat, JBoss can. Log4j cannot. Log4j does not cover an
area wide enough to keep everyone busy and interested. However, open
source still works in the case of log4j albeit differently. Developers
come up with a great idea, suggest it on log4j-dev, sometimes even
implement it and then leave, rarely to be heard of again. That's
cool. It is just not the fairy tale world of "The Cathedral and the
Bazaar". No! Actually it *is* the "The Cathedral and the Bazaar." In
the bazaar, things just don't go according to the original plan. :-)
Actually, I am extremely happy with the current state of affairs. Two
active comitters might be just the right size for a project like log4j.
As for applying patches, I intend to spend a good part of February
doing just that, but only after my book is finished.
I don't mean to sound dire or bleak. I just think that we should seriously
look at the health of the project and what this new logging group will mean
and how it will affect log4j.
</my-opinion>
So, what does "logging.apache.org" really mean? What would it really be/do?
Is the goal logging interoperability or is the goal to bring the like
frameworks together, under one umbrella? Or something else?
Both. Bringing the log4X projects together is one obvious and immediate
goal. Adopting inter operability as an official goal is another.
What do we envision the structure of this project to be?
> 1) Is inter operability a realistic goal? Is it possible at all?
We may not know until we sit down to seriously discuss it. Assuming that
one can control both ends of the serialization, yes, it should be
theoretically possible.
I also think it is possible but we won't find out until we actually try it.
> 2) Is everyone comfortable with assigning copyright to the Apache
> Software foundation?
I assume that log4j is...:-). Are the other projects comfortable with the
Apache 1.1 license or do they prefer GNU? That would be a show stopper.
Log4net is using the Apache license already. As for log4perl, they are
using the perl license. We would have to talk to the ASF board whether
assigning copyright to the ASF but keeping the perl license would be
acceptable.
-Mark
--
Ceki
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
