On 2005.02.05, Vlad Seryakov <[EMAIL PROTECTED]> wrote:
>
> In my case "something" is: i feel that contributing into AOLServer
> project feels like asking permission from AOL, is AOL willing to
> accept or even consider whatever additions i am offering. In most case
> they will be rejected because of stability, direction, code style or
> pure "messed up code".
[...]
> I support my patches and develop different version of aolserver,
> allowing differnet protocols, for example HTTP or SIP over UDP, but i
> am sure AOL will not accept them, so i keep them to myself. There are
> many small improvements can be done and i 've done a lot of them,
> binder for example, many modules. They are public but still, core is
> what AOL provides.

So, for a moment, ignore the existance of AOL.  What does the rest of
the AOLserver Community think about your patches?  I don't mean people
just saying "oh, we think Vlad's patches are great" -- I mean, who else
has written code that needs to run on a version of AOLserver built with
your patches?  (This is my "actions speak louder than words" principle.)

> I understand that AOL pays core developers but i think this is what
> makes me feel this is not open-source project, this is AOL project
> with open sources.

AOLserver is not the only open source project that has contributors who
are paid for their contributions to the project.  Linux is a fine
example where people who've contributed to Linux were paid to do so.
I'm sure there's other examples of this which I can't think of right
now.

I think the difference here is that, for the AOLserver Project, AOL is
the largest financial contributor to the project.  I would love to
change that, too, and have other large financial contributors to the
project, but I don't yet see how to do it.  As usual, I'd be glad if
people in the community would do stuff to help accomplish this.

> It is not bad and AOL benefits from this greatly, so many free
> QA/testers but still, AOLserver goes in the direction at least i do
> not agree with.  I think AOLServer should not be pure webserver, just
> another webserver even running by AOL, still just another webserver,
> it has potential to be full-blown application server.

Please explain what the difference is between being "just a webserver"
and being "a full-blown application server."  Isn't a web server that
serves web applications, by definition, a kind of application server?
By virtue of its name, at minimum a web application server?

There's plenty of folks using AOLserver as a generic application server
already.  Some even build commercial products this way.  So, I don't get
it: I think it's already a full-blown application server.  Please list
what features or requirements must be implemented before you think it
is.  That would be very helpful.

> You are great project leader, no doubt, you just work for AOL, it is
> very noticable.

It is?  How so?  I honestly don't think my attitude or behaviors with
regard to the AOLserver Project have changed since joining AOL.  Anyone
who disagrees is free to read back into the mailing list archives back
to 1999, and without "cheating" by finding out exactly when I joined
AOL, point out the messages in the archive where my attitude or behavior
changed which would correspond with me joining AOL.

I have always done what I felt would bring the most value to the entire
AOLserver Community, which includes you, me and AOL -- all of us.  I
don't think that a feature only one entity actually uses should go into
the AOLserver core -- that includes your patches, and a ton of
closed-source AOLserver code that AOL uses.  Yes, there's a ton of code
that AOL uses with AOLserver that's not part of the core, too.
Half-jokingly, don't think you're so special because your patches have
been singled out as not making it into the core -- the same goes for AOL
code, too.  So, we maintain it on an in-house CVS server and build the
code and run it with AOLserver, too.

This is, of course, the benefit of having a very flexible, easily
extendable and highly modular architecture.  Only stuff that needs to be
part of the core in order to function should go there.  And, as time
goes on, you may likely see even more and more functionality come out of
the AOLserver core into their own independent modules.

A list of contributed AOLserver "modules" (for lack of a better name)
has been up on the wiki for a while:

    http://panoptic.com/wiki/aolserver/Modules

Many of the modules listed were not developed by AOL!  That's a
significant contribution from outside of AOL, for a project that so many
people criticize as "not being friendly to non-AOL contributions."  Is
the argument here that those modules should be integrated into the core?
Do you really think that makes sense?  I'm all in favor for an even more
lightweight core, but maybe others aren't?

Perhaps what people are really complaining about is the lack of a
"Batteries Included" AOLserver distribution.  I agree, this /IS/ a
problem that we need to take seriously and remedy.  Lets start actively
working on fixing this problem:

    http://panoptic.com/wiki/aolserver/BatteriesIncluded

Does it make sense to include all 70+ modules in the Batteries Included
version?  Maybe.  Maybe not.  I don't even want to start discussing the
politics behind the decision-making process of what modules go in and
what modules don't, but to give you a sneak preview of my thinking: no
orphaned modules go in -- every module must have an active owner.

...

I've covered a lot of ground in this email.  Please take some time to
think about what I've said here, and I'll forward to hearing your
responses.

-- Dossy

--
Dossy Shiobara                       mail: [EMAIL PROTECTED]
Panoptic Computer Network             web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to