Since you and I are discussing Vmix elsewhere, I'll leave them out of the thread here.

But I am not sure there is an either-or here. For instance, in the implementation of Drupal, here is an open-source product we don't need to pay for. It's wonderful. Also, it has a steep learning curve (good luck explaining "blocks" to anyone with no CMS experience) and half the materials are either incomplete or written by someone for whom English is a third language.

While we have in-house Drupal experts, it will behoove us to bring in or outsource — as needed — teams of Drupal developers to help us customize the site for our needs.

It seems that's the way a LOT of successful dot-coms are doing business. Huffington Post may have been built on Movable Type but it hired a bunch of Drupalites to develop some other stuff for them.

I don't want to get hung up on a Drupal discussion so much as point out the model: open-source + as-needed support = flexible, continually upgraded software that we can tailor to our needs while taking advantage of innovations from the worldwide developer community.

It's actually an analogue to what we need to do editorially as well.

Aaron,

I'm with you on Drupal. I've spent a ton of time teaching myself the in's and out's of Drupal. I'm trying to learn PHP on the side to make myself more effective, but that isn't easy for me. We run some successful Drupal sites at the Tri-City Herald, but they're vanilla in nature, nothing like the Moms sites that are rolling out at several MNI papers in Drupal.

In the past, we were promised that MI would hire some Drupal experts who would be able to assist the papers with theme development, etc. I don't know that it ever happened. We just went ahead and moved forward, doing what we could with the tools we were given. I think a lot of plans were put aside after the Knight-Ridder purchase.

Fortunately, Drupal doesn't necessarily fall into the category of things we paid for but didn't know how to use because it is open source and, thus, free. Switching to Solr for search has been a great move, saving the company big bucks and, I hear, providing us with better search functionality.

You are right on about the need to look closely at open-source software. In fact, it would seem the Red Pill project has an open-source spirit to it.

I will be interested to see what happens to our Drupal installs in the next couple of years if we stick with Pluck or develop similar functionality within the pubsys (like MIC).

A few facts about Verve:
1. Verve provides one thing we cannot provide: placement on the "deck" of Verizon and potentially other carriers, which improves our sites' chances of being seen on smaller mobile devices that are used primarily as telephones. On those devices, the carriers make it very cumbersome to get to a site that is not on their deck.
2. Yes, the Workbench can generate WAP pages, but prior to the the Verve agreement, we could not find any sites that actually were doing that.
3. We don't or shouldn't use Verve for large mobile devices that have more robust browsers, such as Blackberries and iPhones. That should be done in the Workbench. Unfortunately, I don't know of any sites that have done that, either.
4. I can't discuss contract terms in this venue, but suffice it to say that the Verve relationship is net positive.

Mobile capability should be part of the reference site. I'm surprised to see that it's up to affiliates to develop mobile versions of their site for Blackberries and iPhones - it's easily the fastest growing sector of the web today and must be a common request.

This is an area where McClatchy could benefit from economies of scale in rolling out a platform that accomplishes most of the functionality, while allowing affiliates to further customize it to suite their own needs. Doesn't it seem like a big waste of resources to have each affiliate roll their own, building it from scratch? That's an enormous amount of duplicated effort.

@Justin - Check out the discussion on delivery methods. https://mcclatchynext.pbwiki.com/New-delivery-system(s)

@James Calloway point #1 I find hard to believe. Those who want to read stuff on their phones can and will find what they need. Deck placement is irrelevant. That thinking reminds me of the default MSN home page for Internet Explorer. It doesn't prevent people from getting anywhere on the internet. I've been reading mobile content for close to 8 years on various phones with BellSouth/Cingular/AT&T and Sprint. Rarely was the content I've consumed located on a carrier deck. Maybe Verizon is different.

Back to the topic, I was amazed when I heard about our new contract with weather underground. This was one of the first tasks I was given when I came on board at the Bee. Basically we had no money for weather information, so I was asked to see about getting it directly from NOAA. I quickly learned that NOAA has a SOAP API and after a few hundred lines of code and a week or two I had a great perl/XSLT weather script for forecast information, current conditions, plus current satellite and radar images.

This script held solid for at least 2 full years and one day I was asked to work with weather underground to replace our pages with their content rather than NOAA's. So we worked together and got that done, but I couldn't help but wonder how much money we spent to get the exact same information we already had. I'd be willing to bet that weather underground uses the same SOAP API to get the exact same data from NOAA. Sure they have a few extra features and up-to-the minute current conditions, but I think if people were really interested in the kind of detail, they wouldn't be getting their weather on fresnobee.com anyway. But maybe I'm wrong, and I did get some cool weather underground swag (a rainbow umbrella).

@Stephen Crosby is right (as is so often the case with our friends in Fresno). Why didn't I get an umbrella.

As a follow up to my previous doubts on the benefits of carrier deck placement: "While carrier portals (also referred to as “decks”) provide
users with links to specific websites, most mobile Internet users actively seek out websites to visit." - p.6 Critical Mass, Worldwide State of the Mobile Web, Nielsen Mobile 2008, http://www.nielsenmobile.com/documents/CriticalMass.pdf

Just some facts to go along with my opinion. Download the pdf. It's an excellent read and may open some eyes to truth about the mobile web, its penetration into the markets and its influence going forward.

I just couldn't pass up pasting a link here http://blog.thescoop.org/archives/2008/08/18/six-reasons-to-look-past-caspio/

I read the Caspio link above and can't help but echo that by outsourcing data to a third party, we're then beholden to them. If we move off that platform in the future because of cost cutting - we still need the in house programming and development support to program something new and/or babysit the data migration to something new (and continue paying someone else to do it for us). Two advantages to Drupal are of course the free, robust and open source nature of the product, coupled with the fact that the database remains ours (and is SEO friendly).

I don't understand why we'd pay for Caspio when we can create a fully customizable, free database in house. Perhaps one could argue for the quick turn around involved in creating said database and the ability for anyone in the newsroom to create the database with very little training. But chalk up another monthly maintenance expense that probably won’t do as well in search. Would it be more prudent to train our folks how to use Drupal (or Rails or what ever) for database creation and perhaps even nurture a few budding programmers in house?

I'm sorry to be the voice of reality in the Caspio discussion, but lets look at the facts at least I face on the ground. In the last 2 months at the Bee we've lost 5 of 6 people with the skills to build a custom database solution with only the possibility of replacing one of those. We have been mandated to NOT use Drupal and using 3rd party hosting is frowned upon. In my almost ten years with McClatchy I've had MI consent to setting me up one, count 'em one, MySQL database.

Clearly, I have very few options and so Caspio shines pretty brightly. While as a programmer I too find Caspio limiting and somewhat troublesome to make it do what I consider things it should do, I find it invaluable for handing off those can-you-put-this-excel-data-online-for-me-please annoyance assignments to others in the newsroom (who seem to enjoy it) and as an information provider we reap the benefits just the same. By using Caspio we've had relatively non-technical staffers set up and maintain a surprising number of online databases each of which have driven large (sometimes huge) traffic numbers. That's a big win.

The real question here is not whether Caspio is a useful and/or worthwhile tool, but rather have we as a company done the right thing by creating a situation where it IS a valuable and worthwhile tool.

Oh and that whole SEO argument is crap, by the way. You generally don't want your result data as part of your SEO and you can still put descriptive text and other SEO fodder on the various Caspio-powered pages, but I digress...

As a programmer and an editor I wish that I had the time and resources to build each database by hand, but that's not going to happen -- no matter how we're staffed. We're goldfish; we'll find enough work to keep us busy no matter how we're staffed.

But, I also like Caspio. Why? 'Cause a lot of those can-you-put-this-excel-data-online-for-me databases are only going to be good for a short bit of time anyway. Why not make it so anyone in the newsroom can put it online instead of waiting for someone on the IM team to do it? We'll still take the major projects and program them by hand. Now if we could actually get people in the newsroom to USE caspio. We have got to start doing some things the easier and quicker way when we know it's just not going to drive big traffic or isn't that journalism with a cap "J."

Plus, really, Caspio has saved my bacon a couple of times when it came time to whip out some project in just a few hours.

So, here's my reasons why I like Caspio:

1. You can take data and make a totally searchable and organizable interactive page in less than an hour.

2. You can create input pages for readers that keep the info and make it searchable for others. Also can be done in less than an hour.

3. They have good instructions so it doesn't require someone to teach someone else.

4. It's Web based and not hidden behind a firewall, so you can work on it from outside of the office.

5. Caspio does offer pre-made modules, even if it is at a cost. When was the last time an affiliate built a searchable database and offered to help another site set up the code for their use and traffic?

6. We can do some programming around Caspio, creating bigger projects if you want to.

7. It allows us to do things that officially we're not allowed to do through MI services (I second Marc's points about MySQL and Drupal support. I also second the 3rd party hosting, but that's one thing we have to do).

Mark I reject your reality and substitute my own! Actually, here's the posts that really got me thinking about caspio, I should have put it up earlier: http://blog.thescoop.org/archives/2007/09/07/outsourcing-database-development-or-the-caspio-issue/ and http://www.tubotu.com/?p=54 .I'm not ready to say that caspio is worthless, but there are numerous free tools out there designed to do exactly what caspio does, except for the holding your data hostage part.

Mark's realism is quick, easy, here, and now; but my idealism looks to the future. Data is one of our most powerful allies, and I think we could do a better job of harnessing that power. To me, Caspio just feels like an afterthought; a nickel answer to a five dollar question.

From article's comments..

From my perspective (programmer for online news), the #1 reason NOT to use caspio is it empowers everyone to create databases of information. While this, in itself, isn’t a bad thing, when reporters feel as if creating amazing database applications are easy, they not only devalue the work the programmers do, but also step on their toes. While the reporter is building databases of information and mashing it up in interesting ways (ie. Fun Stuff), the programmer (me) is relegated to munging templates and piddling his time way (ie. Not Fun Stuff).

Is this selfish? Probably. Is it important to keep your programmers mildly interested in their day to day activities? I think so.

... Another user responded "I love this! Programmers are afraid of an enabling technology. This is hilarious.
The web gave everyone a tool to put printers/publisher out of work. Caspio has created a tool/service to put low-level programmers out of work." ...

Then I responded --

I feel as if I need to defend my point.

The web merely lowers the barrier to entry for people to get into online publishing. It doesn’t, however, lower the standards we as a community have. That’s why you have sites like http://havenworks.com put out by people who are “technologically enabled”. http://portfolio.com , on the other hand, is put out by someone with chops. Someone who knows what they’re doing.

If you slight the amount of work and knowledge involved in putting out a good product with phrases such as “No more programming for custom web applications”, you’re going to end up with a communist—”everyone gets the same thing”—style future.

Do you think http://everyblock.com would run on caspio? No! It takes knowledgeable people putting in actual effort to create something interesting.

But don’t take my word for it: http://www.jacobian.org/writing/2007/sep/12/db-journalism/

Caspio is to developers as Blogger.com is to journalism.

(comment character limit; not from article's comments).. That being said, I think caspio does serve a purpose to the "I've got this excel spreadsheet..." issue. Then again, educating reporters that "Yes, we can actually do something interesting and compelling instead of posting your stories online 17/6" (not quite 24/7 ;) ), would also be a strong first step in the right direction.

I respectfully disagree with you Justin. Once you have a tool that makes the hard things easy it is your job (and mine) to go find new hard things. If you wind up relegated to piddling your time away, that is a management problem, not a tool problem.

I'll add that piddling away developer time on redundant projects isn't a luxury we have as an industry or company.

Sure, Caspio has shortcomings. But are they worth the opportunity cost of not doing something else (ideally revenue enhancing)?

If the best that can be offered to Justin is munging templates vs. building small database apps that Caspio is "good enough" for, we have very serious issues with business development.

I'm not to worried about Caspio from a job security perspective. My thought is, if we're just going to "throw a spreadsheet online" maybe we do need Caspio. Now I'm still trying to understand this business, but it makes me think there must be a better way do organize all our data. Do we really have so much "here today gone tomorrow" data that we need online? Most of the database projects I've worked on could be built upon endlessly and if done right could serve our readers indefinitely.

I would love to see a real data McClatchy data center someday that could link up all manner of databases, everything from speeding citations to restaurant health inspections to US census information could be geocoded and linked and searched forwards, backwards, and sideways. Collectively, we have the development power to do exactly that, but it seems like we're just too busy "throwing spreadsheets online". Each of us affiliate papers could become *the* go to place for local data. But that opportunity won't last forever.

A word from a mid-size fish in this sea of Caspio commentary: without it, we'd have zero, zippo, nothing, nada in the way of databases.

We have exactly one programmer in our building, and trust me, Caspio in no way devalues him.