> It isn't a common practice in an open source community. mysql.org just got
> flamed to hell for requiring people to log in in order to download mysql.
You can download from jcorporate without registering!
> As for internal use only, that isn't entirely true. Your argument is based
> on you saying about that you need to justify the cost of maintaining these
> services by using the registration information for "something".
Being for internal use only - is entirely true. That "something" is the
value of a qualitative number of people in our community. Currently we have
approximately 12,000 registered users.
> > 2. Registering enables creating and building a tighter sense of
> community...
> What does the forums have to do with access to anonymous CVS?
Hm, that might be a mistake. I'll have to check on that. In any case it
could be considered another eService.
> Apache.org receives something like 3+ million connections/day. We
> don't have
> corporate sponsorship other than what is donated. Anything more
> than static
> pages taxes the *shared server* (that is shared by something like 500+
> developers) so it is a policy across all of apache.org that
> static files are
> the way to go.
With the tools at hand I perceive sites increasingly going more dynamic for
easier maintenance and for community building.
Jcorporate invested the time in developing the applications Jcorporate uses
to drive it's site. It's interesting that several areas such as forums, faq
and helpdesk began for our own use and have evolved into our product
offerings. It's not so strange that those applications we need ourselves
are the same needed by companies for community building and collaboration.
And here's nothing like eating one's own cooking for QA and ideas. We use
eContent, our content management system, for managing the projects. Within
the projects we are seeing the need for more documentation
collaboration/management with our contributors, and will be soon using
eContent so that our contributors can check out/check in, have workflow etc
for managing this process. Its very exciting.
> I did look at his work. Honestly, I wasn't exactly impressed at the time
> with his code. Last time I looked, it was back in June. Maybe his code has
> improved since then, I know mine has
Vague.
> Needless to say, a quick grep through the code reveals that he is
> the author
> of quite a large portion of the code which substantiates my
> earlier claims.
One might think that this is appropriate for the lead developer ;).
Jon, enough already - your earlier claim was "Expresso is a framework done
by...one employee" not that he is author of a large portion. Interesting how
your claims change to suit your purpose.
As for much of the rest of your email it degrades from there with opinions
without factual basis; and therefore I can see no value in continuing this
discussion.
i.e.
I don't know where you got the idea we had a booth at a conference. I'd
suggest you get facts.
Both Turbine and Expresso are free; with free support on the list.
snip
> We offered to work with you in the past and you blew us off.
This topic was better left alone and I am surprised that you brought it up.
I am at odds with myself on whether to answer or not.
Factually speaking about 2 years ago I approached Kevin Burton about the
idea of combining efforts and strengths into creating one framework - and
that was one of primary reasons I came to ApacheCon in Orlando. We offered
to contribute the Expresso code to Apache provided we could retain copyright
for the substantial effort of years code (in dev since '96) we would be
contributing. Kevin was at first optimistic because there was a similar
arrangement with a couple of other Apache projects when the originator
retained the copyright. However, the answer came back a polite "No". We
still considered it, impressed with meeting with Brian.
The other factor in our decision was you made it abundantly clear in Orlando
that all decisions would be yours and the first thing you'd start with was
throwing away dbobjects - one of Expresso's core strengths. So much for the
concept of teamwork and collaboration on decisions. As you said yourself
today you are "very opinionated". The one difference is while to you, "That
isn't a bad thing IMHO", my view is closemindedness can detrimental to a
project. So while no one is wrong - there was a philosophical difference
that made this not win/win for us.
It didn't much matter because the frameworks really had considerably little
overlap and we continued on in different directions. If there becomes an
opportunity where collaboration would be possible I would be ecstatic Jon.
My interest remains today collaborating with the OSS community for the
greater good of the Java market. Our integration with other components, Java
Standards and most recently Struts are the results of our commitment.
Sandra Cann
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
