Recommendations for PHP Form Validation Script

[Phil Powell]

Where can I find an online PHP form validator script library to use? I
have tried hacking the one here at work for weeks now and it's getting
more and more impossible to customize, especially now with form
elements that turn out to be arrays that have to be compared with one
another!

I have one form element, languages, a checkbox group. Beside each
checkbox is a dropdown, proficiency (which will become proficiency[]
alongside languages[]). The crux of the matter is that I have to
compare a checked language with the selected proficiency, the
proficiency dropdown beside the checked language must be selected;
furthermore, at least one language must be checked, up to 4.

To complicate matters further, Javascript client-side validation is
forbidden due to Section 508 U.S. Government compliance putting a lock
on any client-side validation script. Section 508 dictates that all
things in <script> tags must be followed by <noscript> corresponding
logic, which is impossible for validation, so no client-side
validation.

I am tired of hacking this existing set of classes and about 50
methods per class to validate more the more complicated forms I have
to develop. I didn't even mention that you have a group of form
elements pertaining to "job history": about 15 textboxes, 3 radio
buttons and 5 dropdowns - PER JOB HISTORY that will dynamically appear
per user clicking a "Add New Employment History" button. So now you
will have jobTitle[], jobAddress[], jobStartDateMonth[],
jobStartDateYear[], jobEndDateDay[], etc.

So, basically it's either I keep hacking at the existing code.. or I
find an existing form validator package out there. Recommendations,
anyone?

Thanx
Phil

"Phil Powell" <so*****@erols.com> wrote in message
news:1c*************************@posting.google.co m...

To complicate matters further, Javascript client-side validation is
forbidden due to Section 508 U.S. Government compliance putting a lock
on any client-side validation script. Section 508 dictates that all
things in <script> tags must be followed by <noscript> corresponding
logic, which is impossible for validation, so no client-side
validation.

Why is it impossible? Just make a self-validating form (i.e., submits to
$_SERVER['PHP_SELF']), and insert the server validation code in the
<noscript></noscript> section. Something like...

if ($_POST['name'] && $_POST['email'] && $_POST['etc']) {
// form has been submitted - let's validate!
doValidation();
}

[Manuel Lemos]

Hello,

On 10/28/2003 02:16 PM, Phil Powell wrote:

Where can I find an online PHP form validator script library to use? I
have tried hacking the one here at work for weeks now and it's getting
more and more impossible to customize, especially now with form
elements that turn out to be arrays that have to be compared with one
another!

I have one form element, languages, a checkbox group. Beside each
checkbox is a dropdown, proficiency (which will become proficiency[]
alongside languages[]). The crux of the matter is that I have to
compare a checked language with the selected proficiency, the
proficiency dropdown beside the checked language must be selected;
furthermore, at least one language must be checked, up to 4.

To complicate matters further, Javascript client-side validation is
forbidden due to Section 508 U.S. Government compliance putting a lock
on any client-side validation script. Section 508 dictates that all
things in <script> tags must be followed by <noscript> corresponding
logic, which is impossible for validation, so no client-side
validation.

I am tired of hacking this existing set of classes and about 50
methods per class to validate more the more complicated forms I have
to develop. I didn't even mention that you have a group of form
elements pertaining to "job history": about 15 textboxes, 3 radio
buttons and 5 dropdowns - PER JOB HISTORY that will dynamically appear
per user clicking a "Add New Employment History" button. So now you
will have jobTitle[], jobAddress[], jobStartDateMonth[],
jobStartDateYear[], jobEndDateDay[], etc.

So, basically it's either I keep hacking at the existing code.. or I
find an existing form validator package out there. Recommendations,
anyone?

You may want to try this popular form validation class. It can do both
client side or server side validation. For the client side validation it
generates <noscript></noscript> sections to be compliant with your
requirements, but if you are not satisfied you can tell the class to not
generate client side validation at all.

http://www.phpclasses.org/formsgeneration
--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

[Matthias Gutfeldt]

Manuel Lemos wrote:

You may want to try this popular form validation class. It can do both
client side or server side validation. For the client side validation it
generates <noscript></noscript> sections to be compliant with your
requirements, but if you are not satisfied you can tell the class to not
generate client side validation at all.

http://www.phpclasses.org/formsgeneration

Oh bother, it takes four clicks to get even close to the files. And each
time I have to wait until the advertising is loaded and finally the
actual links show up. And after all that, I have to register before I
can (hopefully? I gave up here) download the files...

Not the most convenient script repository :-(.
Matthias

[Manuel Lemos]

Hello,

On 10/29/2003 07:39 AM, Matthias Gutfeldt wrote:

You may want to try this popular form validation class. It can do both
client side or server side validation. For the client side validation
it generates <noscript></noscript> sections to be compliant with your
requirements, but if you are not satisfied you can tell the class to
not generate client side validation at all.

http://www.phpclasses.org/formsgeneration

Oh bother, it takes four clicks to get even close to the files. And each

At least you can see the files before having to download the whole
package to your disk.

time I have to wait until the advertising is loaded and finally the
This is a free site where over 600 authors share their code. Developing
and hosting the site costs time and money. Advertising helps covering
the costs. At least the advertising in on topic. You practically only
see ads that have to do with the interests of the site users.

But if you find the advertising so disturbing, in the future there will
be a paid subscription model that for a small montly fee will provide
among other things, access to the site pages without advertising.

actual links show up. And after all that, I have to register before I
can (hopefully? I gave up here) download the files...
Requiring registration before downloading is an option that is up to
each author to decide on each file of their packages.

Registration lets the set keep track of who downloaded what and so make
accurate top downloaded packages ranking. This provides useful
information for the authors, so see how well appreciated are their
packages. As an user you may not appreciate this much, but most authors
find that very motivating and encourages them to keep contributing.

At the same time, when an author updates a package, the site is able to
figure which users downloaded the package and send them a new content
alert message by e-mail. Of course, users that do not want this, may
specify that in their options page.

Not the most convenient script repository :-(.

If you still find thin inconvenient, you can always mail the authors of
the packages listed there and ask them to send you the packages you want.
--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

[Phil Powell]

Thanx for the tip. However, your packaged classes don't satisfy my needs.
The form contents are extremely complicated, consisting of dynamic arrays,
dynamic form element groups that dynamically grow upon a form submit click,
and even a set of enumerative arrays whose values are compared with keys of
an associative array - all within the same FORM! (the form has over 200
elements)

Phil

"Manuel Lemos" <ml****@acm.org> wrote in message
news:bn*************@ID-138275.news.uni-berlin.de...

Hello,

On 10/29/2003 07:39 AM, Matthias Gutfeldt wrote:

You may want to try this popular form validation class. It can do both
client side or server side validation. For the client side validation
it generates <noscript></noscript> sections to be compliant with your
requirements, but if you are not satisfied you can tell the class to
not generate client side validation at all.

http://www.phpclasses.org/formsgeneration

Oh bother, it takes four clicks to get even close to the files. And each

At least you can see the files before having to download the whole
package to your disk.

time I have to wait until the advertising is loaded and finally the

This is a free site where over 600 authors share their code. Developing
and hosting the site costs time and money. Advertising helps covering
the costs. At least the advertising in on topic. You practically only
see ads that have to do with the interests of the site users.

But if you find the advertising so disturbing, in the future there will
be a paid subscription model that for a small montly fee will provide
among other things, access to the site pages without advertising.

actual links show up. And after all that, I have to register before I
can (hopefully? I gave up here) download the files...

Requiring registration before downloading is an option that is up to
each author to decide on each file of their packages.

Registration lets the set keep track of who downloaded what and so make
accurate top downloaded packages ranking. This provides useful
information for the authors, so see how well appreciated are their
packages. As an user you may not appreciate this much, but most authors
find that very motivating and encourages them to keep contributing.

At the same time, when an author updates a package, the site is able to
figure which users downloaded the package and send them a new content
alert message by e-mail. Of course, users that do not want this, may
specify that in their options page.

> Not the most convenient script repository :-(.

If you still find thin inconvenient, you can always mail the authors of
the packages listed there and ask them to send you the packages you want.
--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

[Matthias Gutfeldt]

Manuel Lemos wrote:

On 10/29/2003 07:39 AM, Matthias Gutfeldt wrote:

You may want to try this popular form validation class. It can do
both client side or server side validation. For the client side
validation it generates <noscript></noscript> sections to be
compliant with your requirements, but if you are not satisfied you
can tell the class to not generate client side validation at all.

http://www.phpclasses.org/formsgeneration
Oh bother, it takes four clicks to get even close to the files. And each

At least you can see the files before having to download the whole
package to your disk.

time I have to wait until the advertising is loaded and finally the

This is a free site where over 600 authors share their code. Developing
and hosting the site costs time and money. Advertising helps covering
the costs. At least the advertising in on topic. You practically only
see ads that have to do with the interests of the site users.

I know - I know! I'm not blasé enough to complain about free code,
really. And I'm grateful for all the work the authors put into those
classes. It's just a rather frustrating experience trying to get the
code, that's all. Perhaps there's a way to streamline the process.

But if you find the advertising so disturbing, in the future
there will be a paid subscription model that for a small montly
fee will provide among other things, access to the site pages
without advertising.

Thanks for the info. I'll check that out when it's available.
Matthias

[Manuel Lemos]

Hello,

On 10/30/2003 05:58 AM, Phil Powell wrote:

Thanx for the tip. However, your packaged classes don't satisfy my needs.
The form contents are extremely complicated, consisting of dynamic arrays,
dynamic form element groups that dynamically grow upon a form submit click,
and even a set of enumerative arrays whose values are compared with keys of
an associative array - all within the same FORM! (the form has over 200
elements)

And what is the problem with that? In what way do you think the class
does not satisfy your needs or at least could be used to simplify the
solution to satisfy your needs?

You may want to try this popular form validation class. It can do both
client side or server side validation. For the client side validation
it generates <noscript></noscript> sections to be compliant with your
requirements, but if you are not satisfied you can tell the class to
not generate client side validation at all.

http://www.phpclasses.org/formsgeneration

--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

[Manuel Lemos]

Hello,

On 10/30/2003 07:24 AM, Matthias Gutfeldt wrote:

This is a free site where over 600 authors share their code.
Developing and hosting the site costs time and money. Advertising
helps covering the costs. At least the advertising in on topic. You
practically only see ads that have to do with the interests of the
site users.

I know - I know! I'm not blasé enough to complain about free code,
really. And I'm grateful for all the work the authors put into those
classes. It's just a rather frustrating experience trying to get the
code, that's all. Perhaps there's a way to streamline the process.

The means justify the ends. Once you login, it is straight forward.

Anyway, the site has 4 years and many features have been implemented
upon suggestions of the users. If you have anything to suggest to
improve it in a realistic way, feel free to present your suggestion.

--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

[Zurab Davitiani]

Manuel Lemos wrote on Thursday 30 October 2003 10:27:

Anyway, the site has 4 years and many features have been implemented
upon suggestions of the users. If you have anything to suggest to
improve it in a realistic way, feel free to present your suggestion.

[OT from original discussion but] Here are two:

1. implement the class/package dependency listing. I made this suggestion to
you before, as a part of a bigger one, but not on its own. i.e., if
developer A creates class X that extends or uses developer B's (or his own)
class Y, then there needs to be a simple way for developer A to list class
Y as a dependency, rather than including that class in his package.

This becomes a bigger issue when you are talking about two or more packages
and not just single-file classes. This will also see a better use with much
better OO features in PHP5.

2. I would think number of developers may have already suggested to you, but
there needs to be a way to upload an archive directly to the site, rather
than each file one by one.

Hope this is helpful.

--
Business Web Solutions
ActiveLink, LLC
www.active-link.com/intranet/

[Manuel Lemos]

Hello,

On 10/30/2003 09:13 PM, Zurab Davitiani wrote:

Anyway, the site has 4 years and many features have been implemented
upon suggestions of the users. If you have anything to suggest to
improve it in a realistic way, feel free to present your suggestion.

[OT from original discussion but] Here are two:

1. implement the class/package dependency listing. I made this suggestion to
you before, as a part of a bigger one, but not on its own. i.e., if
developer A creates class X that extends or uses developer B's (or his own)
class Y, then there needs to be a simple way for developer A to list class
Y as a dependency, rather than including that class in his package.

This becomes a bigger issue when you are talking about two or more packages
and not just single-file classes. This will also see a better use with much
better OO features in PHP5.

2. I would think number of developers may have already suggested to you, but
there needs to be a way to upload an archive directly to the site, rather
than each file one by one.

Thank you for the suggestions. They have been on my to do list for some
time now.

1. Class dependency is not hard. However, I have not envisioned how the
user interface would work to let authors pick dependency classes from
more than 1130 approved classes that exist now.

2. Bulk uploading is more complicated. Regardless how the authors upload
their classes, they need still need to enter descriptions and specify
the role for each file. I am not sure how this could be done and in the
end the authors do not complain that it is still bureaucratic.

Package bulk updating would be another issue because the site would have
to know which files are being updated and which are new.

I though of having support to synchronize with a remove CVS server
indicated by the author when the update is meant to be performed. but
not every author has their projects in a public CVS server.
Any ideas to solve these problems in the most convinient way are welcomed.

--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

[Manuel Lemos]

Hello,

On 10/30/2003 09:13 PM, Zurab Davitiani wrote:

Anyway, the site has 4 years and many features have been implemented
upon suggestions of the users. If you have anything to suggest to
improve it in a realistic way, feel free to present your suggestion.

[OT from original discussion but] Here are two:

1. implement the class/package dependency listing. I made this suggestion to
you before, as a part of a bigger one, but not on its own. i.e., if
developer A creates class X that extends or uses developer B's (or his own)
class Y, then there needs to be a simple way for developer A to list class
Y as a dependency, rather than including that class in his package.

This becomes a bigger issue when you are talking about two or more packages
and not just single-file classes. This will also see a better use with much
better OO features in PHP5.

2. I would think number of developers may have already suggested to you, but
there needs to be a way to upload an archive directly to the site, rather
than each file one by one.

Thank you for the suggestions. They have been on my to do list for some
time now.

1. Class dependency is not hard. However, I have not envisioned how the
user interface would work to let authors pick dependency classes from
more than 1130 approved classes that exist now.

2. Bulk uploading is more complicated. Regardless how the authors upload
their classes, they need still need to enter descriptions and specify
the role for each file. I am not sure how this could be done and in the
end the authors do not complain that it is still bureaucratic.

Package bulk updating would be another issue because the site would have
to know which files are being updated and which are new.

I though of having support to synchronize with a remove CVS server
indicated by the author when the update is meant to be performed. but
not every author has their projects in a public CVS server.
Any ideas to solve these problems in the most convinient way are welcomed.

--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

[Zurab Davitiani]

Manuel Lemos wrote on Thursday 30 October 2003 19:32:

1. Class dependency is not hard. However, I have not envisioned how the
user interface would work to let authors pick dependency classes from
more than 1130 approved classes that exist now.

2. Bulk uploading is more complicated. Regardless how the authors upload
their classes, they need still need to enter descriptions and specify
the role for each file. I am not sure how this could be done and in the
end the authors do not complain that it is still bureaucratic.

Package bulk updating would be another issue because the site would have
to know which files are being updated and which are new.

I though of having support to synchronize with a remove CVS server
indicated by the author when the update is meant to be performed. but
not every author has their projects in a public CVS server.
Any ideas to solve these problems in the most convinient way are welcomed.

Just ask. I do have those :)

Now, I don't know the internals of your system, but having used it here are
what I think are some options on how to do those:

1. You are right - dependency may look simple on its face, but details may
end up being slightly more complicated. As far as picking dependency
packages, you could allow class authors to (1) search for packages by name
or description, (2) browse to it, or (3) type its ID; next, you find these
packages, let user select and confirm which packages they want to add as
dependencies, then add them.

One thing to consider in this, at some point, is versioning - you may want
to force developers to enter some kind of version number or an identifier
so that when a package is updated (say B and C are dependent on A),
- package A author selects whether the update he is making may break
compatibility (if A is listed as a dependency);
- if so, then dependent package authors (B and C) are notified of the change
and have an opportunity to check/fix compatibility;
- meanwhile, users on the website are notified whether compatibility has
been confirmed by developer(s).

On a user-side of things, when listing dependencies of a package, you may
want to have a link to "download all" to get all of them.

2. As far as bulk uploading, when an archive is uploaded (zip, tar.gz,
etc.), check every file by path and filename against existing package
entries, then provide 4 sections on the next page as follows:

(A) for the filenames that are already present in the package, simply let
the user know that they will be overwritten;

(B) for the filenames that are new, display a table (or a div/span
structure) for user to enter each new file's description and pick a role;

(C) for the filenames that were present in the original structure but are
missing from the uploaded archive, present user with the choice to keep
each one as is, or remove it from the package.

(D) for files that generated errors, e.g. binary files, etc. let user know
what error(s) occurred, correct errors and retry, or upload those files
individually afterwards.

Complete package update only after user confirms and approves what is
described in A, B, C, and D.

The only thing that you'll be missing is a changelog for each individual
file like you have it now. I don't know for other developers, but if you
ask me, that is not necessary - you may want to ask for an overall
changelog instead.

I don't think this will be "bureaucratic", since most updates should be
covered in (A), (B) would not happen a lot unless there were major changes
or a complete overhaul, (A) and (D) are simply notices, (C) should be a
pretty trivial boolean choice.

One thing to consider is that this may not cover situations when files are
moved around in different directories. e.g., developer moved myclass.php
file to /classes/myclass.php or renamed it. To account for these cases, you
may have to either:

(a) explain on the "upload archive" page that if that is the case, they
first need to make sure the path and filenames in the package match those
in the new archive (if not, modify the package first); otherwise, their
history, including download count may get lost;
OR
(b) in a more complicated case, allow users to provide an option to "merge"
(i.e. update) one file with a different file from the archive, as an
additional option in section (C).

3. Do you have your code open-sourced? Is it well-organized and documented?
Maybe some could help you with these types of features in their spare time.

--
Business Web Solutions
ActiveLink, LLC
www.active-link.com/intranet/

[Manuel Lemos]

Hello,

On 10/31/2003 06:48 AM, Zurab Davitiani wrote:

1. Class dependency is not hard. However, I have not envisioned how the
user interface would work to let authors pick dependency classes from
more than 1130 approved classes that exist now.

2. Bulk uploading is more complicated. Regardless how the authors upload
their classes, they need still need to enter descriptions and specify
the role for each file. I am not sure how this could be done and in the
end the authors do not complain that it is still bureaucratic.

Package bulk updating would be another issue because the site would have
to know which files are being updated and which are new.

I though of having support to synchronize with a remove CVS server
indicated by the author when the update is meant to be performed. but
not every author has their projects in a public CVS server.
Any ideas to solve these problems in the most convinient way are welcomed.

Just ask. I do have those :)

Now, I don't know the internals of your system, but having used it here are
what I think are some options on how to do those:

1. You are right - dependency may look simple on its face, but details may
end up being slightly more complicated. As far as picking dependency
packages, you could allow class authors to (1) search for packages by name
or description, (2) browse to it, or (3) type its ID; next, you find these
packages, let user select and confirm which packages they want to add as
dependencies, then add them.

That would mean replicating the site navigation facilities.

I have a better idea. I will implement a sort of clipboard facility.
That would allow users to copy references to packages, groups, authors,
etc. so they could be user later for different purposes.

This way, if you want to add a dependency between two packages, first
you locate the dependency package and then copy it to the clipboard. In
the package page, you will have a link to a page to add a new package
dependency. In that page you can confirm that you want to add a
dependency to the current package on the clipboard. If there is no
package on the clipboard, you are told what to do to specify a package
to add a dependency.

What do you think?
One thing to consider in this, at some point, is versioning - you may want
to force developers to enter some kind of version number or an identifier
so that when a package is updated (say B and C are dependent on A),
- package A author selects whether the update he is making may break
compatibility (if A is listed as a dependency);
- if so, then dependent package authors (B and C) are notified of the change
and have an opportunity to check/fix compatibility;
- meanwhile, users on the website are notified whether compatibility has
been confirmed by developer(s).
I do not know if that is viable. First it is unrealistic to think that I
can force authors to do anything.

Currently the site requires that authors specify the role of each file
in a package. For old packages, I asked authors to do that themselves.
Most authors did not do it.

Some did it when they noticed that if they do not classify documentation
and example files as such, the users could not rate their packages in
those aspects.

They did it because they were loosing user rating ranking positions and
eventually the prizes that are offered every month by PHP-Editors site
to the best user rated packages in PHP Classes, but not all authors reacted.
Now, to your suggestions, it is viable to send the notifications and it
is a very good idea. What does not seem to be viable is to make sure the
developer really verified the compatibility when he was asked and confirmed.

So, the basic problem is what to do when these situations happen:
authors not versioning packages and authors pretended that confirmed
compatibility.

On a user-side of things, when listing dependencies of a package, you may
want to have a link to "download all" to get all of them.
Yes, that would be a logical step.

There is however the problem of dependencies that are not so mandatory.

For instance, I have an email validation class that can work with the
DNS resolver class provided by other author in case GetMXRR is not
functional (for instance under Windows). It would be misleading to tell
users that do not really need that package to download it too because it
is a dependency. Maybe I should require authors to describe the scope of
the dependency.

2. As far as bulk uploading, when an archive is uploaded (zip, tar.gz,
etc.), check every file by path and filename against existing package
entries, then provide 4 sections on the next page as follows:

(A) for the filenames that are already present in the package, simply let
the user know that they will be overwritten;

(B) for the filenames that are new, display a table (or a div/span
structure) for user to enter each new file's description and pick a role;

(C) for the filenames that were present in the original structure but are
missing from the uploaded archive, present user with the choice to keep
each one as is, or remove it from the package.

(D) for files that generated errors, e.g. binary files, etc. let user know
what error(s) occurred, correct errors and retry, or upload those files
individually afterwards.

Complete package update only after user confirms and approves what is
described in A, B, C, and D.
It sounds like a good plan but in practice there other problems to
solve, like where will be the data about the new files stored while the
author does not decide what to do with the files? Basically I would have
to replicate the files table which does not please me much.

It boils down all to have a upload staging system that I wanted to do
for another reason, which is to approve all the changes that the authors
do tio their packages. So, I think the solution may have to be better
thought to address both problems.
The only thing that you'll be missing is a changelog for each individual
file like you have it now. I don't know for other developers, but if you
ask me, that is not necessary - you may want to ask for an overall
changelog instead.
It may not be necessary for you but it is for users of the packages.
When you add a new file you need to tell what it is. If you change a
file you can change descriptions as well tell what was changed, so the
site can provide useful information in the updated package e-mail message.

I don't think this will be "bureaucratic", since most updates should be
covered in (A), (B) would not happen a lot unless there were major changes
or a complete overhaul, (A) and (D) are simply notices, (C) should be a
pretty trivial boolean choice.
I am not so sure about that. Anyway, it will be done as necessary. The
problem is that is if the authors end up not using it because it is too
bureaucratic. That would be a major waste of development effort for me.

One thing to consider is that this may not cover situations when files are
moved around in different directories. e.g., developer moved myclass.php
file to /classes/myclass.php or renamed it. To account for these cases, you
may have to either:

(a) explain on the "upload archive" page that if that is the case, they
first need to make sure the path and filenames in the package match those
in the new archive (if not, modify the package first); otherwise, their
history, including download count may get lost;
OR
(b) in a more complicated case, allow users to provide an option to "merge"
(i.e. update) one file with a different file from the archive, as an
additional option in section (C).
Moving directories or renaming is the samething because the path is just
one field in the database. So, it would always be the case to let the
authors tell that a given file is meant to overwrite another existing file.

3. Do you have your code open-sourced? Is it well-organized and documented?
Maybe some could help you with these types of features in their spare time.

Thank you but this is not quite viable. The whole site is based on
classes but documenting it up to a level that it would make it useful
for others to understand and change would take me a very long time. So,
I would rather not commit to doing it when it is really not necessary.

Also, I do not want to open the source to not have to deal with
nightmare of people trying to fork the project and develop competitor
repositories.

I believe in opening the source code of projects when the advantages
outweight the disadvantages for the authors, which does not seem to be
the case.

Although this does not apply to everybody, the so called Open Source
community can be ungrateful and act against the authors that open the
code of their projects. When you open the source code of projects,
contributors often act as if they became owners of the project. I do not
agree with that.

A clear example of that was what happened to Sourceforge. I am sure that
if VA would not have opened the source code of the site itself if they
knew then what they know today, namely the ungrateful boycott and other
harmful actions against VA from members of the so called Free Software
Foundation.

Nothing against you, but I hope you understand why I would rather not
open the source code of the site.
--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

[Zurab Davitiani]

Manuel Lemos wrote on Saturday 01 November 2003 05:37:

That would mean replicating the site navigation facilities.

I have a better idea. I will implement a sort of clipboard facility.
That would allow users to copy references to packages, groups, authors,
etc. so they could be user later for different purposes.

This way, if you want to add a dependency between two packages, first
you locate the dependency package and then copy it to the clipboard. In
the package page, you will have a link to a page to add a new package
dependency. In that page you can confirm that you want to add a
dependency to the current package on the clipboard. If there is no
package on the clipboard, you are told what to do to specify a package
to add a dependency.

What do you think?
That should be fine too. If you ask me, I'd be OK with simply typing an ID
as well. If a developer extending a class/package, they could easily look
up its ID without having to go through a slightly more involved clipboard.
Now, to your suggestions, it is viable to send the notifications and it
is a very good idea. What does not seem to be viable is to make sure the
developer really verified the compatibility when he was asked and
confirmed.

So, the basic problem is what to do when these situations happen:
authors not versioning packages and authors pretended that confirmed
compatibility.
Well, if you think they are not going to do versioning, then it's not worth
going through the hassle, I guess. Just send out the notices/requests to
confirm compatibility. But, I would think, as a side note, it would be
great to have an optional version field for a package anyway, so (for
authors/packages that would use them) users know if they are up-to-date or
not.

As far as compatibility itself, you cannot do compability testing for them
obviously, so it's totally 100% up to the authors. But when it comes down
to it the question is - is your inability to confirm compatibility between
dependent packages a good enough reason not to offer dependency linking
between packages altogether?

My answer would be "no" - let the developers sort out the compatibility
issues - you do your part of notifying both developers (via e-mail) and
users (on the website) when they may occur, and let the developers, users
and user ratings handle the rest.
For instance, I have an email validation class that can work with the
DNS resolver class provided by other author in case GetMXRR is not
functional (for instance under Windows). It would be misleading to tell
users that do not really need that package to download it too because it
is a dependency. Maybe I should require authors to describe the scope of
the dependency.
Yeah, that's a good idea. A simple comment field should suffice. Otherwise,
you would have to get involved in multiple dependency trees involving
combinations of factors such as:
- PHP major/minor versions
- platforms and their major/minor versions
- compiled in or loadable modules and their major/minor versions
- etc.
It sounds like a good plan but in practice there other problems to
solve, like where will be the data about the new files stored while the
author does not decide what to do with the files? Basically I would have
to replicate the files table which does not please me much.

It boils down all to have a upload staging system that I wanted to do
for another reason, which is to approve all the changes that the authors
do tio their packages. So, I think the solution may have to be better
thought to address both problems.
Well, if you plan to approve package changes manually, then that kind of
staging system is a good way to go.
It may not be necessary for you but it is for users of the packages.
When you add a new file you need to tell what it is. If you change a
file you can change descriptions as well tell what was changed, so the
site can provide useful information in the updated package e-mail message.
I think the way I envisioned it (may not have been clear) is that in case of
new files, authors would still be required to put in their file
type/purpose and descriptions. As far as when the whole package is being
updated (as a whole) it may be an overkill to ask authors to provide
changelog for each file individually, but rather, ask for an overall
changelog instead. This way, users are advised of changes to the package,
rather than getting e-mails for each individual file update.

Again, I'm not suggesting any changes to the current system, but rather an
option on how to handle bulk package updates when uploading an archive.

I don't think this will be "bureaucratic", since most updates should be
covered in (A), (B) would not happen a lot unless there were major
changes or a complete overhaul, (A) and (D) are simply notices, (C)
should be a pretty trivial boolean choice.

I am not so sure about that. Anyway, it will be done as necessary. The
problem is that is if the authors end up not using it because it is too
bureaucratic. That would be a major waste of development effort for me.

I'm not sure what you mean by bureaucratic here. If I have to update 15
files in my package, one option is to go through each individual file and
re-upload it - about 30-45 pages to load/click through (depending on how
you do it); OR upload a single archive, and confirm changes (listed per
file) on the next page once. It seems to me it's a no-brainer.
Thank you but this is not quite viable. The whole site is based on
classes but documenting it up to a level that it would make it useful
for others to understand and change would take me a very long time. So,
I would rather not commit to doing it when it is really not necessary.

Also, I do not want to open the source to not have to deal with
nightmare of people trying to fork the project and develop competitor
repositories.

I believe in opening the source code of projects when the advantages
outweight the disadvantages for the authors, which does not seem to be
the case.

Although this does not apply to everybody, the so called Open Source
community can be ungrateful and act against the authors that open the
code of their projects. When you open the source code of projects,
contributors often act as if they became owners of the project. I do not
agree with that.

A clear example of that was what happened to Sourceforge. I am sure that
if VA would not have opened the source code of the site itself if they
knew then what they know today, namely the ungrateful boycott and other
harmful actions against VA from members of the so called Free Software
Foundation.

Nothing against you, but I hope you understand why I would rather not
open the source code of the site.

Well, it's up to you, it was just a question. It's totally up to you for
whatever reasons you choose to keep it closed - it's none of my business.
Period.

I don't want to start a Sourceforge vs. Savannah flamewar but that's part of
open-sourcing - allowing others to extend your (generic "your") work the
way they see fit as long as they comply with the license. If I didn't agree
with how both FSF and VA update their product and provide the said service,
I could take Savannah or Sourceforge system and start providing my own
modified service. Who's to stop me?

From a strictly personal point of view, I wouldn't take a Sourceforge
example as a means of conclusion that open sourcing a project like that is
automatically "bad" since someone will likely take its controls over and
start providing a competitive service. I mean, that's [a predictable] part
of it, but not all of it. Take slashcode as an example, used by 100s (if
not more) sites, livejournal, even Sourceforge, in this respect, remains
extremely popular.

I guess what I am trying to say is that going one way or another is not a
simple straightforward line - it's a combination of a lot of different
factors; and, even in Sourceforge example, I cannot deduce that
sourceforge.net would have been a more popular service if it was NOT
open-sourced itself. I just can't draw that line.

Anyway, I thought I'd share my opinions.

--
Business Web Solutions
ActiveLink, LLC
www.active-link.com/intranet/

[Manuel Lemos]

Hello,

On 11/03/2003 09:02 AM, Zurab Davitiani wrote:

That would mean replicating the site navigation facilities.

I have a better idea. I will implement a sort of clipboard facility.
That would allow users to copy references to packages, groups, authors,
etc. so they could be user later for different purposes.

This way, if you want to add a dependency between two packages, first
you locate the dependency package and then copy it to the clipboard. In
the package page, you will have a link to a page to add a new package
dependency. In that page you can confirm that you want to add a
dependency to the current package on the clipboard. If there is no
package on the clipboard, you are told what to do to specify a package
to add a dependency.

What do you think?

That should be fine too. If you ask me, I'd be OK with simply typing an ID
as well. If a developer extending a class/package, they could easily look
up its ID without having to go through a slightly more involved clipboard.

Yes, I just noticed that Freshmeat also supports project dependencies
with an interface that works that way. So, that should be fine for a
first approach.

Now, to your suggestions, it is viable to send the notifications and it
is a very good idea. What does not seem to be viable is to make sure the
developer really verified the compatibility when he was asked and
confirmed.

So, the basic problem is what to do when these situations happen:
authors not versioning packages and authors pretended that confirmed
compatibility.

Well, if you think they are not going to do versioning, then it's not worth
going through the hassle, I guess. Just send out the notices/requests to
confirm compatibility. But, I would think, as a side note, it would be
great to have an optional version field for a package anyway, so (for
authors/packages that would use them) users know if they are up-to-date or
not.

Yes, that is what I think is what is viable.

What about the version format? Shall I let it make it arbitrary or
enforce a format like M.m.a (Major.minor.alpha like 2.7.1)?

As far as compatibility itself, you cannot do compability testing for them
obviously, so it's totally 100% up to the authors. But when it comes down
to it the question is - is your inability to confirm compatibility between
dependent packages a good enough reason not to offer dependency linking
between packages altogether?
No.
My answer would be "no" - let the developers sort out the compatibility
issues - you do your part of notifying both developers (via e-mail) and
users (on the website) when they may occur, and let the developers, users
and user ratings handle the rest.
Yes.

For instance, I have an email validation class that can work with the
DNS resolver class provided by other author in case GetMXRR is not
functional (for instance under Windows). It would be misleading to tell
users that do not really need that package to download it too because it
is a dependency. Maybe I should require authors to describe the scope of
the dependency.

Yeah, that's a good idea. A simple comment field should suffice. Otherwise,
you would have to get involved in multiple dependency trees involving
combinations of factors such as:
- PHP major/minor versions
- platforms and their major/minor versions
- compiled in or loadable modules and their major/minor versions
- etc.

Yes, I think I will have something like:

- Required: dependency package is necessary to make dependent class work.

- Base: Required package has actually a base class

- Required alternative: dependency package provides a functionality that
otherwise needs to be provided by another required alternative

- Conditional: Dependency package provides functionality that is
necessary to make the dependent package work in some conditions.

- Optional: Dependency package provides a functionality that is not
absolutely necessary in any conditions.

Am I forgetting any other case?

It sounds like a good plan but in practice there other problems to
solve, like where will be the data about the new files stored while the
author does not decide what to do with the files? Basically I would have
to replicate the files table which does not please me much.

It boils down all to have a upload staging system that I wanted to do
for another reason, which is to approve all the changes that the authors
do tio their packages. So, I think the solution may have to be better
thought to address both problems.

Well, if you plan to approve package changes manually, then that kind of
staging system is a good way to go.

Actually a major headache to implement properly. Anyway, I think I have
to do it soon or later because some authors tend add inappropriate
entries. So, I would rather approve each change before it is too late.

It may not be necessary for you but it is for users of the packages.
When you add a new file you need to tell what it is. If you change a
file you can change descriptions as well tell what was changed, so the
site can provide useful information in the updated package e-mail message.

I think the way I envisioned it (may not have been clear) is that in case of
new files, authors would still be required to put in their file
type/purpose and descriptions. As far as when the whole package is being
updated (as a whole) it may be an overkill to ask authors to provide
changelog for each file individually, but rather, ask for an overall
changelog instead. This way, users are advised of changes to the package,
rather than getting e-mails for each individual file update.

Again, I'm not suggesting any changes to the current system, but rather an
option on how to handle bulk package updates when uploading an archive.

Either way the site still have to support individual and bulk updates.
So, I will have something that sends out digests of file changes maybe
hourly to avoid sending many messages to the users, which some have been
complaining with reason.

The problem of making it easy for authors to enter bulk changes in a
single description is that some will make them vague. This is also a
reason to have an approval stage for new or changed files.

I don't think this will be "bureaucratic", since most updates should be
covered in (A), (B) would not happen a lot unless there were major
changes or a complete overhaul, (A) and (D) are simply notices, (C)
should be a pretty trivial boolean choice.

I am not so sure about that. Anyway, it will be done as necessary. The
problem is that is if the authors end up not using it because it is too
bureaucratic. That would be a major waste of development effort for me.

I'm not sure what you mean by bureaucratic here. If I have to update 15
files in my package, one option is to go through each individual file and
re-upload it - about 30-45 pages to load/click through (depending on how
you do it); OR upload a single archive, and confirm changes (listed per
file) on the next page once. It seems to me it's a no-brainer.

Yes, currently is too bureaucratic for large packages. What I mean is
that if authors add a bunch of new files it will still have to be
bureacratic because they need to enter descriptions and roles file by file.

Nothing against you, but I hope you understand why I would rather not
open the source code of the site.

Well, it's up to you, it was just a question. It's totally up to you for
whatever reasons you choose to keep it closed - it's none of my business.
Period.

I don't want to start a Sourceforge vs. Savannah flamewar but that's part of
open-sourcing - allowing others to extend your (generic "your") work the
way they see fit as long as they comply with the license. If I didn't agree
with how both FSF and VA update their product and provide the said service,
I could take Savannah or Sourceforge system and start providing my own
modified service. Who's to stop me?

Personally, the problem that I saw with Sourceforge was not others
forked the project but rather the attitude of some individuals of FSF
that taken hostile measures causing eventual financial harm to VA.

One thing is expressing public disagreement on the decision of VA to
close the source of futher development and starting forks. Another thing
is making bad PR to try to burn VA business in revenge.

I think that was silly ungrateful attitude from some FSF individuals
because Sourceforge has done a lot for the credibility and viability of
many Open Source projects.
From a strictly personal point of view, I wouldn't take a Sourceforge
example as a means of conclusion that open sourcing a project like that is
automatically "bad" since someone will likely take its controls over and
start providing a competitive service. I mean, that's [a predictable] part
of it, but not all of it. Take slashcode as an example, used by 100s (if
not more) sites, livejournal, even Sourceforge, in this respect, remains
extremely popular.
Sure, but VA (OSDN) and its financial muscle is too large to compare
with me. VA can leverage the resources to keep Sourceforge alive. Maybe
now they are paying themselves but it took a lot of money to grow that
large. When they are that large and popular, they do not need to fear
opening the source of the sites, unless they want to sell copies , which
was why they decided to close the source of Open Source later.

I guess what I am trying to say is that going one way or another is not a
simple straightforward line - it's a combination of a lot of different
factors; and, even in Sourceforge example, I cannot deduce that
sourceforge.net would have been a more popular service if it was NOT
open-sourced itself. I just can't draw that line.

No, I think your are forgetting how it happens. Sourceforge was already
very popular when they opened the source of the site. They really did
not need to do that. I am sure they regret that did it. I do not want to
regret too.

--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/

[Zurab Davitiani]

Manuel Lemos wrote on Sunday 09 November 2003 21:35:

That should be fine too. If you ask me, I'd be OK with simply typing an
ID as well. If a developer extending a class/package, they could easily
look up its ID without having to go through a slightly more involved
clipboard.
Yes, I just noticed that Freshmeat also supports project dependencies
with an interface that works that way. So, that should be fine for a
first approach.

Good.

Well, if you think they are not going to do versioning, then it's not
worth going through the hassle, I guess. Just send out the
notices/requests to confirm compatibility. But, I would think, as a side
note, it would be great to have an optional version field for a package
anyway, so (for authors/packages that would use them) users know if they
are up-to-date or not.

Yes, that is what I think is what is viable.

What about the version format? Shall I let it make it arbitrary or
enforce a format like M.m.a (Major.minor.alpha like 2.7.1)?

I don't see this as a big deal either way; but I don't think enforcing any
particular format is going to add anything meaningful. It's obvious but
just make sure you keep the date/time of each release.

As far as compatibility itself, you cannot do compability testing for
them obviously, so it's totally 100% up to the authors. But when it comes
down to it the question is - is your inability to confirm compatibility
between dependent packages a good enough reason not to offer dependency
linking between packages altogether?

No.

Great.

My answer would be "no" - let the developers sort out the compatibility
issues - you do your part of notifying both developers (via e-mail) and
users (on the website) when they may occur, and let the developers, users
and user ratings handle the rest.

Yes.

Good.

Yeah, that's a good idea. A simple comment field should suffice.
Otherwise, you would have to get involved in multiple dependency trees
involving combinations of factors such as:
- PHP major/minor versions
- platforms and their major/minor versions
- compiled in or loadable modules and their major/minor versions
- etc.

Yes, I think I will have something like:

- Required: dependency package is necessary to make dependent class work.

- Base: Required package has actually a base class

- Required alternative: dependency package provides a functionality that
otherwise needs to be provided by another required alternative

- Conditional: Dependency package provides functionality that is
necessary to make the dependent package work in some conditions.

- Optional: Dependency package provides a functionality that is not
absolutely necessary in any conditions.

Am I forgetting any other case?

In my opinion, the simpler the better. I would simply suggest a single
option - worded either "Required" or "Dependencies" or something similar;
If specified, the author would have to enter a comment as to the extent of
each dependency.

Otherwise, you run the risk of confusing some developers with all those
options and, thereby, ending up with incorrect data. For example, what if
some dependencies could belong to 2 different groups on different platforms
or major PHP versions? Covering all possible scenarios increases the risk
of developer as well as user confusion. UNLESS, you implement some type of
dependency tree system with multiple possible package branches. For
example, imagine package branches for PHP4, PHP5, each with different
dependency trees.

Well, if you plan to approve package changes manually, then that kind of
staging system is a good way to go.

Actually a major headache to implement properly. Anyway, I think I have
to do it soon or later because some authors tend add inappropriate
entries. So, I would rather approve each change before it is too late.

OK.
Either way the site still have to support individual and bulk updates.
So, I will have something that sends out digests of file changes maybe
hourly to avoid sending many messages to the users, which some have been
complaining with reason.

The problem of making it easy for authors to enter bulk changes in a
single description is that some will make them vague. This is also a
reason to have an approval stage for new or changed files.
Well, you know what my opinion is - it's up to you how you implement it. I
believe users would be well served by freshmeat-type update log - concise
and to the point. I don't think it's necessary to duplicate a CVS or a
similar individual file changelogs since the site is not a development
environment but rather a class/package repository. Well, unless you want to
take it in that direction.
Yes, currently is too bureaucratic for large packages. What I mean is
that if authors add a bunch of new files it will still have to be
bureacratic because they need to enter descriptions and roles file by
file.
See above.
Personally, the problem that I saw with Sourceforge was not others
forked the project but rather the attitude of some individuals of FSF
that taken hostile measures causing eventual financial harm to VA.

One thing is expressing public disagreement on the decision of VA to
close the source of futher development and starting forks. Another thing
is making bad PR to try to burn VA business in revenge.

I think that was silly ungrateful attitude from some FSF individuals
because Sourceforge has done a lot for the credibility and viability of
many Open Source projects.

Well, this can happen to anyone, whether your project/service is open source
or not. There will always be differing opinions and [groups of] people who
act one way that others disaprove or do not appreciate. I guess the more
popular the project/service/website the more the likelihood of such
situations.

From a strictly personal point of view, I wouldn't take a Sourceforge
example as a means of conclusion that open sourcing a project like that
is automatically "bad" since someone will likely take its controls over
and start providing a competitive service. I mean, that's [a predictable]
part of it, but not all of it. Take slashcode as an example, used by 100s
(if not more) sites, livejournal, even Sourceforge, in this respect,
remains extremely popular.

Sure, but VA (OSDN) and its financial muscle is too large to compare
with me. VA can leverage the resources to keep Sourceforge alive. Maybe
now they are paying themselves but it took a lot of money to grow that
large. When they are that large and popular, they do not need to fear
opening the source of the sites, unless they want to sell copies , which
was why they decided to close the source of Open Source later.

I agree to most of your opinion, but also consider one example I stated -
LiveJournal. They actually make their users pay a fee to use their service
(in certain circumstances) while offering all their software under GPL.
Now, there are other sites that run that software, but none as popular as
LiveJournal, and none (I am guessing) with as many members and
participants. I'm not implying that all circumstances are equal, or that
you should be charging users, but the model is something worth looking at;
and maybe even having a brainstorming session over.

I guess what I am trying to say is that going one way or another is not a
simple straightforward line - it's a combination of a lot of different
factors; and, even in Sourceforge example, I cannot deduce that
sourceforge.net would have been a more popular service if it was NOT
open-sourced itself. I just can't draw that line.

No, I think your are forgetting how it happens. Sourceforge was already
very popular when they opened the source of the site. They really did
not need to do that. I am sure they regret that did it. I do not want to
regret too.

I'm not sure they regret it though. After all, wide media coverage and all
the fuss it generated did get them more attention and even more popularity.
Your situation is obviously different from VA's, so it's your judgement.
--
Business Web Solutions
ActiveLink, LLC
www.active-link.com/intranet/

[Manuel Lemos]

Hello,

On 11/11/2003 09:27 AM, Zurab Davitiani wrote:

Well, if you think they are not going to do versioning, then it's not
worth going through the hassle, I guess. Just send out the
notices/requests to confirm compatibility. But, I would think, as a side
note, it would be great to have an optional version field for a package
anyway, so (for authors/packages that would use them) users know if they
are up-to-date or not.
Yes, that is what I think is what is viable.

What about the version format? Shall I let it make it arbitrary or
enforce a format like M.m.a (Major.minor.alpha like 2.7.1)?

I don't see this as a big deal either way; but I don't think enforcing any
particular format is going to add anything meaningful. It's obvious but

If you have versions in a specific format, the site can always validate
the new versions to make sure that next version number is more than the
previous.

just make sure you keep the date/time of each release.

The problem is which date should be taken as release? The date/time of
the last updated file or the date and time of when the author updated
the version number?

Yeah, that's a good idea. A simple comment field should suffice.
Otherwise, you would have to get involved in multiple dependency trees
involving combinations of factors such as:
- PHP major/minor versions
- platforms and their major/minor versions
- compiled in or loadable modules and their major/minor versions
- etc.

Yes, I think I will have something like:

- Required: dependency package is necessary to make dependent class work.

- Base: Required package has actually a base class

- Required alternative: dependency package provides a functionality that
otherwise needs to be provided by another required alternative

- Conditional: Dependency package provides functionality that is
necessary to make the dependent package work in some conditions.

- Optional: Dependency package provides a functionality that is not
absolutely necessary in any conditions.

Am I forgetting any other case?

In my opinion, the simpler the better. I would simply suggest a single
option - worded either "Required" or "Dependencies" or something similar;
If specified, the author would have to enter a comment as to the extent of
each dependency.

Otherwise, you run the risk of confusing some developers with all those
options and, thereby, ending up with incorrect data. For example, what if
some dependencies could belong to 2 different groups on different platforms
or major PHP versions? Covering all possible scenarios increases the risk
of developer as well as user confusion. UNLESS, you implement some type of
dependency tree system with multiple possible package branches. For
example, imagine package branches for PHP4, PHP5, each with different
dependency trees.

Yes, although some options are just special cases of others. A base
class is a special case of a required dependency. I thought that could
help the users understand more clearly why the dependency is really
required.

Either way the site still have to support individual and bulk updates.
So, I will have something that sends out digests of file changes maybe
hourly to avoid sending many messages to the users, which some have been
complaining with reason.

The problem of making it easy for authors to enter bulk changes in a
single description is that some will make them vague. This is also a
reason to have an approval stage for new or changed files.

Well, you know what my opinion is - it's up to you how you implement it. I
believe users would be well served by freshmeat-type update log - concise
and to the point. I don't think it's necessary to duplicate a CVS or a
similar individual file changelogs since the site is not a development
environment but rather a class/package repository. Well, unless you want to
take it in that direction.

Yes, but Freshmeat is different. They do not keep track of individual
files of projects. If you have a package with multiple classes and not
all classes are interesting for all users, if you changed just a few
classes, the users that are interested just on those will want to know
what you have changed. So, I think that the list of changes that pertain
just to a certain files is more helpful.

Personally, the problem that I saw with Sourceforge was not others
forked the project but rather the attitude of some individuals of FSF
that taken hostile measures causing eventual financial harm to VA.

One thing is expressing public disagreement on the decision of VA to
close the source of futher development and starting forks. Another thing
is making bad PR to try to burn VA business in revenge.

I think that was silly ungrateful attitude from some FSF individuals
because Sourceforge has done a lot for the credibility and viability of
many Open Source projects.

Well, this can happen to anyone, whether your project/service is open source
or not. There will always be differing opinions and [groups of] people who
act one way that others disaprove or do not appreciate. I guess the more
popular the project/service/website the more the likelihood of such
situations.

Yes, but my point is that VA never had the need to really open their
source code. They always had paid employees to cover for their
development needs. They just followed the trend of opening the source
code of their site but certainly they wish they have not done that after
they realized what they had to put with.

For me this is well enough to warrant. I do not want nor need to put up
with the same as VA, so I will not Open the Source code of the site.

From a strictly personal point of view, I wouldn't take a Sourceforge
example as a means of conclusion that open sourcing a project like that
is automatically "bad" since someone will likely take its controls over
and start providing a competitive service. I mean, that's [a predictable]
part of it, but not all of it. Take slashcode as an example, used by 100s
(if not more) sites, livejournal, even Sourceforge, in this respect,
remains extremely popular.

Sure, but VA (OSDN) and its financial muscle is too large to compare
with me. VA can leverage the resources to keep Sourceforge alive. Maybe
now they are paying themselves but it took a lot of money to grow that
large. When they are that large and popular, they do not need to fear
opening the source of the sites, unless they want to sell copies , which
was why they decided to close the source of Open Source later.

I agree to most of your opinion, but also consider one example I stated -
LiveJournal. They actually make their users pay a fee to use their service
(in certain circumstances) while offering all their software under GPL.
Now, there are other sites that run that software, but none as popular as
LiveJournal, and none (I am guessing) with as many members and
participants. I'm not implying that all circumstances are equal, or that
you should be charging users, but the model is something worth looking at;
and maybe even having a brainstorming session over.

Yes, but what would I have to gain with opening the source code of the
site? The way I see it, only things that I do not absolutely need, not
to mention the disadvantages of doing it.

Besides that, I have more reasons for not doing it that I have not
mentioned.

I guess what I am trying to say is that going one way or another is not a
simple straightforward line - it's a combination of a lot of different
factors; and, even in Sourceforge example, I cannot deduce that
sourceforge.net would have been a more popular service if it was NOT
open-sourced itself. I just can't draw that line.

No, I think your are forgetting how it happens. Sourceforge was already
very popular when they opened the source of the site. They really did
not need to do that. I am sure they regret that did it. I do not want to
regret too.

I'm not sure they regret it though. After all, wide media coverage and all
the fuss it generated did get them more attention and even more popularity.
Your situation is obviously different from VA's, so it's your judgement.

Maybe there were some positive aspects of advertising as you mentioned
but that could only be positive because they ended up wanting to sell
the site code as a product. That is not in my plans though.

OTOH, if they did not ever opened the source, they could have more
hosted projects genering advertising revenue from the banners they put
in their pages because there would not be alternative sites based on
their code.

I am sure that today they are making much more money from the
advertising there, than from the sales of licenses of their site
product. They just did not know then that the advertising marker would
be as healthy as it is today, but at least I know that and it is one
more reason to not open the source code.

--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP
http://www.phpclasses.org/