CoverYourASP goes OpenSource :: Article - 2eNetWorX

CoverYourASP goes OpenSource

by Hakan Eskici

James Shaw of CoverYourASP has just made a critical decision, he selected OpenSource as their development model. 2eNetWorX is at their service to help them with their OpenSource movement by the means of sharing experiences.

Introduction

I am glad to share 2eNetWorX's OpenSource experience with the CYA gang. Please consider this article as an introduction, the ideas will evolve with time. Please contribute your ideas and comments at the CYA mailing list.

What is OpenSource?

OpenSource is a programming model. You simply give permission to the other developers to take your work and develop upon it. This absolutely guarantees evolvement of the software.

OpenSource model:

* Allows other developers to take the project and build their work upon it
* Protects the original software with copyrights
* Ensures the derived works must remain OpenSource as well


See http://www.opensource.org for more info.

We cannot compile ASP code so it must have already been OpenSource you might think, in fact this is not true. OpenSource is not only about the public access to the code, the key point is the permission you give to the other developers. Of course the code must be public, but this is not enough.

The Problems and The Solutions

This is an art. Working together in a team environment requires special skills. It is hard to enable different developers to work on the same piece of code. Strict rules must be defined to determine the permissions. Access to the codebase must be automated.

We need a "code server" which enables:

* Assigning user and file based permissions
* Downloading / uploading the code (checking out / checking in)
* Tracking and reporting the changes (history, diff)


We also need a "code editor" which is able to talk to our "code server". Microsoft Interdev and Macromedia Homesite is able to connect to source code control providers through the common api.

Linux family has a tool called Concurrent Versions System (CVS) for this purpose. Microsoft has the Visual Source Safe (VSS). Although CVS users are very well internet enabled, VSS still lacks it.

Having a CVS server seems to be the best solution for now. There are sites which will give you an CVS space to work in, SourceForge is still the best OpenSource initiative for most of the parallel development needs.

Developing a custom "parellel development tool" is a good option for poor ASP developers. There are some attempts for web based parallel development tools, see rdude's CodeBox at 2eNetWorX User Uploads.

(My personal approach would be developing a custom solution which implements the Internet Engineering Task Force's Versioning Extensions to WebDAV standard as defined by rfc3253 and rfc2518.)

When the developers start to take the project and improve it to fit their needs, the new copies of the project start to progress in different directions. The branches might have different functionality and even technology.

Code branching can be avoided if enough resources are assigned, a good project manager can suggest (or even dictate) the desired direction and make sure that the developers comply with the requirements.

The codebase stability is very important, especially the core parts. The vital parts of the project should be kept protected. Once the control is lost, there is no return. Most of the time, a wrong decision is made in the core and the rest is build upon it. For example the Tcp/Ip stack of Linux is rewritten from scratch three times.

2eNetWorX Case Study

Our parallel development methodology is a little bit different, mostly because of insufficient resources. The project owner usually develops most parts of the projects alone. When it is released to the public, the contributors download it, review and express their comments using the feedback tools on the site. These feedback tools include a bug submission, feature request and an interactive forum. This interactive discussion enables us to build a to-do list. Then we start on delivering our agenda. Contributors upload their work mostly as small bug fix patches. Sometimes we collect the small things together to build our next release. This is the main cycle for our poor parallel development efforts.

Conclusion

Well, enough about the introduction. Let's get to the point. Let's be a part of the solution, not the problem.

1. How do the updates get posted back to the site?

A simple file upload tool will be enough. See the answer #4 as well.

2. Does the actual site get updated by everyone, or just the published zips?

The best way to do this:

Keep two copies of your site, "release" version at www.coveryourasp.com, and the "development" version at dev.coveryourasp.com. Using the parallel development strategies, enable the contributors to work on the development version.

When a stable state is reached, take a snapshot of the development site and "release" it.

In fact, your working copy at home is the "dev" site, and the live site is the "release" site :)

3. Who does the quality control?

The project management team. (Ideally, the owner and a few contributors). The contributors must be aware of the requirements, the coding notations etc. Having a check list would be very handy.

4. Who stops malicious code getting into the download?

Malicious code is avoided best if a good file / user permissions management tool is used. Of course there must be an authoritative mechanism in the place, like the project management team.


Welcome to the OpenSource club, enjoy ;)


Hakan Eskici
2eNetWorX OpenSource Projects
http://www.2enetworx.com/dev