Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

As I understand it, there are three different "types" of CMS:

  1. Proprietary: A CMS built and owned by a company, and altered to meet a client's needs.

  2. Open-Source: An open/free version of the above. An existing system altered to meet a client's needs. (E.g. Drupal, Joomla, etc.)

  3. Fully Bespoke: A CMS built from scratch to the client's exact needs.

It seems to me that, from a client's perspective, their order of preference (if everything else was equal) would be 3 -> 2 -> 1.

There's a danger that option 3 could be riddled with difficult to understand code, but that's a danger with the other two as well.

As developers, what's best for our clients?

I ask this because a competing agency just pitched to one of our clients that Open-Source CMSes are the preferred solution. While I can see the benefits of using OS software, I can't see how it's better than a Fully Bespoke solution.

As a developer blog put it,

"Adding features to [an existing] CMS is not easy. It takes more time than to develop the feature alone, because you need to trick the CMS into doing something it was not designed to do. This is especially true for features that write to the database a lot, like community features, or features that have unusual business logic."

share|improve this question

closed as not constructive by Matthieu, Mark Trapp, Walter, Jim G., Robert Harvey Aug 13 '12 at 23:45

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

4 Answers 4

It depends entirely on the situation:


Pros - Developers intimately familiar with the software; potentially reduced cost and stability by mostly re-using code that's been used before for other clients; software owner has a direct financial and contractual responsibility to the client

Cons - No control or ownership over code; vendor lock-in; typically harder to gain direct access to data


Pros - Larger potential developer community; access to code; opportunity to take over development in-house; larger potential support community; reduced cost and stability from starting with an existing solution

Cons - Need to code against a project you may not already be familiar with; no control over project direction, so upgrades might become difficult or impossible with custom code attached; potential lack of support if project dies; starting with a generic solution can limit feasibility of new features or make implementation much harder (e.g. the project's API might not provide something)


Pros - Client has total control over code and data; tailored completely to client's needs; a framework, as opposed to a complete CMS, can be used as a starting point

Cons - Typically the most expensive solution since everything is done from scratch; no external support

Custom would almost always be the choice if cost and time weren't factors. But they are, so the other options are often chosen instead. Proprietary is almost always the least favorable choice today because vendor lock-in is a huge drawback and there are so many popular open source alternatives.

share|improve this answer

You are avoiding a lot of risk from a stability standpoint when going with prewritten software. While you give up some level of control, you gain quite a lot in exchange. Another thing to keep in mind is that implementation is usually much cheaper than custom development.

There isn't really a general answer to this kind of situation, there are pros and cons to each. I would recommend thinking of them as a line, to the far left you have configuration changes being the entirety of what is available. As you move to the center and the right, you add increasing amounts of code changes. Note that in a strict definition sense, the leftmost point is proprietary, and the rightmost point is custom, in between is all open source. Also note that I would characterize an open source system you didn't change the code to as propitiatory (for the purposes of this discussion).

As you move to the right on this line, you are introducing more risk from a stability standpoint. Your average developer can't compete with a product from this standpoint. This is just due to testing, the amount of testing hours that go into a product is vastly superior to the internal usage at all but the largest companies.

Another thing to keep in mind, is that the line is a simplification, what is even more important, is whether you are customizing core parts, or the fringes, also the complexity of the change. Adding a couple of extra options to a few drop down boxes to match your companies policies is pretty painless. Rewriting the aggregation logic to focus on what you care about can be very painful.

Given that the increase in flexibility comes with an increase in risk, it is difficult to say as a whole, which one is the best. It depends too much on how close a given implementation is to what your business requires (note that even a proprietary system doesn't need to be exact, since you can always adjust your processes to accommodate for the difficulty)

share|improve this answer

Well, it depends.

First off, let's throw out proprietary code: when I was a consultant to a client, I basically told them, it's a scam. You're binded forever to that particular company and they can ask whatever they want for any kind of modifications for which there is no pre-built functionality, and they can ask for extra for any functionality in the future.

So, option 1 isn't an option. Ever.

We expect option 3 to come with the sourcecode given to the client at the end, otherwise see option 1.

Between option 2 and 3, it depends, what kind of website it is.

Usually, there are three routes:

  • grab an open source CMS, and add required functionality in terms of modules
  • grab a (usually open source) MVC / MVVM / ... framework and build required modules
  • build everything from scratch, leveraging only (mostly open source) libraries.

As you see, here, basically we have a framework appproach problem.

Most open source CMSes will have a content-oriented approach: it's relatively easy to create text content and navigation in them, and you can build modules which are usually record-oriented (so, it's basically a CRUD system with modifiable templates and the framework generates admin interfaces for you). Also, you can grab existing modules which are doing certain tasks, you can grab paywalls, etc.

Think of it as a content system with plugins.

Their disadvantage is, that their programming approach might not fit what you're developing, and also that their interface can be cumbersome. If the customer is actually in need of an application, with only a few static pages, but otherwise no resemblance of an online portal / newspaper, it's just a waste of time, effort, and UX.

With frameworks, you usually build an application, and the administrative interface contains only what the user really needs.


  • it's tailored to the user's need from a UI perspective


  • it offers less freedom on user configurability (or freedom costs more)
  • UI has to be designed from scratch for the administrative interface

(If there's no admin UI, go for it, now :)

And then, there's the custom approach. It offers an enermous code flexibility. If your application isn't a record-based information application, or you have groundbreaking new ideas on how to develop really understandable code which already proven in a pet-project that they're better than MVC / MVVM / MV*, then you might have a go for it.


  • Performance (usually such apps are faster)
  • More domain-oriented model, so, it's tailored for the user both inside and outside


  • Slower development time
  • Perhaps noone else could touch it
  • All the cons of the MVC solution

So, all in all, it depends on:

  • what kind of use cases is it supposed to support
  • what kind of complexity is the user able to bear
  • how much development effort (or: how much money) is there to finisih it
  • how much is vendor lock-in problematic

Usually, the question is between an Open Source CMS or an Open Source MVC framework, and it's nearly never fully custom development, nor is it proprietary.

But again, it depends on usage.

share|improve this answer
-1 It's a scam because they can? So you are judging companies to be scammers based on what they supposedly could do in the future? Do you have a crystal ball? Not a very professional piece of advice in my view. –  CesarGon Aug 13 '12 at 17:59
@CesarGon: sorry, in my country, this "we host our own CMS" approach has left 3 of my partners out in the dark and the costs of a single new module were always above half of that a complete new system from scratch (but never 100%, they ain't stupid). Perhaps it's not a scam per se, but in Hungary, this is actually a business model –  Aadaam Aug 13 '12 at 18:47
@AndrewFinnell: No, the problem is that the total cost of ownership, given 3 change requests is between at least 150-200% of any other solution, while usually the flexibility of the service provider is lower as they have nothing to fear - they can say easily, "it can't be done". Listen, you might be part of this business as well,I'm not, I'm doing a totally different business, and ocassionally help out small companies for an insignificant amount of money or even sometimes for free on the CMS business with advices (no code!). For a SMB, 200% price is scam, even if you call it profit:( –  Aadaam Aug 14 '12 at 0:39
I understand and sympathise with you. However, three cases do not constitute a business model, and even if it did, your experience in one country does not necessarily translate to the country of the OP, which might have different business habits. So, I am not saying you don't have reasons to criticise the providers that have left you in the mud, but I insist: personal experience does not equate universally-applicable advice. –  CesarGon Aug 14 '12 at 20:03

I cannot believe that the preferred solution for a client would be a completely new system. I understand how for a consulting firm they would want to do this because it would give them the most billable hours, but from a customer perspective this seems like a disaster. It's asking the customer to wait an unknown number of months/years before they have anything usable.

I'd honestly look at the open source solutions that are available and pick the closest solution that will meet the customers needs compared with the ability of your team to take ownership of the open source product.

The key would be your teams ability to take ownership of the OSS software. Maybe years down the road the original package looks completely different but it seems more reasonable to start with a known working piece of software than starting from scratch.

It is also quite possible there are many enhancements that could be contributed back to the community through the OSS solution.

I couldn't imagine a customer asking for a ESB and the first instinct would be to write a completely new one instead of looking at Fuse or JBoss or something similar. But maybe CMS's are always too customer specific and no framework would ever be suitable for a customer. But somehow I doubt that.

Of course, within the correct budget, the best solution with a proprietary CMS that did 100% of what the customer needed. But if that existed they wouldn't need you.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.