 |
| Welcome
Sign Up Log On |
|
|
Messages: (28) 1
There's a story on inside.com right now that made me nervous when I first started reading it, then I changed my mind and decided that it's probably good for my company, Macrobyte Resources.
http://www.inside.com/story/Story_Cached/0,2770,6358_12,00.html
(Update 12/9/2000: Since inside.com switched to a subscription-based system, I can't provide a working link to the article: I'm not a member, so I don't even know what the new link is.)
The basic message to that article is that you'll be better off writing a custom Content Management System for your company than you will be if you use one from a vendor like Vignette. Those tools (pre-packaged CMS's) require so much customization that you end up writing most of a CMS anyway, they claim.
What I think the author misses is that it's a lot of work to write the underside of a CMS. Sure, Vignette's system has a lousy reputation among those who actually use it, mainly because their workflow system sucks... but what so many companies will find is that it's an awesome amount of work to try to develop the services that Vignette provides in your own in-house product... and then you have to try to support it. If IT staffs were static, that would be fine, but they're not.
Macrobyte makes Conversant, a product that we've been continually developing for 15 months now. We have most of the features of the "big guys", like Vignette's V/5 (formerly StoryServer) and Allaire's Spectra, and we do lots of things they don't do at all.
On the other hand, we're a very small company, and have the flexibility to move very fast in whatever direction we choose. We currently have a customer request for some advanced workflow features in Conversant. Some of those features are going into a custom plugin for this customer, and the rest is going directly into the product itself.
If Jimmy Guterman's main problem with the pre-packed CMS's is that the companies behind them move too slow when adding features or fixing bugs (or any other customer request), then we have nothing to worry about. Maybe he and Inside should try out Conversant!
[Top]
On the other hand, we're a very small company, and have the flexibility to move very fast in whatever direction we choose. We currently have a customer request for some advanced workflow features in Conversant. Some of those features are going into a custom plugin for this customer, and the rest is going directly into the product itself.What are "workflow features", if I may ask?
[Top]
Mark Morgan said:
>What are "workflow features", if I may ask?
Some examples:
There's actually more, but I don't want to spoil it all this early, and some of it is private to this customer's project. The point is, workflow features make it easier for a site with a LOT of content and a LOT of guests to have a standard workflow that takes content from assignment (to a writer or artist) through to publishing.
>I think you're downplaying the real value of Conversant. As you're always
>telling me (and everyone), Conversant is an groupware package with a CMS built
>on it. But you can build anything on it, groupware speaking. It's the most
>important thing about Conversant: if a company's needs change, so can
>Conversant. Say Inside builds a custom CMS. Can they then use the same
>tools they sweated over to manage group scheduling? No--time for another
>custom tool for that. Hope the programmers for the original tool are still
>around... And so on, one custom tool at a time. As the staff changes, each
>new person has to be brought up to speed with the new tool. Ugh!
I certainly don't mean to downplay the importance of Conversant, but you have to get beyond the "coolness" aspect of it and actually get some work done, at some point. Conversant as a groupware platform is useless if the applications we build on top of it are not (or can not be) as good as comparable apps from other companies.
If a potential customer is looking for a strong Content Management System, then telling them about Conversant's event calendar isn't going to cut it. They're interested in Conversant as a CMS, period. The fact that they can use it for more than that might be interesting, but if we're going to compete then we have to do it on implemented features. It's like operating systems: hardly anybody chooses their OS based on how easy it is to write apps for it. Instead they choose their OS based on power or ease of use, and the apps that are already written for it.
>Disclaimer: I'm happy being able to program my watch correctly, and I haven't
>worked in a normal corporate environment in years. But it's got to be easier
>to build everything on a standard system than to custom design, and redesign,
>all the time.
Sure, that's true. However, the point of the article was probably in the last paragraph, where he said that everybody should be using JSP to build their CMS's, as JSP is already open-source. My point is actually the opposite: I don't think most companies want to build their own, but rather that they have a right to expect their vendors (Macrobyte) to work like crazy to provide them with exactly what they need. That's the benefit of our plugin architecture... we can add customer - specific features very quickly.
Great comments, Mark, thanks for taking the time.
Seth
[Top]
I need to be more specific with my first question, though. I don't work at all in corporate America. What is "workflow"? Mark understands not...
[Top]
Mark Morgan said:
>I need to be more specific with my first question, though. I don't work at
>all in corporate America. What is "workflow"? Mark understands not...
Work flow is the specific process that one uses to complete a repetitive job. It's the series of operations that are performed to complete a task or produce a product.
In the online publishing world, it looks something like this:
This work flow is almost identical to the dead-tree magazine/catalog publishing work flow.
So, another term for "work flow" is "work process".
Seth
[Top]
[Top]
And, in my opinion, that's just the tip of the iceberg. The important point is that Conversant is designed to be customized and added-on to and plugged-in to. Nothing has to be hacked in. As you mention, it's easy to add customer-specific features... easy for Macrobyte to offer that service, and even easy for the customer to do that on their own. It's straightforward to see where and how various features interact. In contrast, hacking Vignette (or any other monolithic CMS system) looks like a slow and ugly option that is difficult to maintain. And apparently, it doesn't just look like that... it actually is.
But I think the question was not "Vignette vs. Conversant" as much as "in-house coding vs. Conversant." If a company invests in Conversant, they get a lot of "the basics" done for them... user/group management (which can be extended if so desired), database connectivity (ditto), ownership and privilege models (ditto) a plugin architecture, and a substantial set of features/tools. Instead of developing something entirely from scratch, the company can develop only what additional features or customizations they need... or they can utilize plugins created by Macrobyte or by third parties.
Given those options, I can't see how developing in-house code from scratch is very effective. It's much more sensible to extend a vendor-built system, and the modular framework that Conversant offers is a good choice for that system.
[Top]
That's really the key to me. Right now I'm in charge of selecting and putting in place a new mid-level ERP-type accounting/inventory/order processing system for a company. The key selection point for me is customizability. I don't want to write a double entry accounting program. I don't want to write an inventory control application. Those are relatively quantifiable areas that have already been address by others, why re-invent the wheel.
I do, however, want to write a lot of the code to manage sales order processing, customer relations, project management that represent the key competitive advantage of our business...and I don't want to be tied to down by what I invest in for the pre-built things.
Conversant has those traits for a groupware/communication tools...a sound archetecture to build on. I seriously wish there was "conversant" in the mid-level ERP market. I'd buy it in a minute.
g.
[Top]
"... the point of the article was probably in the last paragraph, where he said that everybody should be using JSP to build their CMS's, as JSP is already open-source. My point is actually the opposite: I don't think most companies want to build their own, but rather that they have a right to expect their vendors (Macrobyte) to work like crazy to provide them with exactly what they need. That's the benefit of our plugin architecture... we can add customer - specific features very quickly."
The importance of this point should not be underestimated. I've been on board with Conversant since the very beginning. While I was impressed with the features and ease of use of Conversant (whether you needed it as a CMS OR as a Groupware App.) I've been much *more* impressed by the speed and ease with which new features (requested or internally devised) have been added to the product. I have closely observed how wellthe team that produces Conversant listens to its customers as well as to each other.
But getting back to the more substance of Seth's comment, he's correct to credit Conversant's plugin architecture as the 'killer app' of the Conversant product.
It's almost as if, in the world of CMS's, Conversant's motto is: "If you can dream it, you can do it".. (after we write this little plug-in in record time...)
J.
[Top]
Hmmm...I read the same article last week and thought "This is good news for Seth." Why?
First the article could be boiled down to this: Vignette stinks. If your choice is buy Vignette or write your own system, you'd actually be better off writing your own CMS software than waste your time with this (does Vignette have *any* satisfied users? All I see on the Internet are people dogging it, especially designers and developers who have had to try to work around Vignette's limitations to make their site work like they want).
On the other hand, the article's suggestion that companies have their IT Staffs develop a proprietary CMS isn't going to fly outside of maybe large media companies. The IT turnover is a huge problem. I worked at a Fortune 500 pharmaceutical firm last year and they were constantly running across legacy code and applications written by people who had long since left the company, and of course the emphasis is *always* going to be on getting the software up and working and maintained and not on documenting the application when you're working at a non-computer firm (the attitude being "we're in the business of making drugs, not writing software documentation.")
This makes about as much sense as writing an article pointing out that pretty much all of the enterprise-scale mail solutions have serious drawbacks, so companies should just develop their own system.
The opportunity cost to developing large scale software like that is just too high. Maybe Time, or the Tribune want to do this, but most companies know that once they step outside their core competencies they're in trouble.
What this does do is create a huge opening. Take the company I worked at -- rather than develop a proprietary system, what we did was take maybe 10 or 15 different products and try to interface them in this clunky system. It was a lot like my old web site -- you had a few CGI programs to handle some stuff, you had an enterprise-level meeting planning software that could write to HTML, there was a very hard to use interface so you could update meeting plans via email, but all the project pages were mocked up in Dreamweaver or Frontpage. And maybe three or four people out of 20,000 actually understood how the whole system worked.
I think the failure of Vignette is a perfect opportunity for a company like Macrobyte. I can see how a souped up version of Conversant would really solve a lot of problems we were always running into trying to integrate people and projects, much of it caused by having to use so many different systems.
The primary difficulty I imagine you'll have is on the marketing side. I'm sure you read them, but if you flip through the various IT-oriented magazines it's just one after another product promising to solve all of your web problems. The market is so saturated with products, it's going to be a challenge to get noticed. But once you can get the feature set down and get in front of customers, I don't think you'll have that hard a sell.
[Top]
A picture of the Conversant team, either all together or a head shot of each member with the caption "These guys write it" and then a picture of that customer at Company X in front of his building with the caption "These guys use it"...
Conversant: Top drawer, user-friendly groupware and content mgmt. featuring the most customer-responsive development team in the business...
:-)
[Top]
However, most sites run on a smaller scale. I have successfully used homegrown CMS's for years, based on nothing fancier than Perl, XML, and consistent habits of data management. There's definitely a market for lighter-weight implementations of what Vignette does. Zope, for example, sees a big opportunity there. One of its big strengths is delegation of authority down a tree of objects. Frontier/Manila now does a very nice job of basic news-oriented publication workflow. I don't know much about Conversant yet, but I've seen enough to suggest that it's a capable toolkit for custom CMS and workflow. Every CMS/workflow situation is different, so there's a huge need for customized solutions. That means opportunities in this space for everybody: Zope, Manila, Conversant, and players yet to be named.
[Top]
Jon Udell wrote
>However, most sites run on a smaller scale. I have successfully used
>homegrown CMS's for years, based on nothing fancier than Perl, XML,
>and consistent habits of data management. There's definitely a market
>for lighter-weight implementations of what Vignette does. Zope, for
>example, sees a big opportunity there.
[SNIP]
>Every CMS/workflow situation is different, so there's a huge need for
>customized solutions. That means opportunities in this space for
>everybody: Zope, Manila, Conversant, and players yet to be named.
Jon,
First, thank you for taking the time to comment, I really appreciate it. It's clear that a number of the messages on this site are from Conversant users and protagonists, and it's helpful to have a third-party opinion set down for consideration (especially one from the author that inspired us as we wrote Conversant!).
Still, though, you left one question open, at least in my mind. If the entire issue were boiled down to a single question:
Should my small-to-medium-sized company use our on-staff resources to build our own Content Management System from scratch, or should we try to find something "prepackaged" that meets most of our needs and then customize it to get the last 15%?"
... what would your answer be? That's the real question being decided here.
I realize that there isn't a single answer that's write for everybody. Still, if anyone wants to try to answer that question, it's what I'm really looking for.
Seth
[Top]
The problem with tools, somebody once said, is that they do as much to you as they do for you. For somebody like me, that's true. I can't imagine any CMS doing just what I want out of the box, and since my needs are modest, I'd just as soon do stuff myself and get it done the way I want.
OTOH if I were doing a heavily dynamic news-and-views site, with new stuff flowing in daily (rather than monthly, as in the case of my magazine site), and with discussion linked to the produced content, then I'd be much more likely to buy, rather than build, a discussion-capable CMS. At which point, I'd be looking for something that was:
- inexpensive
- did the basic stuff out of the box
- was clearly capable of anticipated necessary customization
[Top]
Each application has individual needs, but also has needs it shares with many other applications, as Greg pointed out. It makes sense to share the development costs for the common stuff with as many people as possible, since that means less money for a superior product. The unique stuff will need to be custom-written. Going with a platform that is easily extensible, and which is ideally open-source, gives the most flexibility. Paying for the time of people who are already intimate with the platform will usually be cheaper than paying for your own people to get up to speed on a new platform, or to go through the trial-and-error of writing a system themselves and then building upon it.
In much the same way that it's far cheaper to buy Word and add custom functionality with VBA than it is to develop a word processor yourself, if a CMS system already exists that does most of what you want and can be customized to do the rest (and they don't gouge you like Vignette does), any project of a moderate to large scale should come out cheaper using the product than building it oneself.
Sean
[Top]
Jon Udell said:
>As to build vs buy, it depends on skills, inclinations, and the nature of the
>site. I run a magazine site that's doing about 300K pageviews/month using
>nothing fancier than a Perl script. But, this is possible because I've trained
>people to export the magazine content into a prescribed XML format that I can
>easily parse and repurpose. Behind the scenes, there's a very simple Zope
>application that editors use to post work in progress -- which must
>unfortunately go through a Quark production process (it's a paper magazine,
>after all) and then get exported for the Web. No real workflow, just a
>tree-structured readable/writable repository that supports HTTP file upload of
>text files and images. But it works well enough for a small staff who would
>otherwise do everything in email attachments.
OK, I definitely agree that if the needs of the site are very modest, and are not likely to expand significantly, then something very simple like what you've described will work as a homegrown CMS.
>The problem with tools, somebody once said, is that they do as much to you as
>they do for you. For somebody like me, that's true. I can't imagine any CMS
>doing just what I want out of the box, and since my needs are modest, I'd just
>as soon do stuff myself and get it done the way I want.
Sure, as a programmer I have to agree with you. An established site with existing workflow and production requirements will (practically) never have its needs met by a product exactly as it ships.
If we make that a "law", a rule to guide how we consider this issue, then we're really saying that a pre-packaged CMS is worth buying if it offers:
(In other words, since a pre-packaged CMS can never be everything that you need, you must make the above list part of your requirements.)
That last point is important, because it includes some hidden details. If the pre-packaged software is hard to customize, then the cost of customization is higher. Also, if the cost is exceptionally low, and the software is extremely easy to customize, then the first two points can be adjusted.
Of course, these are still just general guidelines. If the system is incredibly easy to customize, but includes very little of what you already need, and your needs are significant, then the system won't do... it's too much like starting from scratch.
Art Pena made some very good points in his posting last night: don't reinvent the wheel. Find a good product with a lot of promise, and backed by a development company or group (if it's open source) with a good attitude towards improving the product to meet the customer's needs, and you'll almost always be in a better position than you will be if you write it yourself.
I'd say that applies to your magazine site, too. Unfortunately, your site's needs were so small that you'd probably not find a CMS cheap enough to justify buying. You could always consider a CMS ASP! (hint, hint)
>OTOH if I were doing a heavily dynamic news-and-views site, with new stuff
>flowing in daily (rather than monthly, as in the case of my magazine site),
>and with discussion linked to the produced content, then I'd be much more
>likely to buy, rather than build, a discussion-capable CMS. At which point,
>I'd be looking for something that was:
I appreciate the mention of "discussion linked to produced content", but I have to point out that at this point, that's not really the point of Conversant's discussion tools, which are intended to be the core of the CMS, the system that manages the content, rather than a tool for managing a very active public discussion forum. Hundreds of messages per day are fine, but the very busy sites that get thousands of messages per day would probably overwhelm Conversant's current system (though we've never tried it, and so I probably shouldn't say that).
>- inexpensive
>
>- did the basic stuff out of the box
>
>- was clearly capable of anticipated necessary customization
I realize that I said the same thing earlier in this message, but I wanted to point out the importance of using that sliding scale. Also, where you say "the basic stuff," I say, "percentage of your immediate requirements".
Still, I think we agree on most of this. Now we need to convince the publishers to stop designing their own systems and go with something that's already written and has a future, like Conversant, Zope, or Manila (all of which have very different strengths and lots of room to grow, IMO).
Seth
[Top]
Zope is much more interesting, but the technical stuff to install and maintain it is way over my head. If I were going to run a Zope system I'd have had to go with an outside consultant to set it up for me. I'm very impressed with some of the applications built on top of Zope, but the learning curve seems awfully high compared to Manila or Conversant.
What I'm really surprised at is that there aren't more CMS systems aimed at medium and small web site operators. Aside from the Open Source ones like Zope there's Manila, Conversant and little else until you're ready to committ a lot of money. I know I'm not the only one out there with a site getting 2 to 10 million page views a year saying "I wish there was a better way to run my site".
[Top]
Brian Carnell said:
>I know I'm not the only one out there with a site getting 2 to 10 million
>page views a year saying "I wish there was a better way to run my site".
Do you feel this is a question that we've answered, or is it still something you're asking?
Seth
[Top]
"Do you feel this is a question that we've answered, or is it still something you're asking?"
I think you've got small to medium stuff covered -- there are still a lot of features I'd like to see and that you've already mentioned are coming, but I think Brian Andresen really hit the important point when he said in a slight different context, "It's straightforward [in Conversant] to see where and how various features interact." The CMS side of Conversant also makes it a lot easier to get my head around some of my larger sites -- I am doing things in Conversant I never even thought of doing with my static site simply because they would have been next to impossible to do. (I still think a comparison chart of CMS system would really help potential customers).
It's very nice to have Conversant do all the behind-the-scenes grunt work so I can concentrate on other things.
One of the things I don't get is what Andresen means by Conversant being modular. When he starts talking about plug-in architecture he kinds of loses me. Is he saying that there is something equivalent to an open API that third parties can write external software to interface with Conversant?
As for the GroupWare side of things, I am definitely looking forward to see what sort of tools you have planned. As I've said before, my primary motivation to get away from a static site was having hundreds of users posting all sorts of incredible stuff and having no way of doing much with it. I like the fact that with Conversant if somebody writes an essay or posts a news item I can promote that to the web log or bind it to a file, or give some of the more knowledgeable users web logs of their own to talk about specific topics.
The next step is planning and carrying out projects and the people who visit my sites are always putting forward proposals for projects but there's never been a way for them or me to organize that into something, evaluate whether it's really worth doing and then carry it through.
[Top]
That's because you've not seen Conversant's code guts. :-P One of the great things about the way it's built (and for which Brian was largely responsible) is that it's designed to be very, very extensible without breaking any existing code. You can create a "plug-in" for Conversant that will tap into, change, or override any aspect of its functionality. If you want that plug-in in your system, you can just drop it in. If you don't want it any more, it's easy to pull it out. The Weblogs, HTML Enforcer, and all of the interfaces (WWW, Newsgroup, E-Mail) are all plugins that can be included or not without affecting Conversant's basic functionality.
The API for plugins isn't open yet, but I think the plan is still to make it open fairly soon, which will allow third-party developers and Macrobyte customers to add whatever plugin functionality they want to.
Sean
[Top]
Brian Carnell said:
>>>I know I'm not the only one out there with a site getting 2 to 10 million
>>>page views a year saying "I wish there was a better way to run my site".
>>"Do you feel this is a question that we've answered, or is it still something
>>you're asking?"
>I think you've got small to medium stuff covered -- there are still a lot of
>features I'd like to see and that you've already mentioned are coming, but I
>think Brian Andresen really hit the important point when he said in a slight
>different context, "It's straightforward [in Conversant] to see where and how
>various features interact." The CMS side of Conversant also makes it a lot
>easier to get my head around some of my larger sites -- I am doing things in
>Conversant I never even thought of doing with my static site simply because
>they would have been next to impossible to do. (I still think a comparison
>chart of CMS system would really help potential customers).
Could I trouble you for examples of both of these things? I know what features you've requested on the support site, but I don't think any of them fall outside the range of "small to medium stuff". What big features would you like, that we don't already have?
Also (and it might be more fitting to post this on the support site), I'd love to know how you're using it, what things you're doing with it that you wouldn't have attempted on your static site.
>It's very nice to have Conversant do all the behind-the-scenes grunt work so I
>can concentrate on other things.
Yes, I have to agree with that, since it was part of the idea in the first place. Conversant's raison d'etre: to do the behind-the-scenes grunt work. ;-)
>One of the things I don't get is what Andresen means by Conversant being
>modular. When he starts talking about plug-in architecture he kinds of loses
>me. Is he saying that there is something equivalent to an open API that third
>parties can write external software to interface with Conversant?
I can't really answer this any better than Sean did.
>As for the GroupWare side of things, I am definitely looking forward to see
>what sort of tools you have planned. As I've said before, my primary
>motivation to get away from a static site was having hundreds of users posting
>all sorts of incredible stuff and having no way of doing much with it. I like
>the fact that with Conversant if somebody writes an essay or posts a news item
>I can promote that to the web log or bind it to a file, or give some of the
>more knowledgeable users web logs of their own to talk about specific topics.
We need to get a few things done first, but eventually we're going to post a document that explains where we want to take Conversant, what new features we're planning for it, and what new applications we're going to develop on top of it. It is also still in our plans to make the core of Conversant available under an Open Source license, along with a few very basic plugins to act as "demonstrations" to any developers that take it up.
>The next step is planning and carrying out projects and the people who visit
>my sites are always putting forward proposals for projects but there's never
>been a way for them or me to organize that into something, evaluate whether
>it's really worth doing and then carry it through.
Seems that many of things you might like to do... can already be done with what's been made available to you. Again, some examples of what you want to do (not specific feature requests) would go a long way towards helping us push Conversant in the directions that customers want to go.
Seth
[Top]
What I think they miss is that it's a lot of work to write the underside of a CMS. Sure, Vignette's system has a lousy reputation among those who actually use it, mainly because their workflow system sucks... but what so many companies will find is that it's an awesome amount of work to try to develop the services that Vignette provides in your own in-house product... and then you have to try to support it. If IT staffs were static, that would be fine, but they're not.
That's the point. In my opinion, the questions to ask when you consider developing your own CMS are: "When do I want to start using it?", and "How much resources can I put into it?".
If you've got unlimited resources and don't plan to use it for months, then you could go for it. Develop a system that is built from the very beginning to be very easy to maintain and improve (using adds-on or plugins). And make sure the code is well documented. Also make sure your system is less expensive and is better (or fits your needs better) than every concurrent third party product (because you don't want to spend more to get less).
OTOH, it's almost certain that if you try to build such a system little by little and following your needs, you'll end up with a lot of pieces hacked together. Soon or later, that will be hell to maintain and even worse to upgrade.
In fact, the better question may be: "Will I get soon a better product than what's on the market, and will it cost me less?".
[Top]
IT turnover is a real and constant event in the life of any size firm with an IT department. There are more job openings than there are technical people to fill those positions. One of the direct results of this turnover rate to in-house projects, as Mr. Guterman advises, is that inevitably there will be subsystems or entire applications, a package, used in the custom solutions that will have no documentation, no design specifications, and no one with the specific knowledge to maintain that package. A commercially developed application short-circuits this problem.
The developer of a CMS, or any application, has one primary mission during his product's life cycle, that the application is maintainable by his current staff. The average corporate IT department can't maintain the focus of resources necessary to ensure the success of that mission.
Also at odds with the recommendations of Mr. Guterman's article is the cost of developing solutions from the ground up. Why redesign and build the wheel when you can go to your local automotive parts store and buy a wheel? That wheel represents significant expenditures of resources to its maker: the design, testing, and manufacturing. This is a lesson learned in the days of mainframes as well, the cost to develop from scratch is significantly higher than buying off the shelf or merely customizing. A custom solution to the CMS problem represents a significant investment, often more than your average small company can afford to make for an item outside it's realm of expertise. Not to imply that a custom solution is not a viable option for a company. However, Mr. Guterman fails to fairly express these costs in his article.
So the decision any company has to make is which is the best for their business; write 100% of an application, i.e. reinvent the wheel, or perform 15-25% customization to an already existing tool, i.e. add chrome to the wheel. Again "Why reinvent the wheel?", is the question I'd ask.
Use a product someone else has developed. They've taken the time to think out the problem. And spent the time developing a solution to that problem. In addition to having spent on the staff and their tools to develop the product. And after all these significant investments, the developer of the product has a self interest motive to ensure the CMS continues to expand in capabilities.
[Top]
I don't have much to add to what you've said. That was a very good recap of most of the issues that a company should consider before building their own CMS (or any other application). I especially like the reminder that these issues were decided years ago, when big-iron went (mostly) the way of the dinosaur.
The one issue you didn't touch on (at least, that I've thought of since reading it) is the cost of maintaining the software in the long run. Things like:
Of course, those costs are more hidden, and less likely to be included in a cost-benefits analysis before the project is approved (and the problem is worse when it's the IT department that does the analysis, especially if the IT department WANTS to write it... their numbers will be skewed)
Seth
[Top]
If you want a standard car to drive to the grocery store then you go to a lot and you buy one. If you want to win a race you will at least replace some of the standard parts with others, if not build the whole thing. Notice that there is a continuum here from, for example, adding things to the standard engine, through replacing with another enigne from another manufacturer, to building a custom engine yourself.
This is the way I would like CMS to work, each would be a semi custom solution built from standard components. Yes, no one builds a wheel from scratch (unless for cycling :) anymore, but people do like to be able to replace their current wheels with differnt wheels from other manufactures when they need to or want to.
If you want a standard web site then buy a system and make you site work the way the system supports most easily.
If you want your site to work in a particular way, and you can't find a system that supports that out of the box, then build your own system from standard components.
[Top]
On Thursday, July 13, 2000 at 6:26 PM, Alex Moffat (alexmoffat@yahoo.com) wrote:
>I think the wheel analogy is interesting but can also be looked at another
>way.
>
>If you want a standard car to drive to the grocery store then you go to a
>lot and you buy one. If you want to win a race you will at least replace
>some of the standard parts with others, if not build the whole thing.
>Notice that there is a continuum here from, for example, adding things to
>the standard engine, through replacing with another enigne from another
>manufacturer, to building a custom engine yourself.
>
>This is the way I would like CMS to work, each would be a semi custom
>solution built from standard components. Yes, no one builds a wheel from
>scratch (unless for cycling :) anymore, but people do like to be able to
>replace their current wheels with differnt wheels from other manufactures
>when they need to or want to.
>
>If you want a standard web site then buy a system and make you site work
>the way the system supports most easily.
>
>If you want your site to work in a particular way, and you can't find a
>system that supports that out of the box, then build your own system from
>standard components.
Alex,
I agree with everything you've said except for one point: you're not really stating the other side of the "wheel" argument! :-) The point was that you can get most of what you need from the off-the-shelf packages, and then build the other 10% - 20% yourself, which is far easier and less expensive than building the first 80% - 90%. (If this all works out the way we hope it will, those other parts that you need will be available from other vendors, so you might just swap parts instead of building anything at all.)
Those companies that feel the need to build their own system entirely from scratch, right down to the lowest level of the code, are usually making a mistake IMO. More often than not, I think they do that out of frustration because the "big guys" (Vignette, etc) aren't meeting their needs and are very hard to customize... and if the "big guys" aren't meeting their needs, how can they expect some small-fry like Manila, Zope, or Conversant to do the trick?
What they don't realize is that (to varying degrees) all three systems were built with extensibility and customization in mind.
Speaking from Conversant's perspective (which is my job <ahem>), customization was one of our main goals when designing the entire system, and we *know* that it could be the heart of virtually any groupware product, including a super-CMS for a very busy site, a group calendar app for a multi-national corporation, or a project manager and customer-relationship-management-system for someone else. So, getting back to your analogy: if something in Conversant doesn't work the way you want it to, replace it with something that does. You can have that semi-custom (or fully-custom) solution that IS built with standard parts, all built to a wonderful API (Covnersant's heart of Gold).
Seth
Seth Dillingham seth@macrobyte.net President, Macrobyte Resources (860) 572-0244 ======================================================================== 76 Dogwood Lane http://www.MacrobyteResources.com/ Mystic, CT 06355
[Top]
> This is the way I would like CMS to work, each would be a semi > custom solution built from standard components. Yes, no one > builds a wheel from scratch (unless for cycling :) anymore, > but people do like to be able to replace their current wheels > with differnt wheels from other manufactures when they need to > or want to.
I entirely agree with what you are saying and to a large extent you are defending instead of defeating my point. However, what Mr. Guterman is suggesting in his article is that everyone builds that wheel from scratch instead of buying a ready-made wheel if at all possible. Yes, perhaps what the company needs isn't available and must be made from scratch. And that is a perfectly acceptable solution to the problem if custom work is the only option available. However, it is folly to insist that every company that wishes a CMS should build it's own CMS from the bare ground up.
There are CMS systems out there that allow customization to varying degrees. In a perfect solution this flexibility would be infinite allowing for every customer to make the off the shelf system work to his exact specification. Whether those components are company brewed or third party is almost irrelevant. Returning to your analogy, where the wheel comes from is almost an insignificant detail if all you are doing is replacing that one wheel not designing and building the entire car from scratch.
Building any software system from nothing is an expensive and time consuming task best left to someone who has the interest and self motivation to risk their resources on the venture. A CMS is a large application, starting from just the UNIX file system and some other tool to a working CMS is not as trivial as Mr. Guterman would have us all believe. If developing a good CMS were so trivial then the big guys he is complaining about would have solved the problem to everyone's pleasure instead of everyone's irritation. Again, Mr. Guterman is not suggesting take a CMS and modify it to your needs but instead he is advocating take a file system or database and build a CMS from there. The storage of the data is the most trivial aspect of a good CMS. How to get that data to a published page is the hard part. Mr. Guterman fails to mention the enormous cost and risk involved in developing that one "little" hard part.
I too wish that it were possible to buy a base system and just add the pieces, as you need them. In point of fact no CMS available currently can do what we are wishing for. However, there is a CMS that brings us closer to that dream than any other system currently available but even that CMS doesn't take us all the way to our dream. Perhaps for no other reason than a cadre of third parties building all the different parts we'd need is not currently available. Returning to Mr. Guterman's article, he isn't advising such a course as we are dreaming of.
A CMS does more than just organize the pages, like a file system does, and determining how they are rendered, as JSP does. A good CMS allows the building, management, editing, editorializing, and organization of those pages. One tightly integrated solution to this problem is infinitely better for the body corporate than a spattering of applications and technologies. And that is where we return to which course do we take to achieve that tightly integrated system? Mr. Guterman believes that there is no system available that would allow any corporate site to fully realize it's vision for what a CMS should do. So building the system from scratch, is Mr. Guterman's suggestion. I propose that buying the system off the shelf and customizing to your needs is the less risky and most cost effective choice for any company except the massive corporation with a large IT resource.
Where perhaps I would agree with Mr. Guterman is that the large CMS's he mentions in his article fail to deliver on their promises. However, that is not the fault of all CMS's but of those CMS's. I strongly believe that there are CMS's currently available that would appease the needs of many companies.
[Top]
<- Previous Thread:
Sluggy Makes the Grade
Next Thread: ->
Ugly Secrets, Continued
Until August 31
My Amazon sales
benefit the PMC
Apr 1 - Aug 31
Ad revenue
benefits the PMC
|
TruerWords
is Seth Dillingham's personal web site. More than the sum of my parts. |
