The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

If you wrote the CMS then you ought to have a licence written up that describes how it can be used. Such software can be licenced in several different ways the most obvious two being single server use single payment for use for a set period and single server use annual payment. You could also either include or exclude any upgrades to the software that occur during the licence period.

There is plenty of other software out there that have licences along those lines - the vBulletin software this forum runs on is the most obvious example.

This question is not about what types of CMSes I should use, but rather how I can convince a client that implementing a CMS on the website (that I pre-built) will cost money.

What specific issues can I educate the client on?

How can I get future revenue (from the CMS) even though the client is updating the website's text and a few photographs?

Thanks

Loads of reasons;

1. The software may be "free" but you still have to spend time installing, and configuring
2. You still have to write HTML/CSS, graphics as with any other site
3. If the CMS uses addons you have to spend time researching to find the right one(s), then you hve time to install, configure and setup
4. The client gets extra features that they woldn't get on a static site. Those extra things all come at a price just like any other product/service
5. You may have to pay for certain commercial addons - adds to the cost

For future revenue you'll normally have script updates, bug fixes and security updates. These take to to download, and update the site. You can probably add a fee for support as well

I recommend you charge a one-off fee for the set-up and installation of the CMS, and make sure this is enough to reward you fairly for the time and effort you've put into it. Most clients will expect the support to be free which is fair enough, but place a limit on the number of queries a client make per month to try and encourage them to think about the issue in depth before they get in touch (rather than having them constantly flicking obvious questions at you!). Good luck.

typically free CMS are OS, meaning you aren't allowed to sell them or make profit directly from the CMS, so read up on the license that came with it. this is my understanding at least.

Many open source licenses allow you to redistribute, edit and sell the product for profit on the grounds that you keep the code in the open source platform, depending on what license you go with there are no grounds preventing you from making money through it. After all Linux has become a commercial open source licensee.

As for the product in question you could explain to them that there are maintainence costs (keeping the software up to date, debugging issues, ensuring the theme is customised to work with the CMS and such), all of this takes time and therefore money to implement because it requires much more work to customise someone elses code and work around their quirks than to provide simply static pages or dynamic pages around a system you produced and therefore can more easily know if updates will cause serious compatibility problems.

If it is software that you created then I would look at charging a yearly maintenance fee for the applications. Make sure that you add new features to it from time to time and accept feedback from your users for future functionality.

Most clients would rather pay a one-time fee for the CMS. Just build in the maintenance with the monthly hosting as one package price for instance.