Thoughts on process

Hi all,
Well I have some exposure to several OSS projects, some small, some 
large, some backed by a company and others by individuals, and feel 
that I have something to contribute to this discussion so here goes:

When OSS projects are backed by a company there is always an underlying 
feeling that the company is keeping some conversations internal (I saw 
this quite a bit on the NetBeans lists when they were initially 
OpenSourced). To help alleviate this problem Sun allowed a non-Sun 
individual onto the Board which managed the NetBeans project.

When companies back OSS projects you can have in-fighting amongst the 
companies (view IBM's and Sun's with respect to the Xerces project and 
two different architectures for the next-gen parser crimson and 
Xerces-2), not saying that will be the case here, just a heads up.

OSS projects started by individuals typically follows a Benevolent 
Dictator model, I am involved in one of those right now with Zoe 
(http://guests.evectors.it/zoe/), where Raphael Szwarc did all of the 
coding himself and was coaxed into releasing it into the OpenSource 
domain. He, of course, still retains full control over the project and 
decides what the next steps with Zoe will be and where we should focus.

The technologies and methodologies you decide to use in managing the 
project information and release it to the outside world are secondary, 
what is primary is making sure that your message is loud and clear.
What is the company about?
What are you releasing?
What are you keeping proprietary?

Now, I have worked with a lot of OpenSource projects, using, 
contributing and commenting on so here are some general observations of 
what not to do:

1) Don't make the Web site hard to use:
listen to your users, what information is hard to find, what are they 
looking for. As your project grows so will the amount of information 
about the project grow (hopefully ;-). You _will_ have to redesign the 
site probably about every 6 months or so. And if you use a Wiki, don't 
count on it to solve this problem, information could easily get buried. 
Make sure whatever tool you do pick it allows you to move information 
around after the fact, to promote or demote it.

2) Make all documentation available on-line:
I'm not sure how comments and/or javadocs (I know it's Python so please 
forgive me, I'm a Java developer ;-) work in Python, but make these 
available on-line, don't force developers to build them on their 
system, sometimes they just want a quick reference. API's should be 
easy to navigate and figure out, not cumbersome. Other docs should be 
on-line and searchable (good searches), this is the number one way that 
people navigate a site. If they've visited a site before and want a 
document they search.

3) Don't use frames:
This makes things hard to link or forward to other people, Eclipse does 
this and it's annoying as hell to forward a page to someone.

4) I would advise asking your users what the use the most first:
Generally your users/developers are going to be looking for different 
things. Right now the users are probably going to be the developers, 
but this will change once the product becomes more widely accepted. You 
may want to split the site into these groups (dev.osafoundation.org, 
osafoundation.org), just a suggestion.

5) Be flexible:
Evaluate technologies with flexibility in mind. Will it allow me to 
take the data out of it that I put in? Can I easily re-categorize my 
information? Does it allow for multiple users at differing levels of 
access?

I guess that's about all for right now. Let me know what you think.

-warner

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process