A few years ago everyone agreed that open source content management systems would revolutionize web development and website management. It did - just not in the way everyone expected. Now instead of having websites that took a programmer to change, people have websites that no one alive can change. Beautifully discordant sprawls of code connect undocumented databases to random scriptlets written by other random programmers from across the world. This randomness is further complicated by the fact that no paid support exists for any of this code. And say what you want about the evils of Microsoft, when your server gives you machine error 2918384G7, you're really happy there's someone you can call about it.

So what happened to open source? Why did it happen? And most importantly, what are providers and consumers of websites supposed to do next? I'll try to answer these questions in this article.

In the beginning, there was static HTML. And we loved it. Then users began demanding more and more functionality, as they are wont to do. Into this void came a slew of programming languages and toolsets with varying degrees of success. But in general, we moved forward from a "static" world of HTML to the dynamic world of scripts and compiled languages. Things were good. The people rejoiced and set off to write spider-webby rat's nests of code in several common flavors. When a change needed to be made, the programmer had to make it. So we all hated the programmer, but we couldn't let on, because we needed them.

Then, some smart individuals realized that we were actually custom programming the same or similar functionality over and over again. At least it seemed like similar functionality. So a few of those smart people, mainly folks at universities, decided that business and paid programmers were the root of much evil, and they set out to create a brave new world of free code that anyone could use to meet all of their website needs. A fantastic idea. Developers on various forms of financial support and at schools and in basements all across the world set out to create all of the code we would ever need. What about customization and documentation, you might ask? And what about support for this code? Well, the user community would provide all of that. Obviously!

This idea took hold, and understandably so. Why re-invent the wheel each time you create a website? But where did it go wrong? In my experience with web development over the past 10+ odd years (yes, I had a website in my AOL account's free 1mb of web hosting space), I think open source falls down for these reasons:

1. No one is responsible for anything. Open-source developers create CMS systems knowing they aren't responsible for their support, customization, or even deployment. Lack of responsibility has never led to anything good in the IT world.

2. No one documents anything and no one updates documentation. Many CMS's claim to have good documentation. They usually don't.

3. There are too many systems out there for any developer to learn. Open source has made most developers into neophytes due to the sheer volume of different code bases they are forced to work with. If practice makes perfect, then no practice probably makes imperfect.

A caveat here: I will give clear kudos to companies that develop their own CMS and then develop strictly on that platform. That's what my company chose to do, aside from a few "vacations" into the world of open source.

4. Open-source fever has led to a "self-prescription" problem very similar to the rampant self-prescription of medication based on TV ads. Customers come to a developer with a solution already selected. This is not a good idea.

5. Customers think open-source means "free". When it actually means "a lot more expensive in most cases because no one really has any idea what they are doing with it."

I could go on, but you probably get the point. The idea of open source, though idealistic, really never made any sense. Web developers have known this for years, and have mostly been quietly waiting for the day when the users would realize just how bad an idea it really is (once again, this doesn't apply to professional firms who develop and stand behind their code).

So, where does all of this leave you? Your company or organization needs a website. You don't know the difference between a java bean and a web service. And your decision could well affect your professional and emotional well-being for the next twenty years.

Well, if it was my website, I would:

1. First, decide what it is you need your site to do. Do you need to sell your products online, offer downloads of your menu, or provide an intranet to your employees? Do not tell a provider how to do something, tell them what you want the results to be. You're going to be paying these people good money, they should bring some kind of advice to the table, right?

2. Research the companies that create websites in your geographic area. Make a list of them and contact them. You can find them simply by Googling "Web Design + your city". If they don't show up on the first page, you probably shouldn't be working with them.

3. Call them up. Tell them what you want, and ask for a quote. Also be sure to ask them:

4. How long have you been in business? What is your core competency and focus? The longer they have been around, chances are the longer they will be around in the future. If they do web design as a tertiary service (marketing companies are common offenders) then that's a bad sign. You need to find someone with a few geeks on staff, preferably with a good handler (or "project manager").

5. Do you offer a CMS, and if so, who wrote it? You want a firm that is using software they wrote, or else have years of experience with. Any firm that tells you they can use any CMS you want is crazy or dishonest or both. They really can't. At least not very well.

6. How will my website be supported once it is launched? What about customizations to the software?

7. Who will own the code? Is it mine, will it be licensed to me, or will you provide some guarantee as to ongoing viability and usability of the software. You just want them to have some kind of legitimate answer to this question. Sole ownership vs. licensing vs. guarantees can all work in the right situation.

8. And finally, you should ask to speak with existing clients on the same CMS platform you're going to be on. If there isn't anyone, you probably don't want to be the first.

Once you've done all this, you should be able to narrow down your list to one or a few options, and make an informed decision. Will it be an open-source solution? Maybe. But I doubt it. And even if it is, you should have the assurances of a solid and well-established firm about ongoing support and expandability of your website code. Remember, if you make a mistake, it will only result in years of heartache and probably a summary dismissal from your position. So no pressure or anything.

-Al Polanec is a business owner and co-founder of Blue Archer, Inc, a Pittsburgh-based IT consultancy since 2000. Mr. Polanec has been directly responsible for the implementation and development of 100+ websites and web applications, and has overseen the development of over 400 websites and web applications over the course of his career.

Read more about Pittsburgh Web Design at www.bluearcher.com.

You can also read this article on our website here.