Do not be fooled by Richard Verbeek or other SchoolsUnited
salesmen or developers. Our Forum database was stolen by one of
the developers who also refused to hand us the passwords of
our Sourceforge site when he decided to leave the team.
SchoolsUnited or SyndeoCMS are NOT the new names of Site@School.
SyndeoCMS is an insecure and unmaintainable clone of
our CMS Site@School. Better not do business with SyndeoCMS,
SchoolsUnited, siteatschool.COM and siteatschool.INFO and the
persons behind those sites. Read more below.
dd. December 2011: SyndeoCMS still insecure according to vulnerability
dd. January 2008: under construction ...apologies for typos.
In the summer of 2006 numerous Site@School sites were defaced.
Security reports revealead serious problems in the S@S code.
The code is insecure and unmanageable. Basic security problems
were solved. The majority of the team deciced in favour of a
complete rewrite of the code. This decision made Fred Stuurman
leave the team, clone
(fork) Site@School in SyndeoCMS, hyjack the Site@School Sourceforge
site, stole the data and user info of the Site@School forum and
Fred formed a partnership with Richard Verbeek who owns
Scorpio Inc. Verbeek created SchoolsUnited, violates trademark
rights, commits breach of contract and refuses contact.
Last, but not least, we are fed up with all kinds of people that
use Site@School for their own benefit and refuse to contribute to
the project. One of them is Steve Pallet of siteatschool.com. Violates
copyrights and GPL. Others remain unknown so far. When discovered,
they can count on 'name and shame' on this site.
2. Foreplay: Why Fred left the team
3. Security reports
3.1 Part one
3.2 Part two
3.3 Part three
4. New Developments
It's the 21th of May 2007. A couple of days ago I said to myself:
"Ok, this is it. My patience with these scoundrels has ended".
I had enough trouble with Richard Verbeek, Fred Stuurman,
siteatschool.nl, syndeocms.nl and lately SchoolsUnited.eu.
I am fed up with their violations of appointments and agreements,
violations of my rights as an author, violations of my rights
as trademark owner and their violations
of the Free Documentation License under which I publish my work.
I am fed up with their half truth which I literally quote from their site: "S@S version 2.4.10 is built save (according to the S@S-team)".
And, recently (june 2007) I found out Richard is a defaulter, not paying his debts to the Site@School project.
After some thought, two options remained: going to a lawyer (expensive),
or opening the box (unpleasant). The latter is the cheapest and may
result in some recommendations on how to handle these violations in
general.. The Internet may
have unexpected possibilities in correcting bad
Here we go:
In the 2. Foreplay: Site@School and
Syndeo CMS page you find a detailed
description of what led to the forking (cloning) of Site@School in
SyndeoCMS. You also will find English summaries of the security
reports that clearly indicate what is wrong with the fork
In this section we try to give as many facts as possible. Some
material is in Dutch; we try to summarize in English.
In the section on security reports you find detailed information and code examples that
underpin our decision to have the complete code of Site@School rewritten because it will
become unmaintainable and insecure. The security reports are in Dutch, but you find summaries
in the Foreplay page.
Here some misunderstanding may arise about Freds qualities as developer and coder.
Let me be clear: Fred is excellent in prototyping. Ask him a feature and the next day you will
have the code. When you then say: "Well, that's not what I meant, can we have X instead of Y
and Z to it?" Fred has it ready the next day, etcetera ad infinitum. In that way he is unbeatable.
It has given us a great CMS.
Fred is a great prototyper and we miss him a lot.
The 'but' is: for a workhorse program like Site@School it's not enough. Let's observe
the following quote from Eric Raymond
"The Art of Unix programming", in http://www.faqs.org/docs/artu/ch01s06.html#id2878538 , in the section "Rule of Optimization: Prototype before polishing. Get it working before you optimize it."
" Prototype, then polish. Get it working before you optimize it. Or: Make it work first,
then make it work fast. .Extreme programming' guru Kent Beck, operating in a different
culture, has usefully amplified this to: .Make it run, then make it right, then make it fast.."
In Site@School Becks quote is only met in the first part. It runs. And tha'ts a pity.
And that's why we had to decide to rewrite. Fred remains an excellent prototyper.
And it's a good idea to read the book completely, or when you know nothing about code, read
the first chapter(s).
3.1 The first report
3.2 The second report
3.3 The conclusion
New developments can be found on the New Developments page.
In the New Developments page
we will give updates, i.e. what happened when the agreement
between the Site@School Developent Team and Richard Verbeek ended.
As ever, we will be as factual as possible and give as much details
in the form of emails, PDF's, reports, screenshots, etcetera.
Author: Dirk Schouten <schoutdi at knoware dot nl>
Last updated: 2007-0-22