We opened an IRC channel for this project. It is on Quakenet, “#burstcms“. So if you have anything to ask, come there and ask. We will happily answer any of your questions. In the future we also give support on that channel.

Also when I have time, I will create statistic and log file from channel.

And this was my first post to this blog. As I am one of the developers of this project.

BurstCMS is a content management system that gives a lot of power to third-party developers. Modules, such as blogs and forums, frequently control the entire page. Components do work such as parsing BBCode for the modules, and often have close ties with the database.

Some people think that this structure is a recipe for destruction. There are many programs in the world that are positively crawling with bugs. Now, if three BurstCMS modules depend on one BurstCMS component, and that one BurstCMS component happens to be rather buggy, the effect is seen in all three modules. Clearly, it is dangerous to write buggy code in BurstCMS.

There is also the fear of malicious code. What if a malicious hacker releases a BurstCMS component that actually does something horrible, such as deleting all the data? That’s why BurstCMS will have an official module and component repository that will be filled with modules and components that are safe and relatively stable.

Of course, modules and components that exist outside of the official repository can be installed. It’s still quite dangerous.

So why have so much depend on the skills of third-party developers? Because BurstCMS can’t hide from bad code. No matter how restrictive we make BurstCMS, bad code will still somehow ruin it. I’m sure you know the saying.

If you make something idiot proof, the world will engineer a better idiot.

This applies to our content management system. If third-party programmers are allowed to participate at all, bad modules, components, plugins, widgets, or whatever they’re called will eventually end up in at least one BurstCMS installation. How?

BurstCMS is open-source. People are free to change the PHP source code to whatever they want, and then distribute the code. If we really wanted to lock ourselves down from bad programming, we would make it closed-source and never tell a single soul about the content management system to avoid people somehow writing code for it. Obviously, never telling anybody about your content management system takes quite a lot of the fun out of developing it.

Only time will tell whether BurstCMS will succeed with this structure. If the BurstCMS team’s plans are in the direction of failure, and BurstCMS is indeed a recipe of destruction, perhaps it will be a tasty recipe.

It’s not much, but it is a good idea to start committing things early so it is easy to track project development all the way to the beginning.

It’s only a few files, and it doesn’t really do anything yet, but if you want to see the early code, you can check out Google Code.

For those of you that have checked out CodingExperiments, you might have heard about my idea of a new type of content management system. I call that BurstCMS. I’m proud to say that I have got another developer or two and have actually started work on BurstCMS.

This blog exists so people can keep track of BurstCMS news as well as post questions and comments.

And yes, it’s a little ironic that we are using Wordpress. When we get enough code written to make a good blogging platform, we might switch.