GPL Blog Engines

Posted 12 Oct 2002 at 15:09 UTC by garym Share This

This is frustrating: I've spent the past several days digging, and I can't find an opensource replacement for moveableType. Why not MT? It's only $150 for the commercial license and it is 'opensource'! Well, it all comes down to trust: I can't use MT because I cannot trust software I can never own, and I can't place my company at the mercy of another. Been there, done that, got royally burned several times.

What this world needs is a good 10-cent cigar and a good GPL multi-user blog engine

We've had a website since 1993, and all our content management systems have eventually become modified from the original; some of our patches went into the original (we submit them all), but some do not. The point is, everyone is happy because we all had the freedom to do what we need to do. With restricted systems like MT, if they change the rules (the way MetaDot did when it dropped the GPL and went strict proprietary) we're screwed, and I don't want to go through that again. With MT, all you get is free-beer, and only if you're non-commercial and non-government; given their definitions, my guess is maybe half the MT sites out there are operating illegally. It's a great system, well thought out and intelligently architected, but if the Trott's have a change of heart, we're stranded.

MT does form an excellent spec of what a good blog system requires. What we need is

  • multiple independent topic areas which can contain blogs, stories and static pages, and multiple categories within each blog area; this lets out greymatter.
  • image/file uploading by users to seed new blog entries and create thumbnails.
  • blog-owner controlled tags-based template and stylesheet layout configurable on a per-blog; this lets out drupal since it mixes PHP code with markup to programmatically generate a page instead of generating content and letting users determine the layout and selection.
  • user-definable macros to short-hand common markup, for example, to build an amazon book hotlink with a single tag.
  • modular construction with a rich set of modules for google/amazon and other xmlrpc hooks, trackback and ping support to multiple targets.
  • page caching
  • remote publishing via any of the standard blogger-like RESTful XMLRPC, and includes titles and categories.
  • perl, but not mod_perl, or PHP based.
  • installs in a user-account on a webhost (doesn't require messing with the apache config files or compiling new binaries. This lets out the mod_perl and Java-based engines.

I've been through most of the offerings on the blog comparison page and I've come up short on all the free software offerings. Of all those I've evaluated, Drupal comes the closest (and adds several other interesting features) but because it's based on programmatic page generation instead of tags-based and user-controlled templates, it won't allow different layout for different blogs, and even the smallest layout changes require a PHP programmer; the ideal blog engine would be GPL drupal-like, but dedicated to MVC. Any recommendations?

phpSlash?, posted 12 Oct 2002 at 15:21 UTC by garym » (Master)

This should teach me to ask the right questions in the right place: I found phpSlash in the Advogato projects page and it looks like a promising candidate.

b2/cafelog ... simple, but to the point, posted 12 Oct 2002 at 15:44 UTC by garym » (Master)

The first thing that strikes me about the GPL b2/CafeLog is the size of the download .. less than 200k of PHP code. Looks promising in the feature dept too, and there's a large list of active developers and sites using it.

There goes that word again, posted 12 Oct 2002 at 19:43 UTC by amars » (Journeyer)

Why not write your own? One that does what you want... after 9 yrs of experience, surely you'd have a pretty good grasp of the technology required to do so.

why not re-invent the wheel?, posted 12 Oct 2002 at 22:50 UTC by garym » (Master)

amars writes:
Why not write your own?

Our current site is my own, but why write my own when it's more in the spirit of the Freshmeat/Sourceforge tradition to contribute and collaborate on an existing project? IMHO, if more people abandoned their innane not invented here criteria and actually participated in free software (a) the projects list on FreshMeat would drop by 75% and (b) the quality of all free software would be improved.

Even if you take the compromise position, which was my first knee-jerk reaction, to take something GPL and modify the core of it, for example, to take Drupal and gut it to suit my purposes (ie fork it irreparably) it quickly becomes unmanageable if your time is worth any money at all.

Far better to take something close to what you want and worth within its community to migrate it to what many people need.

Ownership, posted 13 Oct 2002 at 03:25 UTC by ask » (Master)

I can't use MT because I cannot trust software I can never own

And you magically own GPL software that you decide to use?

If you really need to own the software you use, you'll have to write it yourself or have it done for you as a work for hire. No?

- ask

GPL, posted 13 Oct 2002 at 06:52 UTC by garym » (Master)

Not so: GPL means you have the rights to the software, to modify it, to redistribute it, to do anything you want with it or to hire anyone you want to do anything you want with it ... except restrict it. You have these rights, I have these rights, your next door neighbour has these rights. GPL is software that we all own.

By comparison, software which does not carry a free license (in the FSF sense) owns a little piece of you; that aspect of your business can only operate at their discretion and while their influence may be minute, it is still a decision about your business that you cannot make. You can never own your systems based on it, at best you can lease them, but unlike the guaranteed term of your car or office lease, software is leased under conditions subject to change at any time.

Microsoft did not become guilty of price fixing because people let them, they did it by changing the rules after businesses became dependent on their monopoly systems. When MetaDot changed their mind about GPL, yes, we could still use the old GPL version, and we did, but MT offers no such alternative: if MT changes their mind, just as if RealPlayer changes their mind, we are forced to change our ways. The software is a gift they offer at their discretion, it is not piece of the commons, it is a hook. Once you're drawn in, they effectively have a tiny voting share in your company.

This is not to say you cannot use proprietary software. You can, but, like joining the army, It's only an intelligent choice when you understand the risks.

Our choice to use GPL is strictly risk-management: I'm willing to take the risk with my streaming media player because, if Real increased the price tomorrow we could live without it; it's a luxury item. I'm not willing to take that risk with content management because, if MT changed their rules tomorrow, we would be forced to pre-empt all normal operations until I'd complied with their demands, and, if it happened at the wrong time (and Murphy's Law implies it will) the costs could be devestating.

GPL is only one, posted 13 Oct 2002 at 07:08 UTC by garym » (Master)

Since ask posed the question, and seeing as Ask is actively involved in Perl, Apache and the new (and very promising) Organica blogmining site (which needs webservices access btw ;) let me clarify that the FSF's GPL is not the only license that places code into the Commons. It's only out of laziness that I use the term 'GPL' to imply all GPL-like licenses which grant permanent and irrevokable rights to maintenance, redistribution, modification and unrestricted use. We use Apache as our webserver and Mozilla as our browser for exactly the same reason.

an aside to ask: there's some links to references to Trust metrics on my current personal (yeah, MT) blog under Trust me on this ... -- these were culled from knowledge management discussions, but still may be useful for your project.

Drupal offers clarification, posted 13 Oct 2002 at 07:13 UTC by garym » (Master)

This arrived today from the Drupal group:

in reply to your article at, I'd like to let you know that in "Drupal CVS" (development version), there is a new mechanism that allows all content to be themed. It is accomplished through the "theme_invoke()" function. [1] As such, you will have 100% control over the layout/markup of your site. However, while the mechanism is there, not all modules have been updated yet to take advantage of it.


XLog made with PHPortal and Xpc, posted 14 Oct 2002 at 14:02 UTC by mglazer » (Journeyer)

Check out XLog made with PHPortal-Xpc released under the Zope Public License (ZPL).

On languages, posted 14 Oct 2002 at 14:10 UTC by Pizza » (Master)

"perl, but not mod_perl, or PHP based."

Huh? All of the other "requirements" you mentioned are perfectly valid, and can contribute to a "good" blogging engine. But then you throw this screwball in there. Why is a blog engine any better because it's written in php or perl? It makes [almost] no difference to the end-user or feature set what it's implemented in. And then you specifically toss out mod_perl. Why? What makes it so terrible that you have to explicitly exclude it?

You choose the implementation language based on its features and the needs of the project.

...more on languages, posted 14 Oct 2002 at 16:46 UTC by mrsbrisby » (Journeyer)

Pizza :
I think garym is simply listing "features" of movable type, and if you don't think the language can contribute alot to the feature set, then you probably don't realize that some people (myself included) will refuse to even consider a program - no matter how fantastically featureful it is - if it is written in PHP or requires mod_perl.

My reasons may differ from anyone elses, so I'll mark them off as non-important. What is important is that it's not a screwball - having the program work in many environments is certainly a valid, desired, feature.

...and more on languages., posted 15 Oct 2002 at 13:35 UTC by Pizza » (Master)

The choice of language (in of itself) won't contribute to the feature set. However, it can make individual features easier (or more difficult) to implement. Generally you'd want to pick the language that makes the most desired features the easiest to implement. :)

That said, you mostly reinforced what I was trying to say. The fact that blog X is written in PHP or perl or mod_perl or fortran doesn't make it any better of a blogger than blog Y. All else being equal, it can be a deciding factor for individual users, but that's about it.

If portability is desireable, then 'portability' should be listed as a desired feature, not 'perl (but not mod_perl) or PHP'. And that's what the article did with the last requirement listed. So I still think that a high-level language requirement is screwball. It reeks of design-by-buzzword(&|committee).

Oh, I also strongly dislike PHP. It's the wrong hammer for 95% of the nails that use it.

...and yet more on languages, posted 15 Oct 2002 at 21:40 UTC by mrsbrisby » (Journeyer)

pizza :
The important thing there is your statement "All else being equal" - I'm drawing a distinction between the <u>capabilities</u> of a blogger, and a <u>feature</u> of it. Again I'll say that garym probably considers a perl-only implementation a necessity of his preferred blog.

Language is a feature, posted 16 Oct 2002 at 02:18 UTC by mbrubeck » (Journeyer)

If you plan on modifying and extending the software you use, language is a feature. If I just want to use a program for an occasional simple task, it can be written in hand-optimized Java bytecode for all I care. But if my job requires me to immediately deploy and support a product, and continually maintain and extend it to meet our particular requirements, then I'm going to pick a solution with a language and development environment that I can use well.

Pizza writes, "It makes [almost] no difference to the end-user or feature set what it's implemented in." But if my "use" of the software includes working directly with the source, then under-the-hood details begin to matter. This is also true of server-side software (like this article's topic): If you aren't the administrator the servers where it's deployed, you may not be able to meet dependencies like mod_perl or PHP.

Pizza is only partially right, posted 16 Oct 2002 at 02:32 UTC by garym » (Master)

My reason for including PHP was because I was aiming for something that could be installed in user space; if your webhost does not offer PHP, you cannot install it yourself (not easily, it's clunky as a CGI), and the same reason applies for Perl.

The astute will notice that I've been so far leaning most towards's B2, and it is not only PHP, but requires the blog manager to learn the very basics of PHP. Since many webhosts do now include PHP, and since PHP 4.2.x with Zend is a pretty decent website platform, I'll concede that while mod_anything is out, PHP is worth considering.

And I list the features of MT because MT is the most feature complete ;) For a free software to be a viable alternative, it has to be a viable alternative :)

XPortal, posted 16 Oct 2002 at 05:36 UTC by garym » (Master)

XPortal does indeed rock, but so far (and I'm still looking) I haven't found the license, but if it is Zope-like (which I don't know off hand) then it's a decent candidate. The talk is certainly encouraging and it's going into my evaluations list.

PHPortal - The PHP Application Builder, posted 16 Oct 2002 at 13:48 UTC by mglazer » (Journeyer)

The license is available here:

Zope Public License (ZPL) Version 2.0

XPortal revisited, posted 16 Oct 2002 at 17:28 UTC by garym » (Master)

I have another criteria that disqualifies PHPortal/XPC: my blog engine must be portable and if not portable, it has to be Unix based -- maybe it's just me, but I've never had much luck running websites under windows, and life's too short to spend any time trying to make it work.

PHPortal is very Windows-bound, using all sorts of MS-hooks (at least for all it's documentation -- maybe the license is Zope's ZPL, but because of all these vendor hooks, instead of paying a license to mglazer, you end up paying a much bigger and nastier license to Bill Gates; if that's acceptable, then you might as well just pay the $150 for MoveableType and be done with it.

For my purposes, however, the original constraint still applies: I must have the rights to use, redistributed, modify and fork any and all parts of the code. Although it might be fine for a lot of applications, PHPortal, by being a sales tool for Windows (I hope 4arrow gets a commission!), is outside my consideration set.

Wrong about PHPortal, posted 16 Oct 2002 at 18:14 UTC by mglazer » (Journeyer)

PHPortal doesn't run on windows only on UNIX servers.

That help active-x on the dev site, that hasn't been updated since its posting a year ago, is what I believe you are talking about in regards to windows.

Use MovableType, posted 16 Oct 2002 at 20:33 UTC by mx » (Journeyer)

If it is excellent, and it doesn't own your data, then use it. The current licensing is relatively open, and the implementation is very transparent (data is in a MySQL db, and can be *easily* exported). Your data is safe, and the tool is solid. The only issue is a moral dilemma ... how important is complete freedom? A question only you can answer for yourself.

It may even be worth encouraging MT to consider a non-commercial GPL-like licsense ... but I wouldn't hold my breath.

I've used most of the packages mentioned here, and they are quite decent. I really have to say, though, that MT is my favorite ... mostly because they built it how I would, saving me the trouble. And, it looks damn fine too ;-) I have been suprised how much the feature set and look of the tool affects the sites that use it (many of them anyway).

I would love to see a similar GPL-like tool, but am already overflowed with new project ideas (well I have a partial implementation, but have shelved it in favour of MT).

For anyone who's interested: the key design win in MT (to me anyway) isn't just the templates (which are a great approach btw), but rather the fact that MT renders the site to static pages on changes by the authors (or comments). The beauty of this is that you can run the tool anywhere (possibly not on the site server), and get the win of static serving. Great for cheap-ass hosting - especially those hosts that don't support any useful apache mods. The tool also supports a good draft-system, and a powerful batch-editing mode ... both of which make site maintanence a breeze.

PHPortal docs and MT licenses, posted 16 Oct 2002 at 21:58 UTC by garym » (Master)

well, if phportal works on unix, it doesn't work here, and every link to a help page hits an ActiveX thing that doesn't work. So I'll grant that perhaps, if you already know how it works, it might work on unix, bu t if you're like me and have never seen it before, you won't get very far. If the docs are available somewhere accessible by a poor dumb browser, please let us know!

as for MT, I've already explained that I can't risk my data on someone else's business decisions. it's ok if it's just a few pages, but after the past 9 years of generating content, that's a lot of stuff to translate to some other system should MT change their mind the other way and go to an even more restrictive license (the way Metadot did). I don't hold my breath about them seeing the light about the GPL; if they think their license is profitable, more power to them, but I prefer to look at software from a long-term strategy view, and in that view, unless you maintain a crushing monopoly, only free-software licenses survive.

PHPortal Docs, posted 17 Oct 2002 at 00:08 UTC by mglazer » (Journeyer)

Since PHPortal is the only Zope replication in PHP the Help docs you are referring to are the same as in the Zope docs which are available at

In regards to more detailed documentation on the specific abilities of PHPortal you can view the html webpages under the 'documetnation' link on the dev site or visit the sourceforge project page with its own html webpages documentation.

The 'help' active-x is in fact outdated and a simple duplication of the basic help one might find in a Zope site.

I would also suggest mozilla/netscape active-x compatible tools that should allow you to view the active-x docs if absolutely necessary, which isn't since the 'help' docs are pretty negligible at best.

my way of working out license and copyright , posted 17 Oct 2002 at 13:24 UTC by sye » (Journeyer)

i wrote a letter and a check of $500 to Chuck Moore since that's all i can afford for now to 'steathily' read and possibly copy all his and others documentations about his colorForth to my own server. Later on, if my team can come up with some value-added products based on his idea, we will write up our own product license according to the bottomline of what our customers need and to the best of our own self-sustainable interest. I shall always add >40% as research and development, patent, license, copyright in the makeup of my production cost. <4% for the cost of hiring lawyers, accountants, receptionist, mailmen etc. That is my way of working out thorny suitcase of license, copyright, patent for my company.

GNUGPL is not the only way out. GNUGPL insists on de-value commercial interest. GNUGPL offered us a collective flag for individuals to let their voices be heard when corporate channels are the only thing possible in all commercial dealings not long time ago. GNU/Linux has made its name on the market. But because of its noble copyleft origin, its value has to be imbedded in the best among established copyright and patented works in order to make GNU/Linux ideal a reality for all people.

PHPortal, posted 20 Oct 2002 at 05:09 UTC by garym » (Master)

ok, welll, having installed it according to the instructions, I get a page at the root that seems to be global configuration options, with an option at the top by that name that leads to a long list of things to be filled out with names like "pth[xpc_pdct]" ... what are these?

so, anyway, on that first screen, some of the fields are obviously database connection and they have values of "required" so I fill them out. I fill out site name, site path and so on. I fill out the passphrase and click submit and I get:

Warning: php_hostconnect: connect failed in /home/garym/public_html/php.teledyn/ftp/xpc.cls.ftp.php on line 50
invalid FTP server: localhost

why does it need FTP? I never use FTP for websites, I use rsync over SSH. why must I now install FTP? Where is this FTP going? The files are already on the server, so where is it that it must send files, and which files is it going to send?

Just because I'm feeling wreckless, I give it an off-site FTP server and click send:

Warning: ftp_site(): /public_html/ftp/tmp.php: No such file or directory. in /home/garym/public_html/php.teledyn/ftp/xpc.cls.ftp.php on line 108

Warning: fopen("/home/garym/public_html/new.teledyn/ftp/tmp.php", "w") - Permission denied in /home/garym/public_html/php.teledyn/ftp/xpc.cls.ftp.php on line 110

Warning: flock(): supplied argument is not a valid File-Handle resource in /home/garym/public_html/php.teledyn/ftp/xpc.cls.ftp.php on line 112

ok, warnings I can take ...

success insert xpc_objects sample data
error insert xpc_users sample data Duplicate entry 'nobody' for key 3
and mild bugs ... but alas ...

You have set up your new PHPortal site an email has been sent with secure info to the email in the form.

Visit your site and or the Managment

Username: nobody Password: ******* (actually printed in clear text on the screen)

Site configuration file unsucessfully created

that last line is a foot note, and sure enough, following those links to my "new PHPortal site" just brings me back to this form, with the passphrase and all other values reset to the initial values; which of the 20 or so fields is in error?

Try Templeet, posted 27 Oct 2002 at 23:39 UTC by penso » (Journeyer)


Templeet is a template system you might want to use for your blog. For example my french personnal homepage use it, see my page and the source of the template : here.

Basicly the template is a XHTML file with some templeet command. For example in my Blog I just upload files into a news/ subdir, templeet will list them in order. But you could use SQL as I do on linuxfr which makes about 10millions hits per month, and as you will see the load is very low, it's very powerfull / fast.

Templeet 1.0 should be out very soon, but don't wait and get a try now, it really rox.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page