[Ns-developers] new ns-2 software contributions
Mathieu Lacage
Mathieu.Lacage at sophia.inria.fr
Thu Mar 24 23:51:15 PST 2005
On Thu, 2005-03-24 at 09:34 -0800, Tom Henderson wrote:
> - licensing criteria should be established (e.g., a policy against
> accepting code that does not come with a free software license)
Here, it would make sense to suggest (mandate ?) a preferred license for
new code. Allowing contributors to randomly choose their preferred
license sounds like the best way to end up with incompatible free
software licenses. i.e., a complete mess.
I have never seen a project not mandating the use of an exclusive
license (with good reasons). At best, they allow the contributor to
choose between 2 carefully choosen compatible licenses.
I would like to add:
- conformance to a clear established coding style
- conformance to a clear established set of architectural guidelines
(i.e., use of STL or use of BSD-style lists, etc.)
- detailed ChangeLog entry for _every_ checkin. Scripts can be used to
generate the bulk of these entries. See
http://developer.gnome.org/tools/scripts/prepare-ChangeLog.pl.
Of course, this means that a coding style and guidelines have been
decided upon but I doubt you can make an open source project successful
without either. And no, I do not believe that what currently stands as
the ns2 coding style, shortly described in the user manual, is a
candidate for these rules.
It would make send to make every checkin (not only the major changes) be
inspected for conformance to these rules from now on (if the rules are
clear, it is a no-brainer to spend 30 minutes every morning reviewing
every patch) to make sure that everyone gets used to them. This is the
only way to make sure slow small decay does not get introduced. After a
while, code inspections for compliance with these rules can be done only
on new contributor's code if you trust the existing contributors to
follow the rules.
Finally, if you are serious about creating an open source community
around ns-2, it seems relatively clear to me that you need to provide a
good roadmap to the external developers:
- when is the next release supposed to happen ? Does it happen when you
feel it's ready ? Does it happen at date X ? Does it happen when new
feature Y works ?
- what process is used to create a release ? (do you create a cvs branch
or tag ? do you freeze cvs for 2 weeks ?)
- who will handle the release process ?
- what features are scheduled to be in the next release ? will it be a
bug-fix only release ? will it contain new features ? If so, what
features ?
I am aware that all of these items are hard work but these are also the
steps necessary to make an open source project successful: lots of open
source projects die or strive for survival because they did not address
these issues and were unable to handle new contributors/handle long-term
maintenance.
regards,
Mathieu
--
More information about the Ns-developers
mailing list