Older blog entries for CaptainNemo (starting at number 8)

janschrage: Sorry, I didn't finish my thought... What I meant to say was ``PostNuke needs PostNuke users, and ProjectX needs ProjectX users''. When users start being a liability, is when they veer from the vision and start pushing separate directions. The Envolution/Encompass people were valuable users, they were just users of the wrong project, since their vision didn't coincide with that of PostNuke.

If I was writing a CMS to manage my personal site, the only user I'd care about is the only user that's going to be using it, Me. But since ProjectX has a far wider audience then just the developers, care needs to be taken to see to it that the users needs are being met. If ProjectX doesn't need users then what's the point in writing a program for a larger audience. Of course, like I said in my previous post, the needs of the users come after the needs of the developers, or else you'll find yourself in a situation where the users bite the hand that feeds it.

Even if you're only writing a program for your personal use, and you don't care about anything but your own needs, finding another person who has the same needs as you and starts using your code would be a huge benefit. Now you have 2 pairs of eyes on your code and any bugs will surface twice as fast. Even if your user never contributes anything but bug-reports, he may recommend your software to another user who becomes a developer, or forks off and creates a whole new beast out of your code (which is a good thing).

So I guess to sum it all up, my thoughts are: if you're writing a program for an audience greater then the developers you need users. If not, then users are an asset. Either way, users are a good thing :)

And, I do get a kick out of knowing that my code is being used by someone other then myself, it wouldn't be enough to keep me working on a project though.

janschrage: Thinking that a project doesn't need users is what lead PostNuke to fork from PHPNuke. Here's the deal:

When PostNuke forked from PHPNuke, it brought along a huge group of users. These were people who were already using PHPNuke and for whatever reason (the energy, the people, the code) they decided to use PostNuke. For the most part these ``users'' had production sites which they, against the warnings of many of the developers, immediately moved to PostNuke. They wanted/needed support for their current site. They did not have the 1.0 vision. They were not PostNuke (as per the Vision) users.

PostNuke needs PostNuke users, however, when it comes to listening to users, this must be done after the developers have reached their goals (post version 1.0). I have to agree with you that without the developer there will be no software, and I hope that ProjectX will be open to it's users/co-developers and their suggestions and ideas.

Treat users like your greatest asset and they will turn around and become your greatest asset.

niceguyeddie, I have never had any training (formal or otherwise) in management, so your `rant' was quite interesting, now my rant :).

While I'm sure there is a lot that we can learn from commercial software project management, the dynamic nature of open source projects makes the overhead that Commercial software management carries with it unneeded. I think that is the point that ESR was making.

Bringing your thoughts about goals and management together, I'll blockquote some more ESR...

Can we save defining goals as a justification for the overhead of conventional software project management? Perhaps; but to do so, we'll need good reason to believe that management committees and corporate roadmaps are more successful at defining worthy and widely shared goals than the project leaders and tribal elders who fill the analogous role in the open-source world.

That is on the face of it a pretty hard case to make. And it's not so much the open-source side of the balance (the longevity of Emacs, or Linus Torvalds's ability to mobilize hordes of developers with talk of ``world domination'') that makes it tough. Rather, it's the demonstrated awfulness of conventional mechanisms for defining the goals of software projects.

Like I said in my previous diary entry, having first hand experience leads me to question much of what ESR puts forward in his papers, so I'm not going to argue any of what he says. I do tend to think that overmanagement can be more harmful to an opensource project then undermanagement... it is a bazaar afterall.

niceguyeddie, sounds like you need a dose of the The Cathedral and the Bazaar. I'm sure you have read it before, but reading it again after being involved in a project that went belly-up was very interesting for me. Actually, I agreed with a lot less then I did the first time around, having first hand experience puts it into better perspective.

This section would probably be the most interesting as ESR talks quite a bit about the role of management in open source software, specifically traditional "goal based" management vs. Bazaar style management.

17 Aug 2002 (updated 17 Aug 2002 at 18:16 UTC) »
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.

17 Aug 2002 (updated 17 Aug 2002 at 09:39 UTC) »

This is where I'll state my position on the Postnuke/Envolution fork, as well as the internal problems that Postnuke is currently going through.

To start I'll state that I'm not a major developer. I've contributed a little code way back when it started, and since then I've whipped up a few command line scripts that I needed and contributed them to the project. When I talk about the "developers" or "devs" I'm referring to the hand-full of core Postnuke developers.

Postnuke started out by forking PHPNuke which, of course, forked off from Thatware. At the time of the Postnuke fork, there were a lot of disgruntled PHPNuke users/developers who became the Postnuke userbase, I was one of them. The goal of the Postnuke developers was not to enhance PHPNuke, but to create a whole new Content Management System. Under the leadership of John "niceguyeddie" Cox, they started a souceforge project and designated project as in Alpha stage.

Being in Alpha turned out to be the excuse that excused many major code upheavals. First it was decided to use PEAR DB abstraction code, then that was dumped for ADODB, then once the API was somewhat complete that was put into use. The decision to make many of these changes received a good amount of critisizm from the module developers as well as most of the community, however none recieved as intense critisizm as the coice of templating engines.

As the self-appointed keeper of the PN-Dev mailing list archives I can say that there have been a few minor disagreements and flames over the year that PN was in development. Some of the disagreements were settled, some simply blew over, and others resulted in the loss of a developer, but unlike what we have seen in the last few months, most people handled themselves in an adult manner. The issues were worked out and the development continued.

The developers in who made the choice of templating engines received harsh and personal critisizm regarding their decision. The developers who were working on Postnuke had every right in the world to choose whatever templating system they wanted to use, however, the mistake that was made was that the decision was not mandated (like it should/could have been) but put forward as a contest. A contest in which the people who would decide the outcome were also very involved with the development of one of the templating systems that were in the running. This was in no way a fair contest.

So the fit hit the shan when the annoucement was made that Blocklayout was being chosen as the Postnuke Templating engine. Blocklayout differed then Encompass in that Encompass was a complete, feature filled system and Blocklayout was still in the conceptual stage. The other differences between Encompass and Blocklayout are beyond the scope of this diary entry.

Well, this has been interesting but my time has run out and I've gotta run. I'll try and finish it some other day.

11 Aug 2002 (updated 11 Aug 2002 at 18:33 UTC) »
Zope
I've been fooling around with this for the last few weeks, great platform! I think I'm going to have to learn Python after all. I'm finding PHP less and less fun, it's practical, but not fun...

There is a lot PostNuke could learn from Zope, but since the vision and philosophy behind Zope differs substancially from that of PostNuke I'm hesitant to start talking about major vision swings.

PostNuke could be a PHP Zope, the basics are there... maybe a future fork will go this direction.

I love these </> tags :)

7 Aug 2002 (updated 7 Aug 2002 at 09:27 UTC) »

O.K so I got 2 replies to my last diary entry. One from mbrubeck with the url to advodiary, and the other from gregorrothfuss with a PHP code snippet which suits my needs nicely.

Thanks guys!

Advodiary

I'm using this right now, I realized that I didn't have Python 2.2 so I ran to ActiveState and grabbed the latest build, but then that didn't work properly in my perferred Cygwin environment. The Cygwin Python port seems to be working alright (I've got this far :).

Lets see what happens when I publish this!

So I've created an account, and I'm trying to figure out how the xml-rpc interface works.

Are there any apps that work with it? Is it compatible with the blogger API? I googled, but I couldn't even find a whole lot of specifics as to the API.

If any oldtimers can help me out drop a note to nemoatthebooniesdotcom.

Thanks

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!