|CoverYourASP --> Snippets|
|"Snippets" are mini-articles - they allow me to very quickly add answers to your frequently asked questions, and add brief explanations for topics that you've searched for without success. So, everytime you send an email or perform a search, chances are a new snippet will be the result!|
3 May: Hakan Eskici talks about open-source
Hello CoverYourASP members!
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.
Now, let's go step by step:
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.
* 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.
What is OpenSource ASP?
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.
Codebase Maintenance / Stable Codebase
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 imes.
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.
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 ;)
2eNetWorX OpenSource Projects