Older blog entries for niceguyeddie (starting at number 7)

How does anyone make something extremely complex also user friendly? The Xaraya permissions system is extremely complex, but at the same time extremely powerful. My task at hand codewise is to figure out how to change the system so that it has better sorting capabilities, better user friendliness, and is still backwards compatible to the .7 API spec.

I have ideas, but without spending time working on them, I am not so sure that they will pan out. I have to basically build two new systems in order to improve the friendliness without degrading the power that makes them what they are.

For the people that have figured out how to use the permissions, they understand what can actually be done. However, I fear that not many have figured them out. Most of all I fear that people writing modules have limited the power of the system due to people not figuring out the permissions GUI (namely only using the Admin and Read permissions and skipping the rest).

I suppose this next week will be fun. I am taking vacation, and spending the time finishing my office (got all of my puter's networked today, along with RH installed as a dual boot on my kids computer) and working on the modules and permissions module of Xaraya. Possibly on the next writing of this journal, I may have cracked the problem, but at 10:30 on saturday night, its not looking great:)

captainnemo -- Yup, read them! The problem is not so much for me the idea of how to come to a successful project, because each of those white pages deal with it very nicely. What I am more interested in is applying the theory of constraints to Open Source development. Here is a brief overview of what I am talking about. There are basically three major developments in the TOC. Its also called Drum Buffer Rope in some sectors. The definition of each goes something like this:

Drum - The constraint. If we can agree that everything upstream from the constrain and everything downstream from the constrain can operate faster than the constraint itself, the the constraint is what actually determines the throughput.

Buffer - If something upstream from the constraint goes down or has problems keeping up with the constraint in the meantime because of "murphy's" then there needs to be a "safety" net of time to allow the drum beat to continue on.

Rope - You do not want to flood the system with "stuff" instead, you want to release into the system "stuff" at the same rate of the drum.

So how does this apply to Open Source Management? The same way that it apply's to project management in general. There are scheduling constraints. You need to apply a certain amount of buffers into the overall system scheduling in order to always be feeding the constraint. And you don't want to start anything new until the constraint can handle it.

What I am confused on is the goal of Open Source in general, in order to lay down a general project management white paper to push forward the ideas in general to increase the productivity of all:) So is the goal the same as commercial projects, to make money in the end? If so, then the constraint and measurements to let you know as a manager of the project needs to be set accordinly. However, I am not so sure that is the actual goal of every project. Some projects have no intention of every making a dime, but rather the goal might be to scratch the "itch", or to do something different, or to learn, or to accomplish something that others said would be impossible.

I could easily set up the goals for the my project, since they are relatively easy. However, I am just thinking aloud, because this is something that is very interesting to me, and I would like to write something from my experiences, and allow others to have a good model not for their organization or project, but rather something to help them plan and manage just a little better, using and applying some theory, and some know how:) I am just stuck at the beginning though on getting started with the actual goal, which I have taken for granted for so many years.

To me, it's an interesting exercise, thats all:) I am not trying to reinvent whats been done before, but rather to apply some of the theories that the commercial software sector has been applying for years, and relating those back:) You see, in many case Open Source has an advantage over the MicroSofts of the world, since the goals are different. However, when you drive the other car (M$) you also have several roadmaps and signs that we do not clearly have. I just think that by constructing some of those signs and maps, we are able to compete more as a community which is a good thing for all:)

Rambling again... Bah, its a diary, I'm allowed:)

--

Chloe's first ever soccer practice is in 2 hrs:) I am a lot more excited about it than she is.

I need to get my predictions for week 1 NFL as well;) Predicting against the spread is a little more difficult than the out right winner, but it is also a little more fun:)

A little more free thinking on using TOC theories with open source management, and how it can be used to increase productivity and ease the 'murphy's' that exist for anyone that is dealing with group type development. A good article on the subject (more a research paper, but nonetheless) explains the relationships of the constraints to scheduling and management.

http://www.sytsma.com/cism700/toc.html

Granted the TOC theories are often thought of in the context of manaufacturing, however the overall concept can be applyed anywhere, such as project management, or optimizing any system to make the system run better.

The two main things that I am confused on though is the actual "Goal" of a open source project. There needs to be one actual pot of gold at the end of the rainbow so you can set your sites on it, and set the system to exploit the constraints accordingly. What is the goal of any open source project? Is it just simply the satisfaction of creating instead of the normal throughput measurements of business?

I did find a couple of interesting articles on the subject, including one on Advogato by rakholh which he says "The whole point of making a program is not to keep it tucked away in some secret hidden vault. It's for everyone else out there to enjoy and use. That is the ultimate goal of any program, be it opensource, closedsource, commercial or non-commercial." but I am not so sure that it applies to what I am thinking, because commercial projects main goal is not to have everyone use the program if you buy into the therory of constraints but rather the end goal is alway to make money. So can the same be applied?

Hmmm, more pondering to do:) Seems its a difficult question for me to answer.

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.

---

Project

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.

Harry

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!