Hi,
I am someone who probably fits the picture you paint. I found the project a
few years ago and have been half monitoring bits of it here and there. I
was put off by a number of things and eventually gave up - so maybe my
thoughts may be of interest
At 03:00 18/9/00 -0400, you wrote:
>Now I have always promoted the idea of there being multiple
>implementation of every component. With the best being chosen by
>natural selection, but this hasn't worked each component is too strong
>and just won't die. The problem with this is that the whole project
>will die off because new members don't know where to start and then
>leave.
I have always disliked this approach segregation of projects is rarely a
good idea. So much more can be learnt by cooperating and building together.
Sometimes it is impossible to fix the old version and you have to change
from evolution to revolution. In many cases the new project will fall short
or die out but sometimes it survives and is actually better.
At apache we allow a seperate proposal to be active in the CVS tree and
different people can talk over the second bit (or alternatively the
branch). Sometimes parts of the proposal will be merged into main trunk and
sometimes proposal branch will just be an ideas testing fround. Interesting
approach and seems to work. It also creates a lot less friction if multiple
developers want to work in same area.
I am usually also deadly opposed to people including their own names into
projects (ie rheise-os or whatever it was called) because it implies less a
group. It is a better idea to come up with code-names.
>So far each developer has worked on there own project with little help
>from other developers, and nobody wants to give up there project and
>work on someone else's.
One thing I noticed here is that there is faaaaar to much re-invention of
the wheel. I saw a lot of projects mentioned that were started but never
finished but were almost 100% identical to external projects.
You should standardise as much across the projects using external tools if
neccesary. Theres a build tool here when there is the far superior Ant
(jakarta.apache.org) or you have rewritten scripting tools when there is
already a large number of java scripting languages around (BSF includes
javascript, python, lisp, tcl etc).
Internally you should restructure to all work together and ideally work
with external teams. I am not sure how much of code can be shared between
the VMs here and other VMs but it is worth looking and trying to shared
code at least.
>Now for this to change we need to all stop working on our own projects
>and work together on a new unified project. We should treat all the
>current project as prototypes and leave them behind, and just bring all
>the good ideas with us on the new unified project.
+1
thats always a good thing - it mean frictions at the start but in long run
maybe better.
Another thing to consider is making consistency across all the projects.
Currently copyright is assigned to various people and licensing is
different etc. It is much better to assign copyright to a non-profit
organisation as that means if the owner of code leaves the rest of team are
not screwed. You could look for a sponsor group if you don't want problems
of setting up jos.org - there are a few around.
Another thing to consider carefully is copyright. GPL and LGPL are
extremely bad for java programmers - because of javas linking model
LGPL==GPL and that is why many gnu java libraries have modified LGPL.
Another thing with the licensing is that it will determine who can and will
work with you. For instance GPL means that many commercial bodies will
simply not be able to touch it - unless it is a complete product because
they have too much to loose. BSD-like licenses however see a lot of input
from commercial people. At apache (which uses APL a BSD-like license) there
are some projects where 3-4 or more of the people are payed to work on the
projects part time. This does great things for code - and also some bad
things. Sometimes the commercial guys try and do hacky things because have
a deadline looming. Of course you have to have some strong willed people to
keep you on trac aka Design Nazis :P.
So unless you want to be product complete before you try and get people
payed to work on it then some of the other licenses should be considered
before L/GPL
>For this to succeed we need to jump into the deep-end, new mailing
>lists, web site, cvs server. We can keep the old stuff around but only
>for reference.
It may also be worth drawing up a project guidelines on how projects are
run like http://jakarta.apache.org/guidelines/index.html.
Also another thing that I would consider important is homogenizing
web-pages. It is damn near impossible to find anything as it is currently
setup - and if you stumble across the page - you are not sure if it is up
to date or obsolete or even used anymore.
Another good idea would be to standardize layout of directories in each
project and seperate projects out into seperate well explained modules.
Personally I don't think a Wiki approach is the *right* approach - at least
not for this. It is too damn hard to maintain, manage, navigate and
standardize.
If you were to do this sort of thing I would gladly join up. FWIW I am
currently working on Avalon Server framework at apache. Currently there is
only a few applications built on top of it but soon many of other Avalon
projects will switch to it.
In the future I plan to finish a MessageServer (NNTP/SMTP/IMAP4/POP3),
start a FileServer (FTP/Free-net style/ Revision control in built) and
write a simple DNS resolver + dns server.
This I hope will be completed by March - at least that when I pencilled in
deadline and I will be getting payed to dev this stuff. I als have a lot of
stuff like echo/discard/other minor protocols during testing ideas on
Avalon. If you were to offer support for multiple users I would also gladly
do an ident server :P
Of course this is all under APL so it would have to be compatable with
whatever license you choose. I guess if I was in your position I would
force all non-native-VM stuff to be something either Mozilla or BSD like
but thats up to you :P
Theres my thoughts - hope I didn't offend anyone too much :P
BTW if you are standardising projects structure you may want to wait until
end of november as I am trying to get a standard layout that all projects
conform to defined at Apache. If that is the case then it will slowly
trickle out - many of the other java projects rely on Apache tools and will
gradually conform.
Cheers,
Pete
*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power." |
| -Abraham Lincoln |
*------------------------------------------------------*
_______________________________________________
General maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/general
