Older blog entries for niceguyeddie (starting at number 4)

gregorrothfuss -- I agree with you that is an valid point. Stability breeds consistancy. I am not so concerned about org structures per se, but what drives people to make the org work. Its a curious subject. In some cases it is a very clear cut definition of what drives the people behind the project to success, but in other cases its a lot more blurry.

Still need to think about what is the Absolute Goals, and not the relative ones. I have read quite a few good ideas, but I still think its not as defined as it should be. Is a projects end goal satisfaction, or something more or less abstract? I am not so sure that I have ever seen the goal defined (not talking about technical goals), but then again, I am not all that well read as most of my peers in the open source community.


NFL starts tonight. Giants at the 49'ers. I pick the 49'ers in a 24 to 17 victory over the Giants. Giants lack the QB, unity, and cohesion to do alot this year, but then again, I am not an expert. I like the 49'ers even with the points.

Team building is a challenge for me with open source projects. There is a certain amount of latitude that you have to give everyone on the team in order for there to be some fun, and there is also a certain amount of control that you need to have over the processes in order to maintain the desired consistency. Motivation I have found, usually isn't nearly the concern as it is with for-profit projects, however, keeping everyone on the same page is. It is quite unique that the constraints are completely different with the mindsets.

I suppose that this can be illustrated through the 'TOC' theories, since the exploiting the constraint is different, as well the measurements, and the end goals. Is there a need for throughput reporting, when the goal isn't always to show a return?

I have been looking at the different models of OpenSource structuring, and how successful projects work, since my last project goes into the semi-failure side on my management skills. Some of the organizations such as Apache make very good distinctions as to the 'ladder' of responsibilities, and accountabilities, but I have been wondering if it is the best model for me to benchmark and measure against. Not to say that it isn't the best to emulate, but are there further opportunities to exploit from the constraints of the org structure?

I still don't know if I can grasp in my mind what the ABSOLUTE end goal of an open source project management should be, when there appears to be several to choose from. I must somewhere along the line seem to be missing the castle at the end of the maze. If you take any kind of money out of the equation is the end goal simply satisfaction of creation, or is there some other goal to ponder? If you throw any money back into the equation, does the P & L and throughput become the top of the line as the 'goal'.

Bah, need a beer and another vacation to start think more abstractly.

Ughhh, first day back to work after a weeks vacation. I really should have taken two weeks back, just to clear my mind completely (not hard to do), and to enjoy a little more family time.

Its amazing to me that both of my kids are in school now. Something about them being 4 and 5 make me feel older and older. They are both incredible, and I hope they have a wonderful year, and meet new friends, etc. I know that it has been a hard summer for my oldest because of the move, but I hope that she finds some new 'best' friends.



Why are project names so important? Is it the name of the project or the code of the project that matters the most to people? I know that communities need their names, but which is most important on the grand scheme of things? Do projects with the greatest code but the crappiest name still succeed, and vice versa?

Accomplishments are easy to determine from a technical sense. Sometimes they are just reaching a milestone that you set out to reach with your project. Sometimes in a fit of caffeine and nicotine, you reach a technical accomplishment with a little thought and and a little work. This is what I did with the very first install file that I wrote for PostNuke. After about a day I had something workable (although very ugly to look at) and it set PostNuke up to move forward.

Organizational accomplishments though are harder to realize. Sometimes with the snowball reaching critical mass it becomes very hard to steer it, and impossible to change the direction. I feel that yesterday however, there were organizational accomplishments that allows us to have the flexibility to move forward. As cryptic as it sounds here rereading what I just wrote, I think that the organization that a GPL project rides on is just as paramount as the technical innovations that drive the code.


Released the first tarball from the CVS. With the changes in the architecture there were several problems with the code. I have received several emails today chronically those problems. I really hope people read and understand that the tarballs are by no means ready for a production site. I needed to release it to start showing the changes in the dot 8 architecture, but I do worry about the perceptions that it might allow.

8's not a stable codebase, while 7 was, and I hope that some folks realize the difference between the two.


Finally I got to work on some code yesterday! Its been a couple of weeks since I last got to open up my editor and enjoy what got me started in the first place. Several problems that I noted were with the modules init and the change in function names that we recently instituted for better readability and function flow.

I'm still a little concerned at the config being in an XML format. Seems like there are some security risks there. I need to think about it a little before we move on with the config being formatted as such.

That is exactly what PostNuke's current direction is. The X Project doesn't have any intention of caring one bit what a possible userbase wants - which was the single divisive issue behind the spit.

Just FYI.


Right! Comments like this were the exact reason for the split. Thanks for the illustration, Harry!

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!