Om and Niall PodSessions

In this week's podsession Om and I discuss network neutrality and the tolls paid by content networks to network providers to boost the performance of online applications. The telecom world is emboldened after the Supreme Court decision last summer in the case of National Cable & Telecommunications Association v. Brand X. The court ruled in favor of the carriers, allowing corporate discretion over access and use of their services.

Cable operators have already prioritized their own network data such as Internet telephony over the data of other services. Some telecommunications executives have even stated that large services such as Yahoo! or Google should pay for faster response times on their networks. Some customers have already noticed traffic shaping resulting in slow or no access to podcasts, and non-functional software phone clients such as Skype. Om and I address these issues and their affect on online businesses of all sizes in this week's podsession.

The audio recording of this week's session is 23 minutes and 14 seconds in length, a 10.8 MB download.

Transcript

Niall Kennedy:

I'm Niall Kennedy.

Om Malik:

And I'm Om Malik.

Niall:

And this is the Om and Niall Pod Sessions.

Om:

Hey Niall, how are you?

Niall:

I am doing well Om. It's the day after Christmas. It's been nice to relax for a couple days.

Om:

Did Santa bring anything for you?

Niall:

Yeah I got a few books, and a few DVDs. Mass consumption.

Om:

Ah, nice. I had to play my own Santa, so unfortunately I decided not to go for DVDs or books. Instead I decided to blow my money on other stuff.

Niall:

Well let's talk about what all geeks want for Christmas: more bandwidth and more access to all the things online.

Om:

Oh yeah. Well I wish we could get what we wanted. Yes, the world is rapidly changing on us broadband freaks.

Niall:

Yeah. So I wanna talk about network neutrality, two-tiered Internet and some of the other terms that are used to describe how carriers interact with inside operators and how that might impact Silicon Valley. So how did this issue first come about? When was the genesis of the idea of a two-tiered or priority Internet?

Om:

Oh, you know, between you and I and everybody who's listening, this has been the dream of carriers, the incumbent carriers for the longest time. You know the whole concept of Internet is something which goes against the grain of how the old-school telecoms worked. You know for the longest time, more than a century, they have made money by taking a call, which starts at one point, and terminating it in another point, and metering the call and making money off that. So that's the mindset for them; the whole concept of flat-rate consumption doesn't make sense. That's just the way they've done business. But the world is way different now. Somewhere down the line they will have to come to a compromise and, as consumers, we will have to come to a compromise. But when you look back how this whole thing was started to get traction, it was in the Brand X decision.

Niall:

All right, before we go into Brand X, I realize there might be a lot of people listening that have no idea what is a two-tiered Internet or traffic shaping. So to give a little bit of a background, the general idea behind the two-tiered Internet is being able to, on the service provider level, select certain services or certain websites to packet prioritize or be able to give better performance to a certain application or degrade performance of another, competing application, for the benefit of your own networks, your own pocketbooks. Some examples may be to just cut off Skype entirely to keep your own VoIP products alive and running, to drop iTunes Music Store or podcasts from your service to make sure your own music service is alive and well, or it could be someone working out a deal, for example a search engine, where a network operator could prioritize Yahoo! over Google some payments. That's what we're talking about: the ability to use traffic shaping or packet prioritization to build a different tier on the Internet and to control what services flow across the pipe.

Om:

Right. I would like to add a couple of clarifications. Don't expect the phone companies or cable companies to degrade somebody's service intentionally, because that is going to become a problem for them in Washington D.C. However, they can give priority to their own applications, or to their own partners. So think, "The enemy of my enemy is a friend of mine." It's sort of like that concept.

These guys are not that evil that they'd go out of the way and create problems for their rivals, but they will give priority to their own offerings, or their partners' offerings more so.

Niall:

What are some of the carrier offerings or partner offerings that you've seen already?

Om:

Right now we haven't seen much. We've heard sporadic complaints about shutting down Skype, and Vonage has some quality issues. Those are the early examples of when the incumbents get pretty serious about some of the new IP services. I think Skype has a legitimate problem in that sense. It consumes too much upstream bandwidth on people's computers. It actually has become a bit of a networking nightmare and has created a whole lot of security problems.

In the case of Vonage, nobody has explicitly degraded their performance except for a handful of smaller carriers. You'll find that suddenly AT&T Callvantage VoIP provides services that are much better sounding than Vonage, or you know the Comcast VoIP is going to sound much better than Vonage. It's because they're prioritizing their own traffic. They are managing the network to send traffic in a way in which you, the consumer, don't really feel that it's any different from your traditional phone service. That is why I expect this to roll out in video services. I think video over IP will be an area where they will try to clamp down on IP services. The same is going to happen in radio, online radio, and online music services.

Those are the early examples. I think then there will be a whole different approach to this. I cannot stress enough that they will not go out of the way to degrade somebody's service. They will go out of the way to upgrade their own service, which are two different things. But the end result is pretty much the same. You know, it's like, "Hey it's my car. If I drive it at a hundred miles an hour, who are you to say anything?" So that would be their argument, but that's a valid argument though.

Niall:

Or is another part of the valid argument that these are very time-sensitive services, so in order to have VoIP or IPTV, you would notice if it was delayed by a second for example.

Om:

Right.

Niall:

Whereas if you were downloading e-mail, or loading up a webpage, maybe you can wait a second for that. So from a carrier point of view, wouldn't it make sense to them explaining it to their customers to say, "We realize that these types of services are more time-sensitive, and we've done the hard work for you."

Om:

Right, so a lot of smart companies are actually preparing for this kind of a situation. Google is one of those companies. There is a specific reason why they are building up their own backbone and coming closer to the user is because if they have appealing relationship with, let's say SBC or Comcast, they are actually in a better position to exchange their traffic. So similarly traffic coming out of SBC's network or Comcast's network gets priority onto Google's infrastructure. So those things are important. Those are traditional relationships, which companies like Google are realizing they have to do those in order to kind of stay relevant in the future. The way I see this shaking out, in 2006, 2007? Before the end of 2006 we will have an example of this. We will have to, you know there is nothing wrong with two-tiered Internet really.

You know one Internet, the way it is, but then the incumbent carriers, at least in the U.S. will create what is the managed layer on top of this Internet. This will be the premium networking layer. It will be used by, for example, online gaming companies. You know latency's such a big issue, so if you're Sony or Microsoft it makes sense. If you are Xbox Live, you will be asked to pay a few million dollars to make sure your service, or your packets, get priority over everything else. There's nothing wrong with that, because this is a commercial service Microsoft is selling over somebody else's pipe so Microsoft or Sony will have to pay for it. Similarly Apple will make sure that iTunes will get priority traffic handling. These are premium services, so the concept is if Apple is making money and Microsoft is making money and Sony is making money, why shouldn't the carrier make money?

They're thinking along those lines. I don't think they're going to try and mess with your e-mail or your webpages, you know you can still get your online services the way you want. However if Sony or Microsoft or Apple have a relationship with Comcast and SBC they know they get better performance. And as a consumer you don't pay for it. You're paying Microsoft, Microsoft is paying SBC or whoever. So that, in the end, that's not actually a bad thing, if you're a paying consumer. The biggest concern I have, and I've written about it extensively, is that if they start deprioritizing other people's traffic intentionally, that's when things start to go wrong. That is just not right. And I hope it doesn't happen, and I don't think big gazillion dollar companies like Comcast or SBC or Verizon will do that because that would just open up too much political scrutiny.

Niall:

Well there have been threats to do it, right? A lot of people have come out and said, "Well I could just shut off Skype tomorrow." And there have been a lot of executives that have talked about this, and hasn't it already been done in Europe? Or in other countries, hasn't this already been happening?

Om:

It has in some places. Now Skype is a totally different. Skype is a parcelling service. It basically it doesn't add anything to the carriers. So if you're Vonage or Skype, you're actually taking away dollars from those carriers. You're actually throwing away commodity. They get scared of that. I mean everybody's scared of that, because that's been their cash cow for a century or even more than that, so that's a whole different thing. But what I'm trying to talk about is the other applications and not just the voice applications. The way I see it shaking out is they're gonna come out with their own voice offering, which will be a VoIP offering, which will probably compete with Skype and Vonage and that will get priority over those two. And unfortunately there is very little we can do about it.

Niall:

So how are people working with the networks right now, to make sure their company's services are one of those services prioritized? I think people listening to this will say, "I wonder if my competitors are on that list, and how do I get on that list?"

Om:

So let's say it's Microsoft, Sony, or whosoever. First of all, this doesn't happen right away. It is two or three years before the network neutrality, which means equal access to everyone go off. So that's very important. So there is time to build relationships.

Niall:

Now what does that mean, "network neutrality rules go off?" Is there a certain law that's about to expire?

Om:

Because of the recent approval of mergers between AT&T and SBC, and MCI and Verizon, the FCC, which in my opinion is not doing its job, unfortunately, not watching out for the consumers, has shown that at least for two years we won't have network neutrality in place. So, having said that, I have issues with that, but I don't want to get into that right now.

The whole concept is that going forward, we have to worry about giving access to all services. The biggest concern right now is, what if we go back to the same argument I made earlier, what if they start shutting down access to IP services, which do not pay them at all? That's wrong. I think as long as they can charge, they want to charge and have a managed network, and charge a premium from certain people who want better performance, that is fine. The minute they start imposing a toll tax, this quasi-toll tax for the access part of it, that is where things get a little complicated. That's where, as a consumer, you have to stand up and scream, because why are you paying them fifty dollars when they define what you can see or what you can't see? So we cross that bridge when we get to it. Right now everybody's made threats, nobody's followed through. So it's something we have to watch very carefully.

Niall:

And how would we even know? If we were watching, how would we even know when it starts to take place?

Om:

Well, unfortunately for the big phone companies and the big cable companies, I'm there. I'm gonna be watching. It's what I do. So, it's one of those things. But I think this is going to be a very hot issue for 2006. I think it becomes more and more important, I think the FCC will have to stand up and give clarification on how this thing is going to be run. I have some doubts about the FCC's willingness to defend the American consumer, but they will have to. I hope the political climate in this country just becomes slightly different than what it is right now. And even we have more open minded FCC in that sense, but there was a big article in Washington Post which compared FCC to the KGB or something like that. I'm not going that far, but at some point they have to really, really figure these things out.

Niall:

Some companies already integrated with the carriers. Verizon and MSN partnered together for content deals, and the same thing with SBC and Yahoo!, so they already have a good position for this changing landscape.

Om:

Right. They do. I would bet you that in exactly twelve to eighteen months from now, there will be some major rethinking of the phone companies and cable companies. They will suddenly wake up in eighteen months and realize that the relationship is with Yahoo!, not with SBC. And that's when they're gonna say, "Uh oh." And I think that will be an interesting development. And that's my prediction, in eighteen months you will see that happen.

Niall:

And do you think it changes the M&A game for carriers? Are they going to start looking at more content acquisitions?

Om:

I don't know if they will start looking: the cable companies already are. Cable companies slowly, unwillingly, kicking and dragging themselves into this new world. They are starting to think like a software company. They have to think like a software company. They have to think like Yahoo!. They have to think like Microsoft. Because that's the world. What use is the network if it doesn't have anything you can do with it? The cable companies are actually getting the message pretty well. Comcast recently formed a special group in which they will invest in companies and that sort of thing. I think Rupert Murdock has already gotten the message. It's not just video advertising and online advertising which is driving it, but there's a change in consumer behavior, which is very important. But let's see how the phone companies react to it.

Niall:

So how does this affect Silicon Valley? Carriers versus the valley?

Om:

Ahhh. You know how it affects Silicon Valley? I think it throws cold water on innovation a little bit. I think the biggest companies at risk here are the start-ups. Yahoo!, Apple, Microsoft, Google, Sony, HP, they have enough money to pay the carriers. So they have the mass market, they have the mass volume to actually figure all this into their business plan. I think all these little start-ups, which are basically getting started, they haven't taken into account this reality, that one day they will have to pay, they might have to pay a little toll-tax on what they do. I mean if you are an online, I don't know, word processing software company, something like Writely or whatever, they can basically give priority to Microsoft Word over you, so those little, little things start to become a bit of a problem. Things like latency issues, because Microsoft Word is gonna perform better online than the other ones. So you're inherently thinking, as consumers, "Let's go with the one which is working better." So those are the issues. Those are practical problems. People will have to deal with them.

Niall:

Are there any open networks that we won't have to worry about this on?

Om:

Well.... Look, this is all projection. I don't know how the world shakes out. I mean that's, this is the worst case scenario, I'm trying trying to present, so...

Niall:

OK.

Om:

All right. So, I don't know. You know muni wireless is one hope we have. I hope it really takes off because it actually puts some sort of pressure on the carriers and when I say carriers I mean both cable and phone companies. So I'm not taking sides on this one. But meanwhile this is important and I hope we see some of this traction, I think sources like MetroFi and cities like Philadelphia and New York and San Francisco are actually successful in doing this and giving people at least an option. It may not be much of an option, but it is an option. And you also have to worry about even the smaller players like Clearwire. They're also pretty stringent about who gets access to their network. Because the networks are pretty complex things and you can't really define who's the good guy or the bad guy, and everybody needs to make money.

I can look at the issue on both sides and I say, "Well, I understand the incumbent point of view because they need to make money and yada, yada, yada." And I look at the other side and I say, "Jesus. I'm a consumer and I don't want anybody stopping what I can see or how I can use my Internet. I pay sixty dollars a month for it! Why should anybody be defining how I use my Internet connection?" So those are two conflicting thoughts right? But muni wireless, they'll perhaps become the third option. If it's free, if it's available, I can maybe say, "Well, maybe I don't need all my services from Comcast or SBC. I can maybe take a little bit from them, the rest of it comes from muni wireless" or something like that. I don't know. The issue with muni wireless is bandwidth. How much bandwidth will they have?

Niall:

OK. One final question. If I'm a small business, Technorati or Pandora for example, what should I be doing about this? What should I be looking out for to make sure my business is not hampered?

Om:

I think a lot of the companies actually do business with AT&T. I'm sure your company does business with AT&T for example. Pandora does, or anybody, because they know how to manage a network, manage infrastructure. So, you have a little bit of that built into your gameplan so to speak. But I think as it becomes clearer that these guys are beginning to work with certain providers more so than you, then you probably have to reach out to these guys and see how it happens.

I really don't have a clear answer on this to be honest, I mean, look we've heard three telco executives make big noise about how they want Yahoo! and Google to pay for everything, but we haven't seen anything actually happen. So, I really can't say. But this is something people need to think about. This needs to be factored into their gameplan. Just like how many people you need to hire, and how much venture capital you need to make, this is something people should be thinking about as start-ups.

Niall:

All right, we'll post some more notes on the blogs, so people can follow up and get more information.

Om:

I didn't let you talk today though.

Niall:

I've done plenty of talking. We'll have another time for that.

Om:

Nah, it's not RSS right?

Niall:

I'm deeper than that Om, but I'll make sure my tinfoil hat is securely attached to my head.

Posted by Niall Kennedy at 8:03 PM | Permalink | Comments (2) | TrackBacks (1)

The world of APIs received a few new entrants and business strategies this week as companies competed for geek downtime of the holidays. Om and I sat down on Saturday evening to talk about the big changes and what they mean for startups, developers, and end users. We were joined by special guest Kevin Burton of TailRank.

This week's session is 26 minutes and 28 seconds in length and a 12.2 MB download.

Topics

Amazon introduced its Alexa web search platform on Monday that allows developers not only access to the search engine's APIs, but the ability to supplement Alexa's data with your own, process it on Amazon's servers, store the results with Amazon, and even serve your own APIs based on the combined data. The new offering creates many new opportunities for small projects and startups to get a quick start without maintaining their own crawler or hardware.

On Tuesday Google introduced the Google homepage API, opening up its personalized homepage to outside content. These newly created homepage modules can be styled to match your own branding and have some smarts.

FeedBurner launched FeedFlare on Tuesday, allowing feed publishers to easily add content to their posts from popular web APIs such as social bookmarking site del.icio.us or blog search engine Technorati.

Yahoo! released a new output format, JavaScript Object Notation (JSON), for its search and maps APIs on Thursday. This new format helps developers potentially skip a step when interacting with Yahoo! data, making dynamic applications respond faster and easier to develop.

Google seeks to extend its reach into the VoIP and video IM space with its introduction of jingle, a new API for Google's GTalk client. Google proposed two new extensions to the XMPP standard used in its clients and many others throughout the world. The new libraries and APIs should extend the reach of Google's instant communication services throughout the Web.

Posted by Niall Kennedy at 8:44 PM | Permalink

Om and I interviewed Jason Fried and David Heinemeier Hansson of 37signals as a bonus PodSession this week. 37signals is a 7-person hosted software shop based in Chicago. Their current products are focused on project management and personal life management. David Heinemeier Hansson is the lead developer of the Ruby on Rails framework.

Our discussion focused on scalability, the tools needed to get the job done right, and how small businesses can better plan to succeed. The interview was conducted via a telephone conference call.

Our interview with Jason Fried and David Heinemeier Hansson is 29 minutes and 50 seconds in length and a 13.7 MB download.

Topics

1. Are companies building to scale? When does it pay to plan ahead? Are companies currently being built to flip and not worry about scaling?
2. How does Ruby on Rails help you think ahead and build more scalable code?
3. Ruby on Rails version 1.0 will be released this week. What is new in this version and what can users and developers look forward to?
4. What are some of your favorite products that use Ruby on Rails? Blinksale, an invoicing tool written in Rails.
5. When will Ruby on Rails and software such as Typo become more mainstream and used to power more blog sites?
6. What tips do you have for people thinking of starting a company?

You can stay up-to-date with Jason, David, and the rest of the rest of the 37signals on their weblog, Signal vs. Noise.

Transcript

Niall Kennedy

Hi this is Niall Kennedy.

Om Malik

I'm Om Malik.

Niall

And you're listening to the Om and Niall PodSessions. Today we have 37 Signals on the line with us, we're trying something new today, and doing an interview and a conversation. How about everyone introduce themselves on the line.

Jason Fried

Sure. Hi, I'm Jason Fried from 37 Signals.

David Heinemeier Hansson

I am David Heinemeier Hansson, also from 37 Signals.

Om

Well, you guys know me so, no introductions needed. Right?

So what are we talking about today? I think Niall and I discussed this with you, Jason. We were going to focus on our hotly debated issue of scale and scalability, in a kind of little riff on Jane Austin there.

Jason

Yeah, I guess all this probably came about from the blog post that you put up and we responded to. And so Om why don't you tell me a little about why, why you think that scale is something that everyone seems to be ignoring and why that's a problem.

Om

OK, so that's one of the things that you and a lot of other people don't understand. What I was trying to say was that this is not about adding servers or buying bandwidth, this was basically thinking through your product, thinking through your product strategy and where you will be, and architecting your very innards accordingly. This was not about buying $3 million servers or anything of that sort. This was mostly about thinking through where the company was headed, where the product was headed, and giving some thought to how much do you want to scale.

Now the problem I have is that many companies I meet on a daily basis and the so-called "Web 2.0 companies," they're basically patching things together and the whole concept is if you can do this and if you get some early traction in the market, there's a good chance that you can be flipped for a few million dollars. Now I have a problem with that, and I think that's what I talk about scale and scalability. I didn't want to make this a religious issue, but apparently it's become so.

Jason

David, why don't you jump in first from the software side.

David

I think that the problem with that notion is that the fallacy that you can do this, that you can architect something scalable from day one and that's a good idea. It's a pretty dangerous idea that leads people to think that if they just think hard enough about the problem up front, they can solve it. And I think if you talk to pretty much any of the major operations that have scaled high and low, they'll tell you that they could not have foreseen the effects on the system once users start coming in in droves.

I think Dare Obasanjo from Microsoft touched on this and how they scaled up MSN Spaces over a year to be three times the size of Live Journal. And as you said, they basically had to rewrite everything as they learned about what the issues are. I think that's the key issue is that you cannot foresee what kind of scalability you'll have because real users, real data just have a tendency not to fall into neatly set up simulations, which means if you spend a whole lot of time up front doing what you think is needed to scale, you're going to spend a lot of resources on something that might not turn out in the end to be what you needed. Which means that you started out spending a whole lot of time and money on something that's never going to be used, and you're going to have to re-architect your application anyway.

So it seems like it's kind of placing a pretty high risk bet, and a pretty high risk bet in the sense that the time you're spending thinking about and optimizing for scalability is time you're not spending thinking about, 'how could we improve the application so we'll actually have scalability problems.' I think that people should focus more on trying to get the scalability problems in the first place, of course meaning getting users who care enough the application to use it.

Jason

That's my biggest thing, at the end of what David said, kind of the opportunity cost. When you focus too much time on the future, you're obviously not able to spend time right now and do what really needs to be done now and that's building a great project, a great experience, and making sure the copyrighting is solid, the interfaces are solid, the marketing is solid, so you will have a scalability problem.

You actually want to have a scalability problem. I think that's the real goal nowadays is being able to build something that's going to have a problem scaling because you have so many people using it. Now, of course, the other thing -- and this is something that I do agree with you about -- was this idea of companies not thinking too far ahead, and in general I think it's good not to think too far ahead.

But when you take a company like Flickr that's giving away free photo hosting, they're clearly going to have a hard time scaling that if it's free. It's in fashion right now to give away a gigabyte of space: "let's just give away a bunch of space and let's just see what happens." And I think that's where you start to get in trouble, where you start giving everything away for free, and trying to figure out how to pay for it later.

And so I think that's definitely a problem, and I think that Flickr may have run into that problem as they ballooned in size. Luckily a lot of these companies, us and del.icio.us even though they just sold, but a lot of these companies are dealing with text based data which is pretty easy to scale with. Also, if you charge right off the bat for your services you can scale indefinitely because it's profitable to scale. I think the problem is where it's not profitable to scale, that's when you start running into these problems.

David

Yeah, I agree with that. That's actually when what you want is not technical scalability, you want a business model scalability, like what are you going to do if 100, 000 people actually do come to your site? Are you going to have enough money to buy the servers needed, and so on. It's not about the technical issues; it's about making each request worth it. If you give away everything for free that's of course pretty hard.

Niall

I hear two things coming from you guys: one is to not focus on what exactly will be the feature that you want to scale because you don't know when you launch what will be the most popular feature that you're going to want to go back and re-engineer to create the best user experience, and the other thing that I'm hearing is about the business experience.

We talked about startups wanting to just flip, and part of the interesting thing about giving things away is you gain many users, and Om's done his monetization of the eyeballs piece that will try and prove that it's $35 for every user that you sign up, and it's a little bit more difficult to do that with future service at $5 a month. So doesn't that fall into the whole built-to-flip model when you're trying to get all the users you can without worrying about scalability?

Jason

Well, I would say if your strategy is a build-to-flip, you've got to come up with a better strategy than that. I think a flip should be a pleasant side effect of being really successful. But if you're building something to sell it, you're putting a lot of eggs in one basket there. You've got to deal with the economy.

Google might decide to stop buying people; Yahoo might decide to stop buying people. You have to deal with the stock market; you have to deal with all sorts of market forces that you clearly have to deal with anyway when you have a product. But if you have a product that you're selling and you have your own revenue coming in, you have a little bit more control over your destiny than hoping someone's going to buy you.

I think anyone right now who is building to flip, and they're getting into this business just to build something so Yahoo will buy it is making a very dangerous mistake.

David

I think that it's pretty dangerous too to put a price something like $35 on a pair of eyeballs. I think that is not something that is going to fly in the long term. Jason Concannon from Weblogs Inc had a great post about this and about how they sold and what that turned out to be. In his notion, of course it was all about the revenues, and as he calculated it the price was more like two dollars per user, and that was not based on an intrinsic value of per user, but just on the amount of advertising that could be sold on that pair of eyeballs.

I think that we shouldn't get too attached to the idea that getting one user's worth of $35 is a pretty dangerous generalization.

Jason

One other thing that I'll throw in there real quick is that I don't know of any great company, ever, that was built to be sold. If you want to build a great company, you have to build a great company. You shouldn't be building something to sell it to somebody else. Again, if it gets sold and you're happy to sell, that's great, but to have that as your motivation ' to build something to sell something ' to me, by default means you're not going to build something great, you're just going to build something that someone else wants to buy.

And of course, everyone has different motives. Our motive is to build great products and to build a great company. Someone else's motive might be to sell it, but I think selling things is much harder than everyone thinks too. I don't think Yahoo just comes over and drops a blank check on you and says, "Hey thanks, now we have tagging here and there." It can certainly happen but it's very rare.

Om

There are a couple of things. First of all, the story which I did was $38 for a set of eyeballs, was actually an aggregate of a past-tense of deals which happened and we based it on that. I think everybody focused on that whole issue and never really read the entire story which was about: the whole concept is not all eyeballs are created equal. Some are more valuable, some are less valuable.

And there was a very categorical statement I made in the story that was, if you don't have revenue and you don't have a community which is sticky and is more loyal just the way MySpace was, there is very little value to those patriots. However, the other issue which is the build-to-flip, the issue which I talk about.

One of the reasons I wrote that post is pretty clear is that: look, you guys have a product, you have a product strategy, when you build the product it's almost 95% there. And then you're taking the user feedback and kind of tweaking it, right, either the alpha or the beta users. Now this whole concept of perpetual data, people just keeping things out, not knowing where things are going.

I give you the example of Flickr. Two years ago a lot of the features they had are a lot of the features they have right now. They've made incremental improvements. They thought it through: what they wanted their product to look like, and they were flexible enough to adapt, change, morph as the community reacted. It was not about going into a perpetual beta and saying, "We keep changing our game all the way through."

So those are the issues I have when I say scale and scalability, the build-to-flip model being abused completely, now everybody's doing it and I think those are the issues which are very important. One needs to address those things, and a lot of people, maybe perhaps it's a lack of my own writing skills that I could not articulate as clearly now.

Niall

I don't think that's the case, I think you're a good writer. I think what you just said goes against your original point, which, using the Flickr example, which was they've been adjusting, adapting as have we all the time. I do think things are in perpetual development. I don't like the word 'beta;' I think it's kind of ridiculous, so I just call it like development. I mean things are being developed and improved all the time.

But, that's the exact reason why you shouldn't spend a whole lot of money up front to build this system to scale because the system may change. In six months, your users may take you in a completely different direction and then you've spent X amount of dollars and time on making sure things are going to work the other way.

And now things are different, and so I think that's a great example of why, if you're a flexible company, you shouldn't worry about predicting the future too far in advance because you're just going to end up spending ' and forget the money side of it, it's just time, and time of course is money ' but really it's time and opportunity costs, not being able to do other things that really matter right now.

David

And also, the more time you spend on optimization and scalability and so on, the more you freeze your current architecture, so it's kind of like putting your clay in the oven when you start adding optimizations because these optimizations are usually something that goes against the grain of good software development in general about having readable code, maintainable code, code you can change.

Because often times what's scalable or highly optimized needs to have bulky hacks, needs to go shortcuts through the system, and the more of these optimizations you add to the system, the more brittle it will be and the harder it will be to change and add new features to it.

So I think in software development there's this notion of premature optimization being the root of all evil, and I think that applies pretty well in this example too simply because you can't optimize something before you know what the problem is. And once you do, you've tunnel-locked yourself into that solution, more so than you were before and that's just a dangerous path to go down unless you very much have to. I think that's what the great thing Jason: ...problem is. And what you do is, you've locked yourself into that solution, more so than you were before. That's just a dangerous path to go down, unless you very much have to. And I think that's the great thing about the web, and the great thing about being in internal development, is that you can react to problems as they arrive. I mean, we didn't do, with basecamp, or the any other projects, we didn't spend a lot of time upfront thinking about all these capability issues. We found the problems as they arose, and then we dealt with them. And I think that is simply because you can now. It was different in the old days when you shipped a new CD every year, and you had to make sure that that shipment was solid, and that it could last for years. Now you have so much more flexibility, which totally changes how you go about software development, and it totally changes when you need to do optimizations, and when you need to worry about all these things. You can now push the problems out until they're actually real problems, and that's where you have the most information available about the problem, and that's when you have the most context available to actually solve the problem. So you're just setting yourself up for an easier living if you can actually wait until you actually have problems to solve it.

Om

Ok, I think we should switch gears here. I have some questions about working on Ruby on Rails, and if that is...

Niall

Yeah, do you think that Ruby helped solve some of the problems, having that type of NPC architecture, and helping you think ahead of time helped you thinking ahead of time helped promote available solutions....

Jason

yeah, I definitely agree that different platforms will have different intrinsic capabilities of scaling. Ruby on Rails is very similar to the LAN stack, in the sense that PHP and Python and Pearl and so on, they all have roughly the same approach to scaling, which is the notion of scaled nothing, where you can add as many web servers and as many application servers as you want by pushing all this data, all the sessions, all the stored data down to some data layer, like a data base. When you have an architecture like that, scaling is a solved problem in the sense that...how yahoo scales, or how livejournal scales, or any of the big LAN stacks sized scale, on a relative scale, how just PHPs in general scale, it just means that the problem is solved in the sense of throwing more hardware in there. There's a path ahead, which means that if you have more problems, you know how to add more hardware in order to solve that problem. That doesn't mean that you never have to optimize your software and never should, just that you're not locked into a box that says this can only scale to 2000 uses and then there's nothing we can do, there's no more hardware we can add. I think that comes back to the key issue, which is, are you making each request worth it? Like, with Faith Campbell we paying customers, by the time we have scalability problems, we will have more than enough revenue to pay for new servers. If your model doesn't have any revenue built into it, then that's putting you at more of a problem. You can't just keep buying new servers if you're not any revenue in. And then I can see, you might have scalability problems, simply because you can't afford to scale. But that's not a failure of technology but a failure of business.

Om

Right. One thing I think, David you mentioned, was that there was an upgrade coming to Ruby on Rails, and I just was wondering what that's all about.

Jason

Yeah, David can talk on that but basically Rails 1.0 is due out what... hopefully next week, maybe?

David

Tuesday. Tuesday is the target right now. So the software is basically right in... we're currently putting the final touches on the new website. It's more of a monumental cultural event more than it's a monumental technical event, since Rails has been at 1.0 since at the beginning of the year. Meaning new changes that we've introduced have kept backwards compatibility. So, what's in 1.0 what it's going to do really now if you're already on Rails it's mostly about the final [box mixes]. We have a whole lot of new features in store, but we're holding those back to the 1.1 release. Now it's just about getting a nice polished 1.0 version out and getting a new web site and getting some refreshed imagining to it.

Om

Explain to me why when the new version of Ruby comes out it will make life a lot easier, I mean, how the user will be impacted, that's what I'd like to know.

David

If you're already using Ruby on Rails, the new release won't impact you unless you unless you hit one of the parts we've fixed. The major change, the major thing is that we now trust enough in it to put on the 1.0 label, which is more about a feel of quality control of our personal and professional pride that we now want to call this project 1.0. And that's more sending a signal, so if you're risk adverse, and don't want to fool around with software that doesn't have a 1.0 label on it, now that's not an issue. So I think those concerns in general, if not silly, then are overrated. But that's how I feel, and that's the reality, so we are defiantly happy to not have that be an issue anymore.

Niall

Alright. What are some of your favorite Rails services that are out there right now, that have caught your interest?

Jason

Rails based products?

Niall

Yeah.

Jason

I'm a big fan of Blinksale, which is by Firewheel Design. Blinksale.com, it's an online invoicing tool. We don't actually use it much because we don't send invoices out much anymore, but I've looked through it and I did actually send a few samples invoices out. I just really liked the flow, I really like the way it works. And of course, what I think is really important here is that technology doesn't make these products. There's no rocket science Basecamp, there's no rocket science in Blinksale, there's no rocket science in Odeo or anything like that. It's not Rails that really... Rails isn't doing anything special, Rails just makes things easier to program, so it just makes it easier to write these products, and you can worry about what makes your products unique rather than worrying about all the monotonous things you do over and over and over. You could build Basecamp in PHP you could build Blinksale in PHP or Perl or whatever you want. It's more of a...David could talk on this too, it's more of just like loving the language that you're writing in, and loving the development process, that basically results in creating better products. If you don't treat programming as a chore, instead you treat it like a love, treat it like something that you just really like to do. You're just going to build better products by default. So I do think that Rails has that special quality to it where people actually enjoy programming in it. It also seems to be a language that people who haven't really programmed very much in the past can kind of get into it. Some people call it a language for designers, which I don't really understand, but I think that the idea is that it doesn't feel like a programming language to someone who is not a programmer. I think you can read the code a little bit there. I don't program, you might be able to tell that from my answer here. But I can read through a lot of the code, the Ruby code, that David and James and the other guys have program, and I can read it and kind of understand it because it almost reads like English, it's logical. And I think that this also makes products easier to design for designers because you can look at the code and understand what it'd doing, and you can almost work with it that way without having to go back to someone and say well, "what did this do, what did that do?" So I think one of the nice things about a lot of Ruby apps or a lot of Rails aps is that there seems to be a focus on good interfaces now, coming out of the Ruby on Rails based software, for whatever reason. I think part of it has to do with the fact that designers, it's just easier for designers to work with programs that are written in Rail, than in PHP or something else.

Om

Have you been playing around with typo and you have some questions I assume, on this and you've have had some issues...

Niall

Let's not make this aabout tech support, let's keep talking.

Om

Oh no, no no! I actually wanted to get to is... how long before Ruby starts to make an impact for bloggers, and for people who are leading the whole open-media revolution.

Jason

I think that the thing about Rails in general is that it's not as well suited as PHP for packaging up and distributing to run on any imaginal hosts, just because there is more stuff involved. And that more stuff makes it harder to currently distribute these applications in a way that makes them easy to install for people who are not technically savvy. And I think that's what PHP is really great at, the distribution of it and the adoption is large enough that people that don't know anything, or much about programming or technical issues can kind of huddle along and get WordPress installed somewhere. So I don't think... it's going to be a while before Rails is going to have an impact there. But, on the other hand, a lot of the most popular services are not like that. Most bloggers are not installing their own blogging software. They're using TypePad their using blogger, they're using WordPress.com, where you get this host immersion, and I think that it's not going to be too long until someone announces some platform like that running on Ruby on Rails. And as soon as you do that, who cares what it's running on? And then, Ruby on Rails can take their competitive advantage for getting stuff done faster. So I don't think the technical issues of that will have that... Do bloggers care? I think bloggers care about great applications, and if somebody launches a blogging service on Ruby on Rails that's just better than the other stuff, that's when people will start caring, not because it's simply written in Ruby on Rails.

Niall

OK, well we're almost out of time. I have just one more question for you guys. For a start ups in small businesses what tips would you like to send out for people to watch out for as they start their own business.

Jason

One thing I alluded to earlier, and I'll repeat it now, is this idea if you are going to build a business, and I'll underline the word business, you gotta have an idea of how you are going to make some money. It's fun to be an idealist when it comes to building something and thinking you're going to be bought out for 50 million or whatever, but in the mean time you have to run a business that can survive if no one buys you. And if you're not running a business that can survive in that way, then you're really not running a business, you're just building a hobby site, which is fine too, if that's your motive, that's totally fine. So I would say that's the first thing. The second thing is, you have to embrace constraints, don't try and push constraints out of the way. So don't go out and get venture funding. You know, it's better to have less money when you start out. Don't go out and hire a bunch of people, it's better to have less people when you start out. Do stuff on the side, as a part time job to build your application, don't necessarily dedicate full time to building something, its better when you have less time to do things, because you'll spend that time more wisely. So, look for constraints and embrace them, instead of trying to push them out of the way. I know a lot of companies spend a lot of time and resources and money seeing an obstacle and trying to get rid of it, instead just working through it and working around it. I think that that is when creative things happen, is when there is constraints in place. So, again, my two pieces of advice would be: if you're going to build a business, you have to build a business, and a business has revenues, and hopefully profits. So work on that first. And second of all you gotta embrace constraints and really work within your limits and not try and do something that's kind of above and beyond what you're really able to do. Don't try to push those things out of the way. In fact, you want to look for more constraints; it helps force you into better, simpler products and simpler solutions. So those are my two big things, I don't know if David you have any?

David

I think just in a technical issue, you should start caring about what we call the epicenter of your application. The stuff that your application really does. Don't start out making a logging system, or making that all that around stuff that's not particular to your application. You should spend the first hours of sitting at the keyboard on the stuff that makes your application special, and worry a whole lot less about all the generic stuff that you need at the end. So worry about the particulars of your application and get that right before staring to do all the other stuff.

Om Malik

Alright. Hey guys, thank you so much for your time today. I thoroughly enjoyed it. Thank you to you. Hey Jason thanks for keeping it civilized, even though you and I fight all the time.

Jason

Well, I think if we were in the same room it wouldn't be civilized.

Well, thanks for having us on, we definitely enjoyed it. You know, I think it's cool, actually, that we can disagree and be civil about it. I think a lot of times, especially on the web, that people start flinging mud back and forth because there is this level of anonymity, that no one has to worry about... no one really knows who you are and you can sit on your couch and rip on people, so, I think it's good.

Om

Goodnight.

Niall

Alright guys

Jason

See-ya.

Posted by Niall Kennedy at 9:12 PM | Permalink | Comments (1)

This week's podcast focuses on the rich media uses of RSS. Syndicated feed formats such as RSS are expanding beyond text, blogs, and the desktop and delivering media content such as images, audio, and video to mobile devices and home entertainment centers. Om and I discuss how these new applications and distribution models affect the average consumer, the network operators, and open new opportunities for entrepreneurs.

The RSS beyond text podcast is 21 minutes and 23 seconds in length, a 9.9 MB download.

Questions raised

1. How is RSS playing a major role in the digital connected home?
2. Why are broadband providers not developing new rich media RSS applications?
3. How can RSS be used to create new experiences with photos, movies, music, and games?
4. What are some companies creating applications for this new platform of rich media consumption?
5. What is the impact of RSS on networks and bandwidth?
6. Do these new rich media opportunities encourage increased bandwidth consumptions?
7. How does bandwidth consumption and perception change in this new environment?
8. What hardware is emerging to help manage this increased flow of XML?
9. What caching possibilities exist?
10. How is rich RSS being used within the enterprise?
11. What companies are doing new and interesting things in this space?

Topics discussed

Media platforms: TiVo, MythTV, Windows Media Center, Xbox 360.
Feed aggregators: FeedDemon, NetNewsWire, NewsGator, Shrook, Straw
Tools: Cisco, FeedBurner

Tags: homemedia, broadband, RSS

Posted by Niall Kennedy at 11:48 PM | Permalink