Feed.us CMS and Content Delivery Platform
Feed.us has taken a shot at the content management market and one that strikes a distinctly different approach to solving the typical problems with light-weight publishing. Via the combination of software-as-a-service (SaaS), XML data transformation and flexible input and output APIs, Feed.us thinks they've carved a foothold in the market. If they've played the cards right, it could be one that's going to make life easier for a whole lot of folks. Come along for the ride as we spent some time in the mind of Feed.us co-founder, Rick Stratton.Create their own "Content Delivery Platform" and build a business around it, of course. According to co-founder Rick Stratton, Feed.us is "is a hosted content management system or a content delivery platform... [the] intention is to host the content and then provide a variety of APIs to deliver any content to any site or application hosted anywhere on any platform." Rick was kind enough to sit down with us to banter a bit about this latest venture into the SaaS CMS arena: CMSWire: So let's start with the original company, I believe it was called 1871 Media... Why was that company started and why did you choose to sell it? Rick Stratton: It started in 2000 out of the dotcom failure. We had worked for a company that had like 3 dotcoms, including a CMS company. It ran out of money and we were able to buy the software that we created for very, very cheap. So we started selling that software to customers. We started doing work for political campaigns and newspapers and that became our focus. Basically 1871 Media had a suite of publishing products: newsletters, website management, ads and ecommerce. We had about 150 clients. We did everything from hosting, site design to even writing. We weren't great at site design, and didn't have the resources to make our software great. We always wanted to just do the software and let others create/control the website design. And hosting sites is a pain as well... when Godaddy sells it for $2 a month! So our goal was to find a way to just do a hosted publishing service. RSSCMS.com was a raw, first attempt. A rough draft so to speak. Also, I'm not a programmer nor am I a designer but I've always wanted to be both. I can do a bit of both, but I'm not great. I guess my strength is that I'm like the end-user. We build products that should work for people who just want to write, add content, pages, etc. CMSWire: So RSSCMS.com was the "first draft", what happened next? RS: It made me realize that I could mashup websites without being a programmer. And it got our CTO fired up to make a hosted solution. But we realized that javascripts just can't be used to make websites. Because it's client-side and Google cannot see the text. Similar to Flash. Plus, with all the software we had created for 1871 Media, it had gotten old and bloated... 4-5 years old is like ancient. There's so much more cool new stuff in the last couple years. We wanted to start from scratch and make something that would work great for us. One thing is that I have a network of like 50 sites. And I've always paid a person to put them together. Plus they've all had separate CMSes for each one. The big thing is making a product that works great for my network of sites. That's the other motivation. Making something that really works for us. There are, obviously, way too many CMS products out there. But there are very few hosted or "content delivery" versions out there. And to have our [system] work as a hosted solution -- solving that problem [how to make the content available to search engines] was our main focus. The RSSCMS way -- with javascript -- was super easy. Just like Adsense... copy/paste a little code and the content flows from a remotely hosted server. But widgets are not great... slow pages, etc. And Google can't see the text. That's a deal breaker. CMSWire: That is my question. How does the text get spidered? RS: John, my partner, is an old-hand with caching systems. So he had a dream one night of how it could be done using a caching object. CMSWire: Wait a second, did he really have a dream? RS: We struggled with what to do to replace the javascript. John Welborn (my partner/cto/programmer) had been working on a big caching project and seriously woke up in the middle of the night with the realization of exactly how we'd replace the javascript with caching. Some folks dream in French, he dreams in cache. I'm not the most technical person, but the basic [idea] is this. There's one locally hosted file. It's a PHP or ASP or ASP.Net or even Ruby on Rails file. And there's one directory with read/write access setup [on the customer's server]. It could be on the $2 GoDaddy windows hosting, or on a server in someone's basement. That local file accesses our server and downloads content. It's a form of caching. Then, on Feed.Us, we have a "script-o-matic" that creates two lines of code that are placed into the Website's files. This part is just like a javascript widget -- just like Adsense. Using the Sciptomatic, you can choose what content gets pulled off our servers. By date, by author name, by date range, by categories, etc. Then you choose what fields to display using XSLs. Our system is all via XML, so the XSL tells the system what fields out of XML to display. CMSWire: Let me see if I understand. I am writing a blog post using Ecto or Blogger.com -- something that supports the MetaWeblogAPI -- and I post my content to a Feed.us server, right? RS: You can type directly into feed.us, but our hope is that you will use something that you enjoy. CMSWire: Feed.us has an editorial interface? RS: Yes, with a WYSIWYG editor, etc. We want you to be comfortable: send an email, log on to feed.us, use blogger, whatever. CMSWire: My content is now sitting on a Feed.us server somewhere. I configure my webhost with the aforementioned file and directory. What's next? RS: Next is the site files. Feed.Us doesn't handle the templates. It doesn't have some sort of file system. We don't want to control or host your site. So you can have any designer make a site for you. These days that means CSS/XHTML. CMSWire: So my content goes into a database? RS: Exactly, into our database and comes out via XML. CMSWire: Where do the two lines of javascript go on my side? RS: They go right into the area of your HTML where the content would normally go. CMSWire: Like a server side include? RS: Yes. You would have 2 lines of code that say you want to display the last 12 articles and then you've got 2 lines of code that say you want to display the previous 10 headlines. CMSWire: Is the content pull at runtime (when the page is rendered)? if so, how do the spiders see it? RS: Exactly. Back to the caching... that local file pulls the newest content every 20 minutes. Or you can force it to "refresh" and grab the most recent stuff. Very similar to the way Feedburner pulls articles into their RSS feeds. The content sits locally -- and displays on the page normally. So it's all local. CMSWire: If I view source on the page, I will see spiderable xhtml content? RS: Exactly. It looks the same as if you typed the article directly into a PHP page (or asp, etc). CMSWire: Are there any concerns about performance? I know bandwidth is one but what about on the Feed.us side? RS: That's the cool thing about it. Caching is built in at the very start. So there is very little drag on www.feed.us for traffic. The only traffic is people entering articles, files, etc to Feed.Us. CMSWire: So performance was a consideration from the very beginning. RS: A consideration? No. But because of our background... we've built some dogs, performance wise. We've made MANY mistakes. Since 1998... Lots of mistakes and headaches...throwing servers at the problems. Performance is crucial. CMSWire: Then more a culmination of best practices around web app development and deployment. RS: I don't like getting text messages and phone calls at 2am! CMSWire: What is your target market for this product and how do you plan to monetize it? RS: We've got 2 problems. We just discussed the first: explaining why a hosted solution is a good solution. The second is market. I believe making a great product is key for creating a customer base. But creating a product that works for a particular niche also helps create a customer base. Our main, initial customer base is freelance and small firm designers that are not programmers. The other initial target market is domainers (people who host a ton of websites). But really, the larger market is the movement from enterprise CMS systems to blogs. That's the movement I'd love to address. I'm not sure that a couple guys in the Midwest will be able to make a real dent. CMSWire: We have talked about potential markets. Can you talk about your revenue model? RS: Sure. Freemium I believe is the term. We want to offer a free, limited version. Then a full version around US$ 3000. Then a reseller of sorts version just under US$ 10,000. CMSWire: What does US$ 3000 buy me? RS: US$ 3000 buys you the full product that can manage as many sites as you want. Multiple users and tons of file storage. CMSWire: If i am GoDaddy, why do I buy the US$ 10,000 over the US$ 3000? RS: The reseller (needs a catchy name!) version allows you to customize the look/feel and the domain name of Feed.Us. Your end-user customers can log into your own solution. It won't be Feed.us to them. CMSWire: With the premium version, your staff gets involved and creates a customized version? RS: Exactly. With the wonders of CSS, Feed.us resellers can customize the whole thing: logo, colors, etc. CMSWire: I am assuming that these numbers are for a year of service/availability and support? RS: US$ 10,000 is the setup fee and then a yearly maintenance fee. CMSWire: So US$ 3000 gets you in the door and then approximately 15% per year for maintenance and support? RS: Exactly CMSWire: What about organizations who want to use Feed.us inside their corporate firewall? Could they setup an internal instance? RS: We've thought about that. There's a way to get the content to an internal network, securely, using the cached based object. If folks wanted a server version to have inside their facility, like Google does with the search appliance, we could do that as well. If people actually wanted Feed.Us, we'd be happy to make it happen. CMSWire: How do you plan to scale Feed.us up after it becomes publicly available? Will you leverage something like Amazon Web Services or will you manage the hosting of the app yourself? RS: We've got Amazon S3 built in for file storage. File storage is the one issue we thought we'd have for scaling our application. But we've built it from the start to scale easily. CMSWire: If I am an experienced Wordpress, Movable Type or Drupal user; why should I consider Feed.us? RS: 2 reasons. Maybe you like long installations and you enjoy the pain of upgrading some people love that! I'm serious, it gets their geek on. But Feed.us, once you understand it, is like 30 minutes or even less to setup a new site. People enjoy having servers around them and installing software. I can't argue [with that] but a new site on MT... typically days. Templates, and all that stuff... The other reason is that we can handle all sorts of different types of content. We're not just for a blog -- calendars, product info, FAQs. You can customize the fields to work for your writers and editors. MT and WP are restrictive there. CMSWire: If 2008 is truly "the year of the mobile web", how does Feed.us fit into the picture? RS: Feed.us works great for making multiple versions of websites. So IMHO, publishers need to have mobile versions for the coming onslaught of iphone/android/blackberry surfers. Feed.Us makes it easy to create a separate mobile site and/or create shorter versions of articles. CMSWire: Why .Net for the underlying architecture? RS: We are much maligned about this choice. Via John Welborn:
.NET is a fully object oriented programming language, not just a scripting language. .Net's multiple language support allows us to work with a variety of developers. Also, the Visual Studio development environment is powerful and easy to use. The negative? .NET's approach to web development is as if you're creating desktop applications, not web applications. Also, AJAX is implementation is more challenging with .Net.
CMSWire: Thanks so much for your time... this has been great. RS: Thanks for your time, I love talking about Feed.us!

The Wrap

Although Feed.us is still in private beta, feel free to head over and request an account. After your test drive, we would love to hear what you think of this approach to solving our old and dear content management issues.