Part of my work at e-smith is to help build the e-smith community. This mostly means the Open Source developer community, though there are other efforts underway to build communities for end-users, resellers, etc. Interestingly, there is a fair degree of crossover between the end-user, reseller, and developer communities: developers become resellers, resellers start taking part in the development community to better serve their customers, and so on.
Development contributions (e-smith add-on modules, etc)
Testing and bug-swatting
Word of mouth publicity
Nurture potential resellers
Discover potential staff
The main tool we use to build the developer community is our dot-org website. It provides the following features to developers:
News and announcements
Discussion fora
Bug tracking
Contrib upload
Documentation
We run a couple of mailing lists (in particular, the "devinfo" mailing list for developers) and some web-based fora. Interestingly, it has been found that the web-based fora receive much more traffic than the mailing lists.
It has been suggested that the people using the developer website and mailing lists are not as experienced as the general population of Open Source developers, and that they are not familiar with the common use of mailing lists as a communication tool for development teams.
This suggests to me that the e-smith developer community need nurturing not only as "assets" which e-smith hope to attract and retain, but as developers in their own right. Helping them become better developers and more in tune with the Open Source development community will benefit e-smith immediately, by improving the understanding between e-smith developers and technical staff (many of whom are long-time Unix/Open Source/Internet types) and the quality of contributed software.
When I started working with e-smith in October 2000, I was surprised to find that they did not use CVS. To me, and to many other Open Source developers, this is one of the core tools which we expect to find in place in any major project.
As it happens, there are good reasons for e-smith's choice not to use CVS so far: CVS and e-smith's use of RPM as a version tracking tool don't mix well. The typical mode of development for e-smith is to take a standard RPM for a widely-used package (for example, Apache) or an existing e-smith package (such as parts of the e-smith manager interface) then make some modifications. The diffs are included in the SRPM as a patch, thus maintaining a history which shows the original software and the changes e-smith developers have made over time.
In October/November, Dan York and myself started using CVS for the e-smith documentation, which we were converting to Docbook. This was the first step in the direction of CVS.
In December 2000, I discussed CVS with some of the technical team. Benefits of CVS, as I see it, include:
shallower learning curve for experienced Open Source developers
the ability to make small changes without having to roll a new RPM
the ability to easily work remotely
The first benefit is particularly attractive to e-smith as we try to encourage more contributions from the Open Source community.
At the moment, I am researching ways of integrating CVS and the RPM-history-keeping styles of development. One tool which looks promising is "gbuild", which can build tarballs, RPMs, and SRPMs from a CVS tree.
There are a multitude of other ways in which e-smith is attempting to involve itself in the Open Source community. These include:
LUG visits
Announcements on freshmeat etc
Free CDs