Just my two cents worth. .. don't freeze your vision. Have one (we have a very general one for POI plus some very specific ones for each release), but you have to allow people to come in and say "I want this by 2.0" even if its a 4.0 for you.
For example we landed a very talented developer for POI by allowing some features I didn't think were very important in our next release (they turned out to be more important then I realized but thats a long story). He's now involved in far more than what his original plan was. Its also a strategic advantage to have someone working tomorrow while I'm sleeping (he's an Aussie). I try and constantly say "Okay here is the release vision as I understand it to date" for the next 2 or so releases regularly to keep it constantly discussed. You have to remember opensource is very fluid. You can't *nail* it down the way you can other projects. The best way to do this is just release as often as possible. This will make people button up code *for the release* including yourself. Some folks will come in with the new features long before you're ready for them. MS doesn't have that because they fire those people ;-). I figure if one guy wants it bad enough to do it himself, then probably a hundred want it almost bad enough ;-). Keep user needs in perspective. Users are your future development community and are really an undervalued commodity in open source projects. I realize (theres a whole paragraph on this on one of the jakarta who we are pages), that having a bazillion users isn't as big of a deal as it is to a commercial project, but it sure as heck helps. Its also a wicked career incentive (that I didn't even realize) for developers on the project. Lastly, highlight the heck out of the accomplishments of the developers on the project. Don't suck all the limelight. Avoid it like the plauge, you'll get yours. (yours may be a barrage of poorly expressed emails where you quickly diagnose the problem as a mater of failure to meet the relative intelligence requirements, but you'll get yours ;-) ). This advice is for everyone on the project ;-). (great positive spiral dontcha think). Anyhow thats my opinion. -Andy On Tue, 2002-01-22 at 12:33, Jeff Prickett wrote: > Ceki Gulcu wrote: > > > > In your opinion, what are the key factors in nurturing a developer > > community? > > > > I know what does not nuture a development environment. > 1. Working in a vacuum and hoping someone magically finds out. > 2. Mispresenting (Intentionally or Unintentionally) the status of the > project. > 3. Not having a clear vision of what features we want to see and when. > > Actually, I am going to put my flame suit on before I say this, but I > was reading an MS Press book by Jim McCarthy (VC++ manager) called > Dynamics of Software Development. He outlines 50 some odd "rules" of > software development. > > One rule is to have a Multi-release technology plan. Its just a big word > for a document that outlines which features will be available in what > release or in what time frame. Ideally, this document should have the > buy in of the whole development team. > > I think what Mr. McCarthy is trying to do with the Multi-Release plan is > to create Vision. Great communities development or otherwise share a > common vision. > > The multi-release technology plan serves two purposes. It establishes a > vision and then breaks it down into a set of smaller steps which are > easier and less frustrating to accomplish. > > When I have a community of developers around icalendar. I am going to > borrow a page from the MS playbook and create a Multi-release technology > plan. > > > -- > > Ceki > > > > > It is very easy to monday-morning quaterback and second guess the > > > decisions that were made in the distant past with perfect 20-20 > > > hindsight. Some might even find it amusing to single out some of the > > > participants and try to act as the judge, jury, and executioner of > > > that person's reputation in the court of public opinion. > > > > > It is easy to play Monday morning quarterback. One of the reasons I > stayed away so long was the initial dread of trying to explain what had > happened (why I "quit", why iCalendar had > failed). > > <snip> > > Jeff Prickett > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
