17 Aug 2002 CaptainNemo   » (Journeyer)

Part 2

Since I posted the last diary entry, I've had a chance to talk a bit with Dracos who cleared up some questions that I had, specifically regarding the "theme contest". So I'll qualify my statements.

The request for ideas of a replacement to the then current theme engine was put forward to the community in mid-March with this announcement. The concept of what the core developers wanted was decided on. The Encompass rendering engine was ready at this time, but as ladyofdragons put it in this post "there's nothing wrong with what they've been doing. But a more radical change is in order than just a theme that has a templating engine in it.".

Elaborating any more on this will just place me on one of the sides so draw your own conclusion.

It is my understanding that at the start of the "contest" Encompass did not fulfill the goals of what the core developers wanted in their templating system, by the time the "contest" was over Encompass had not changed its design to please the core developers so Blocklayout was chosen over it. The contest was not "rigged" as I had suggested in my previous post.

The flamewar that ensued after the announcement, carried on and, no doubt, brought out the worst in everyone involved. The point of contention was not the decision for Postnuke to use Blocklayout as opposed to Encompass as the templating engine, but the methods through which the management presented the decision among other things. While there was a lull in which people from both sides decided to see if they could reach a united decision, once when the talks broke down the flames started up again, and eventually the fork was announced. Like most flamewars, there were a lot of developments, good arguments, bad arguments, none of which is particularly worth mentioning. The end result is that the Encompass team and the Postnuke team had too little in common to continue working on the same code. The Encompass team announced the fork and created the new open source CMS project called Envolution, which is based on the .714 Postnuke release.

Unfortunately things didn't quite settle down in the Postnuke camp, Postnuke .72 was released and it included a very controversial "lowercase module name" change. When the bickering started back up I unsubscribed myself from the PN-Dev mailing list, whose signal-to-noise ratio was unacceptable.

In the past 10 days, John Cox and the majority of the Postnuke developers have also officially left the project (although, you'll still find many of them hanging out in the #postnuke-chat irc channel). Harry (the last of the original four founding fathers) is now the Project Manager, and a second "Pheonix" .72 release has been released which reverts the lowercase module name change, as well as offers an upgrade possibility to Encompass users. The date for .8 release has been pushed back from 2 months to possibly 6 months.

Enough history. Now my thoughts.

The Postnuke .7x code tree was simply an intermediary step. The goal of the core developers was not to help people settle into the .71 tree, but to move as fast as possible towards a stable API and the long awaited Postnuke 1.0! Like with any other software, after the appropriate length of time the developers stop maintaining the old code and move on coding the next version, and the old code is abandoned. The creation of Envolution is the best thing that could have happened to the .7x code, it now has a home, and a team of coders who are dedicated to maintaining it and taking care of the people who are satisfied with the current codebase, and would prefer stability to the addition of new features, many of which current sites that are using Postnuke, would not utilize fully.

The way we as Postnuke developers would do the best good, would be to press on with the original vision, which is the release of Postnuke 1.0. There is a perfectly good alternative for people who for good reasons do not want to move with the Postnuke vision, and that is Envolution.

Latest blog entries     Older blog entries

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!