Newfangled works with independent agencies to create lead development web platforms for their clients.

Newfangled works with independent agencies to create lead development web platforms for their clients.

Choose a Developer, Not a CMS



As I listened to one of the last panel sessions at this years HOW Design Live conference, I was surprised by how many questions were asked by the audience about content management systems (CMS). They ranged from the easily answerable—Do I need to use one?—to the not-so-easily-answerable—How do I choose the right one? As the questions kept coming up, I couldn't help but feel that the discussion was veering off into the wrong territory. It wasn't just that the question of which tool to use lacks a simple answer—most experienced developers have a preferred platform and will be able to make a good case for using it—but it seemed to me to be the wrong question to ask in the first place. The more important question is, How do I choose the right developer? I believe that if you choose the right developer, you will also choose the right CMS.

For many organizations and individuals, the choice of CMS is representative of far more than just a tool; it is often seen as a much more existentially defining decision, life altering in the way we think of geography or ethnicity. But honestly, folks, it's not nearly so grandiose. If you only built your website once, perhaps such a grand view of its inception might be merited. The mundane reality, of course, is that the lifecycle of the average active website is 3-5 years, often continually adapted to the changing technology of the ecosystem of the web. If you want to take a long-view at the beginning and make decisions accordingly, you're better off making a choice of relationship—aligning with a person or firm that will bring wisdom and stability to that changing environment—not one of technology.

Still, it is very common for specific solutions to be chosen purely on the basis of a perception of portability—the idea that once the website is built, the CMS won't impose any barriers to relocating it or enabling any developer to work on it later. While I'll agree that portability sounds fantastic, my experience has taught me that it's actually never that simple. A sophisticated website—anything more than what you might call "brochureware"—whether built upon an open-source CMS or something proprietary, will likely launch with enough customization to make it truly unique. In other words, two websites built upon the same platform could be speaking very different languages when it comes to their underlying code. From the point of view of one developer trying to make sense of another's code, true portability is a myth.

Though portability may not actually be the most relevant consideration, thinking critically about the CMS a potential developer will use is still important to do. But rather than evaluating the various platforms technologically, I think it makes sense to do so strategically—looking for what you might discern about your future partner (and website) in the process. So this month, I'd like to evaluate three possible developer/CMS scenarios and hopefully provide you with some points to consider next time you're making a buying decision.







Comments

Joel Sutherland | July 26, 2011 9:35 AM
Chris,

This really is a wonderful article!

I think you really nailed the portability topic when it comes to medium to larger-scale websites. The cost of migrating content is just so much lower than developing a deep partnership that it really shouldn't be a big factor when choosing a platform now that web development best practices have matured.

Peter | July 26, 2011 10:04 AM
Great article, I've experienced exactly what you said with "pushed beyond their comfort zone".

Once things get a little different you end up at the drawing board ;)
AJay | July 26, 2011 10:09 AM
Fantastic article!
John Pitchers | July 26, 2011 10:10 AM
Chris,

Great article. Your bias towards proprietary systems is obvious. But, hey! I'm open source all the way.

In my business, hardly a week goes by without an email from a potential client at the end of their tether asking for help because their developer bailed, or went back to uni, or just plain disappeared.

The low cost of entry into web development as a profession has led to the rise of an amateur army - spiky haired 20 year olds that think they can bang out a site in a day for a thousand bucks and every one will be happy. Had to chuckle at "that point isn't mitigated by being related to the developer."

I urge any potential clients to read the title of this article over and over. Choose a developer, not a CMS.

J
James | July 26, 2011 10:30 AM
I can't express how strongly I disagree with your conclusion. Your premise is sound - I agree that people need to focus on choosing the right vendor to work with, not worry themselves with the specific technology choice. By hiring a competent firm, they will recommend the technology most appropriate to your needs (or they should at least).

However, this article takes a bizarre left turn into spinning the anti-customer business model of "single vendor lock-in" as the optimal choice. By deploying a proprietary CMS, you are now the only vendor the client can return to. Once the site goes live, they are essentially your hostage. With such guaranteed business, what motivation is there for the company to continue to produce high quality work at reasonable prices (aside from common decency, of course)?

I've had to save organizations from this kind of toxic "hostage situation" time and time again.

This is one of the big selling points to using an open source or even a licensed off-the-shelf system. If your relationship with your vendor goes sour, or the company goes out of business, you aren't left stranded.

As a client, I'd personally rather work for a firm who is dedicated to doing a good job to keep me as a client as opposed to relying on proprietary technology handcuffs.
Robert Whyte | July 26, 2011 10:44 AM
Right On! Relationship is the key here. Technology in and of itself never solved anything. Understanding clients true needs is the real question. Offering real services, not shiny software is the only viable solution.

Admittedly it is quite hard at times to educate potential clients that they are paying for time and commitment, not just trendy one-stop shopping solutions.
Josh | July 26, 2011 10:59 AM
Well written and informative as usual, but I must admit with James (last post) re the client hostage comment.

I had a recent case of this with a client at wits and wallet's end because of a technology company I had partnered with years ago. The client is now struggling financially and one of their biggest monthly expense was to keeping the site alive. Client was basically hostage to the developer's CMS, and in today's low cost hosting and CMS plans available it simply made no sense paying these ongoing fees.

Aside from the customization part of Scenario #3, this is no different than Scenario #1 re hostage aspect.

Keep up the great content, always enjoyable!
Christopher Butler | July 26, 2011 11:19 AM
Joel: Thanks for reading! The whole question of portability was why I wrote this in the first place.

Peter: Indeed. But for sites with less complex functional requirements, some of the open source options can be quite good.

Ajay: Thanks!

John: The "my developer bailed" scenario is far too common, but it's a wonderful ongoing opportunity for commitment-oriented developers to step in and show these clients what a good relationship can be.

James: You're absolutely right: a hostage situation could be the result of working with a developer that uses a proprietary solution. But, that is certainly not the only result. In other words, it doesn't follow that every developer that uses proprietary tools holds their clients hostage. The missing link here, as anecdotal and aspirational as it may be, is, as you said "common decency." Of course, word-of-mouth and the power any of our clients have to share a complaint if they have one could do major damage to our ability to continue operating as we do. But we get continually positive feedback from our clients, who are very happy to remain in relationship with us after launch precisely because we have a very strong motivation to continue producing high-quality work for them. An unhappy client is extremely costly to a business—not just because they might tell other people not to work with us—but because serving them as long as they do remain would be arduous and unhappy for everyone. It would take more time, require much more free work, and create burnout among our staff very quickly. So, our motivation to continue high-level service is pretty holistic: it's good for our clients, and good for us.

Robert: Now that I've read your comment, I think it succinctly addresses James's point quite well. Thanks!

Josh: As I mentioned to James, this could happen, but it's very possible that it won't. It really depends upon the people involved. Thanks for reading!

Thanks, everyone, for starting up a great conversation!
Paul d'Aoust | July 26, 2011 11:45 AM
@Christopher, I appreciated your point about a proprietary CMS making things more efficient for developers, and therefore more beneficial for clients. I've often yelled at WordPress, thinking, 'this isn't the way I want it to work!' when developing a theme or plugin. Developing for a platform that I created would certainly be quicker, and it would allow for faster customisation to my clients' needs. This article may yet convince me to develop the CMS I've always wanted to develop!

I do, however, think that developing for a certain platform does give a bit of portability -- if you're used to coding for WordPress, for example, and you adopt a customised WordPress site from your client's last developer who went AWOL, it will take you a bit less time to figure out how everything worked, because you'll at least be familiar with the basics -- how to use the hooks, how to call a DB query, how plugins are structured, etc.
Abel Mohler | July 26, 2011 12:22 PM
One thing you may not have mentioned: Those developers who have actually participated in developing their own CMS, are going to be much more agile when it comes to actually customizing your website for you. How many Wordpress developers are there that can't customize something for you without going over the documentation every single time? I think the majority. Having a well documented system does not necessarily mean that development will be faster, it often only breeds the ability to find things in the documentation.

When you've actually developed and deployed an entire CMS by yourself, or with a team you work with daily (I've developed and deployed my own system entirely on my own), you know exactly how each part works intimately. Doing customizations are much easier when you've actually had a hand in putting the framework together.

As far as locking clients into using you exclusively as a developer, I don't see this as being as much as a problem as it seems to be. As a solution, I've offered to simply document the basics as to how my system works. Though the docs aren't done yet, any decent developer in the future could figure it out unless they're worthless as a developer in the first place. I put a liberal open source license on it, to give my clients permissive rights to use it as they wish. So while my system is sort of proprietary, seeing how I'm the only one deploying it, I'm using open source to make clients feel better about the freedoms they'll enjoy from using it.
Bill Wyman | July 26, 2011 12:24 PM
I think this was a well thought out piece and finally something that addressed the human factors beyond just the technology.

@James and @Josh, did you make it all the way throught the proprietary section? The author talked about a connection between commitment and proprietary tools, and made clear that his opinion was that proprietary developers are "very likely to show a strong, long-term commitment to their clients."

@Chris I think you elaborated well on that thread, so you're obviously not advocating for forcing clients to work with you ongoing.
Mahalie | July 26, 2011 3:27 PM
Love the illustrations but cannot agree with your points, all be them well laid. In summary: ditto "client hostage". Should a client of yours decide the relationship isn't working for them they'll be hard pressed to find someone to work on your proprietary system - much more so than even a heavily customized but already popular CMS with an active community behind it.

Cannot agree about open source vs. licensed platforms either - there is give and take there and it depends on site requirements and priorities. ExpressionEngine comes to mind, often a much better fit than WP or Drupal (but not always) and there's plenty of folks who can pick it up quickly thanks to public documentation (all platforms).

I can understand developing a bespoke site with a framework, you & your client benefit from a lot of heavy lifting being done already. Generally though, I find pushing your own private CMS totally self-indulgent.
Clay Schossow | July 26, 2011 3:31 PM
Great article. Really enjoyed reading it.

With the argument against open source, I think the fact that those systems try to do *so* much that it also ends up affecting the Basics that they do well at the beginning. Systems like Drupal that are focused on supporting so many thousand features often can fall out of date with making some basic things (i.e., controlling meta data) easy for end-users. So, the longer an open source system is in the wild, it starts to not only lack in those extended features that you identify, but also some of the basic ones.

@Abel great point in how a firm w/ their own CMS has already mastered it and can likely build custom features into it much quicker than a developer working on an open source or outside-proprietary system. I mean, if the firm built it, you can be pretty damn sure that they're experts in using it and customizing it.
Justin Roberts | July 26, 2011 3:57 PM
A very well written article (and comments) that covers the facts from different angles. I think all systems have their pros and cons but overall I agree with choosing the developer, not the CMS.

I have had many a conversation with clients about the benefits of using a 'in-house' cms over an 'off the shelf' product and it would have been great to refer them to an article like this ;) ... One sentence that sums up my view is: A propitiatory cms can be tailored to the project where as many open-source or licensed systems involve modifying the project to fit the cms.
Christopher Butler | July 26, 2011 4:08 PM
Paul d'Aoust: My advice would be to measure your inclinations toward R&D against the typical functional scope of the sites you're building. If you find that you're continually stretching what one open-source tool can do, perhaps it's not a good fit. But, it may be that another tool is a better fit, especially in comparison with starting from scratch and creating your own. Creating a unique CMS is a big risk—one I wouldn't really recommend to many unless you have plenty of cushion (cash or clients) to help you through that process. To your point: there are other CMS out there that might be a better midway between something basic and something proprietary.

Abel: I agree and hinted at that here:
...the ongoing value of the CMS is reflected in how it enables process efficiencies rather than specific functional outcomes. While we're continually thinking about how we can improve it and investing time to do so (we're at version 5.3 now), the competitive feature set and stability of our CMS is only one part of why we continue to use it rather than some other open-source solution. The other reason is because of those process efficiencies; they keep us very competitive on price. We can achieve big results for our clients without charging them the kinds of prices that might pay for CMS research and development because we expect them to remain our clients for a long time to come.
Bill: Thanks for the backup ;-)

Mahalie: Thanks, I had just as much fun making the illustrations as I did writing the article! As to your points, I think the hostage issue has been dealt with already. This could be the result of a proprietary solution being employed, but it's not a necessary one. The relationship will be the distinguishing factor. As far as how that plays out in reality, well, we've had hundreds of clients work with us in the past decade, none of which have decided to end their relationship with us and take their site, house it elsewhere, and have a new developer work on it. This is not because we don't allow it. We consider our clients the owners of their sites; they are free to leave and take them whenever they like. Sure, that would be difficult, but not impossible. Our CMS is developed to run on LAMP-friendly servers and is PHP-based (i.e. very common development environments). Few do this because they see more to our relationship with them than just hosting and implementation. They see us as strategic advisors that will help them continue to move forward and excel in a constantly changing technological environment.

Clay: I've noticed the same thing, as well as the point that I made in this article that many of them seem to be architected with an assumed developer/user paradigm—in other words, that the person creating the site is the same person who will be using/growing it long-term. Thus, it is easier to add pages and functionality ad-hoc than it is to create a "master-plan" and create something fairly sophisticated from scratch. I referenced a scenario in which creating a multi-field form can take far longer than it should because of this (add field -> name it -> position it -> save -> repeat).

Justin: Thanks for reading. I hope you have opportunity to use this article as a resource in the future!

Thanks, everyone, for your comments! Keep 'em coming!
Dave | July 26, 2011 4:40 PM
Chris,
As usual, a very insightful article that I enjoyed immensely.

Full disclaimer – I am a Partner of a boutique agency that has built a practice around an open-source CMS (Drupal).

You are absolutely correct that software development is a people business first – too often technology professionals lose sight of this. In fact, what I've found organizations value more than anything from professional service vendors that they have an existing relationship with is responsiveness or follow-up. The quality of code/product, pricing, experience, etc. is actually secondary to those who give the right amount of attention to a customer.

Historically, I've found that most organizations have already decided on whether to "go" open-source or proprietary. Rarely, are we asked to sell against a closed-source platform. The more likely scenario is that they've already selected Drupal, and the question becomes why should we hire you? At our firm, what I ultimately tell prospects is that what we are really selling is predictability – all firms have a reputation that can be determined by evaluating their track record.

Cheers,
Dave
Mediacurrent
Elliot | July 26, 2011 5:39 PM
Brilliant piece! First time I've seen CMSes compared based upon developer relationship strategy instead of specs. Verrry interesting!
Truper | July 27, 2011 1:32 AM
Very informative, thank you. Right now, I stand before the choice of CMS.
Alex | July 27, 2011 11:46 AM
Smart stuff as usual!
Jen Frears | July 27, 2011 7:17 PM
@Christopher (or maybe @Elliot?), do you have a specific recommendation for a CMS that a designer could use to build relatively basic sites? I've looked at Wordpress, Joomla, Drupal, and Expression Engine and I really don't know where to start. My experience is deisgn and front-end stuff, so I need something that is easy to use and doesn't require too much programming experience. What would you recommend?
Christopher Butler | July 28, 2011 11:00 AM
Dave: I'm glad you agree about people > technology. It seems like this becomes obvious the more immersed one gets in technology, don't you think?

I'd be interested to know how your agency has customized Drupal for use on your projects, too.

Elliot: Thanks, and thanks for linking to the CMS comparison site!

Truper: Glad you found this helpful; thanks for taking the time to say so. Good luck with your decision.

Alex: Thanks!

Jen: It really depends upon what kinds of websites you are looking to build, and, more specifically, what functionality they need to have. I intentionally avoided naming specific tools because I wanted to keep the comparisons general and scenario-based. But, we have done projects using Wordpress and Drupal and have found them both to have strengths and weaknesses that make them best suited for smaller scale sites (compared to our typical project). Both have the advantage of having a very large developer community and a plethora of plugins that expand the available functionality of core install. As much as a pro as that can be, it can become a con if the site uses so many plugins that they become a barrier to future upgrades of the core CMS. I'm inclined to not go much deeper than that, since I am by no means an expert in either. (Perhaps @Elliot or @Dave will weigh in.) Meanwhile, you could easily grab and install Wordpress and start playing with it—probably a bit more easily than with Drupal.
Vaughan | July 30, 2011 1:39 AM
A very informative and well debated article.

I'm definitely not in agreement with all things said but some great view points.

My main issue with what I call "Home Grown" CMS systems, the 3rd option Christopher describes, is the development budget and product road map is generally limited, which impacts on providing an extensive solution that covers the customers' needs now and in the future.

When you go down the path of developing features for a client's specific requirements, you develop a very focused feature, which may work for one client but not another. In the end you keep adding to the feature to suit each client's requirements, which leads to feature bloat. Also, as we all know the client's needs change as soon as the site goes live, which requires further development and more cost to the client.

With a commercial CMS, features are scoped for the needs all clients within the target market for the specific CMS. The depth of the feature development should (I say this loosely) cater for needs for the majority of the clients using the system.

What is also worth remembering… there is no one CMS that will fit every website requirement. Every developer has a bias towards a CMS solution so if you choose the developer first, you have limited your options severely. I firmly believe the decision is a combination of both. A CMS that fits the functional requirements of your website with limited custom development needed, and a website provider that will provide the level of service and on going support your organisation requires.
Allan Kent | July 31, 2011 4:53 PM
A really good article Christopher and some very interesting comments. This article really has gained some traction and it's good to hear some healthy debate.
As a website company, when we talk to clients we carry out an exhaustive scoping analysis to see what their requirements are likely to be further down the line, as well as their current ones.

Our CMS has a very defined road map, and comes ready to handle most requirements (for our defined target market) out of the box. Where there is a disparity, i.e. our CMS won't fit, or will require extensive customisation, we're happier to steer the client to another company - one that either has a tailor made solution for them (perhaps an area where they specialise in) or have a good development team able to handle bespoke customisation.

We have chosen one CMS only, prefering to be a specialist in one technology and for a clearly defined target market, rather than being a jack of all trades, (catering for a nmuch wider range of needs) but probably less well.
Christopher Butler | August 1, 2011 8:31 AM
Vaughan: I think you're right. If we were to create an entirely new CMS for each of our clients' sites, we'd have a hard time being profitable as well as useful to the client. Instead, we've developed one version of our CMS with an architecture that allows it to be shaped for each install—kind of a flexibility that allows for fine tuning where necessary. The other side of this issue—as far as maintaining a workable scope is concerned—is not so much a CMS issue as it is one of positioning and sales for our firm. At the outset, we have a pretty good idea of what kinds of projects make sense for us to do. That is informed by our expertise and our capabilities (partly, what our CMS can handle and what it cannot), but is far less a technological question than a strategic one. Which brings me to your last point, which, again, I'm completely on board with. No one CMS will be right for every project. That's why we might occasionally have to pass on a project (though that tends to happen more as a result of timing and price) as well as why we leave our CMS customizable by our developers. That gives us the right amount of wiggle room needed to create websites uniquely suited to their purpose for the specific kinds of clients we're best able to serve.

Allan: Thanks! I've been pleased to see such an interesting discussion come out of it, too. We're like you in that we spend a lot of time in the sales process making sure that we are on the same page as our possible-future-client in terms of scope, timeline, and price so that we don't violate what our CMS can do, but most importantly, what we can reasonably do. You are right on the money when it comes to the importance of specialization, though. The web is far too large and complex for any one company to be able to build any kind of website well!

Thanks for reading and commenting!
Nate | August 1, 2011 10:08 PM
Chris,

In reading @Vaughan's comment, I wondered how a small web shop can support both software development and website development? If you're not monetizing the product that your R&D team creates, then the project work you do would have to subsidize it, right? I'd have to guess that means that any project you do would have a higher price tag that if you worked with something off the shelf. I know you addressed this a bit in an earlier comment (how the efficiencies gained level it out) but do they really cover the cost of the CMS dev team? If you're ok with spilling the beans a bit, I'd love to hear more about how you guys pull this off.

Thanks,

Nate.
Justin | August 10, 2011 3:25 PM
Chris,

What a timely topic. At least the latest issue of Adweek seems to think so.

http://www.adweek.com/news/press/trouble-back-ends-133917
Christopher Butler | August 10, 2011 4:09 PM
Nate: That's a great question. Let me answer with a proviso: while I won't deny that in creating our own CMS we are developing a piece of software, I wouldn't call Newfangled a software development firm as well as a web development firm. On the other hand, much of what we create for our clients goes far beyond what the average person would think of when they hear the term "website," and pushes into application territory very often. With that in mind—especially that today's websites are commonly sophisticated applications of their own that gather, produce, and analyze data continually—I would say that Newfangled is a web development firm that creates functionally sophisticated work, including our own CMS.

All of that said, we don't spend too much time valuing the investment we make in maintaining our CMS against revenue. We periodically identify changes and improvements that we would like to make to the CMS and allocate time within our production schedule to do so—time which would otherwise be spent by the same developer(s) doing client production work. In some cases, we'll distribute the work across the team—something we did over the past year in order to make various changes that resulted in our last official CMS release (v5.3). In other cases, we'll map out changes and temporarily remove one developer from the production stream to focus on them as a project. We're taking that approach right now, as our Senior Developer, Dave Mello, is working on some major changes to our CMS that we hope to release later this fall.

Ultimately, this kind of investment isn't paid for by specific projects, but is worthwhile to us in preserving the efficiencies I mentioned already as well as keeping our CMS competitive in the perception of our clients and clients-to-be.

Justin: Thanks for the link. I hadn't seen that article but just skimmed through it. It's interesting to read through the many frustrated voices coming out of publishing, especially since it provides an explanation for something that many people have questioned in recent years—why big media publishing companies seem to be perpetually behind the times when it comes to translating what they do to the web. I especially liked the quote from a "former AOL employee," who said, "When you try to build a product that works for everybody, it works for nobody." That sounds exactly right to me!
Bill Marshall | August 15, 2011 5:24 PM
Excellent article and some thought-provoking comments, I'll be returning to it for a second read when I have more time. Can I just mention another aspect that is vital for me as both a developer and an SEO - most open source CMS and most commercial CMS that I've worked with have all been poor from an SEO perspective and require considerable customisation to overcome the issues they bring up. This is despite the so-called SEO-friendly add-on modules that proliferate in some of them - often they are worse than useless because the programmers simply don't understand SEO correctly.

I previously worked with a company that built its own CMS from scratch but sadly failed to make enough cash-flow from it and folded - I still maintain a couple of sites that use the system and only wish I could develop it further because while it wasn't perfect it was genuinely SEO friendly because I made sure it was by haranguing the programmers constantly!

This issue gets even worse once you bring in ecommerce as well - there are too many CMS that need an add-on shopping cart and there are too many shopping carts masquerading as CMS.

Definitely concentrate on finding a good developer (preferably without cash-flow problems!) but make sure they are experienced with SEO or can bring in an SEO who can work with them effectively.
Christopher Butler | August 22, 2011 3:13 PM
Bill: Thanks! I'm glad you enjoyed reading this, and especially the comments string, which has been fantastic.

I think you're right to point out the SEO-handling of a CMS as a critical factor. I've been surprised that some require plugins and other modules in order to frame the basic on-page factors that we've always maintained are essential for content creators to specify.
Sharon | September 13, 2011 2:41 PM
Thanks for the article. I read your blog often and find it valuable. However, I just had to chime in here.

I disagree what the following 2 statements.

* Developers using open-source CMS won't be as inclined to prioritize their relationship with their clients.
* Open-source CMS may do the basic stuff well, but they lack the functional sophistication required for enterprise-level websites.

We work with open source CMS platforms all the time and have for years. I dont have any major issues with proprietary content management platforms but I think it is incorrect to say that open source platforms lack sophistication for enterprise-level websites. Yes, they might not have everything that is needed right "out of the box" but they can be extended with modules and customization.

And, I do not agree that open source developers dont prioritize their relationships with clients. I think that depends on the developer not the CMS. We specialize in open source platforms, keep up with the latest releases and modules, and maintain long term relationships with all our clients - regardless of platform.

Thanks again for such thought provoking articles.
mobmoney | January 2, 2012 1:49 PM
Whatever you said about open source CMS and licensed CMS is true. However some conclusions at Open Source CMS are not true. One of them is about limited functionality of Open Source CMS. Nowadays wordpress is popular open source CMS which has a wide range of functionality with the help of various plugins.
Jackey Worden | January 27, 2012 10:02 PM
Choosing a content management system can be tricky. Without a clearly defined set of requirements, you will be seduced by fancy functionality that you will never use. What then should you look for? Well, it is Core functionality, The Editor, managing Assets, Search, Customization, User Interaction, Roles and Permissions, Versioning, Multiple Website Support, and Multilingual support. Consideration of features is an important part of the process of selecting a CMS, but it is not everything.
Jackey Worden | February 7, 2012 1:30 AM
I've never used a CMS written in Java, and none spring to mind. I would suspect that a Java CMS would have slightly more complex hosting and technical requirements, so it might not be suited for a non-programmer anyway. PHP content management systems are far more common and generally inexpensive to host too, so I'd suggest focusing your search there is your decide to host project yourself. Nice!
Ben | February 9, 2012 2:23 AM
I was just reading this site's article on Content Management Systems and since I didn't see it there I thought I would let everyone know about a new CMS called Directus that just launched. It is free, open source and definitely worth checking out.

http://getdirectus.com
John Dray | January 26, 2014 4:40 PM
The comment about 'no two websites' being alike is very true. I tend to use WordPress and often have to stretch it far beyond its basic functionality. I do like the use of plug-ins. I know it is not foolproof but I like the idea that there are lots of people using (and by implication testing) software, rather than having to go through quite such a rigorous development procedure for every line of code. Keeps costs down for my customers, too.

↑ top