Welcome to Particletree!

Introduction

The talk about the future received its name about a year and a half ago and like a stray dog recently adopted, the people can’t stop saying its name—hoping to both own it and save it at the same time. The idea, christened by an editor/publisher/developer named Dale Dougherty, came out during an O’reilly conference planning session—clever and inspiring. If you know anything about math, then you might understand what I mean when I say that it was like a vector, describing both magnitude and direction. In the name there was hope. There was promise. There was a path. The fate of the interaction between the work of the titans (Amazon, Ebay, Google, Yahoo) and the work of the people (you, me, and every other promising developer and entrepreneur)—this was the talk about the future. This was supposed to be Web 2.0.

Like I said, that was a year and a half ago and while muscles and sweat and the turning of cogs followed the talk, the talk (and therefore the promise) feels to this day disappointingly unrealized, incomplete and even, at times, incoherent. And so the talk about the future has turned quickly into the discussion about the future and that has turned even more quickly into the argument about the future.

Non-Inevitability of Talk

There have been attempts to get back on track. Towards what, I don’t presume to know. Maybe this? There have been Lacanian attempts to reveal the failure of the language, attempts to deconstruct the snake oil in the message, to call it by any other name, but the fact of the matter is this: the idea has already been planted and so we yearn for it by name. Not because it’s accurate. Not because it was promised. Not because it was sold. We ask for it because it seems so very necessary and seems so very possible. It is the future we’re talking about. You would think there would be an inherent inevitability to these things.

But these things don’t just happen and so it’s important to realize quickly now that while some might argue rather successfully that the problems surrounding Web 2.0 might be that it is surrounded by too much talk, criticizing the talk usually fails to present alternatives and so I am writing this essay with the underlying premise that people are tired of asking “what is” the future and want to desperately get to “how to” contribute to the future. Because when the future gets here, there will be plenty to talk about then.

Assemble

Getting started is easy, but you’ll want to find some friends to help you. No, seriously. When it comes to Web 2.0, don’t try to be a hero. I refer to John T. Preston’s 2001 essay, Success Factors In Technology-Based Entrepreneurship, for the reason:

>What we’ve found is that entrepreneurial behavior is more successful when performed by teams. Professor Ed Roberts of the Sloan School did a study of startup companies and their probability of success. What he found was that the probability of success increased dramatically with team size until you got up to four or five entrepreneurs founding the company. Teams of people with complementary skill sets perform better.

>Success Factors In Technology-Based Entrepreneurship

I’ve talked briefly about this before on Particletree, but there are plenty of great articles out there on how to assemble a team. Paul Graham’s seminal essay, How to Start a Start Up, describes some of my favorite methods for choosing partners in crime. Over at IT Conversations, you can hear Jason Fried offers some tips on how they built the team that built Basecamp. It is much easier to follow along if you also download the PDF presentation to accompany it. As for the roles that need to be filled, check out “The A-Team Theory” presented by James Archer over at Return of Design. Whatever you decide, remember to learn from the mistakes of others. You’ll also eventually need a hardware guy and a money guy if you ever decide to scale upwards. If you’re already a large organization, I suggest you read about The Magic Number 150.

Learn

After you’ve assembled your team, you’re going to want to get people educated and on top of the literature. Remember, the key is interdisciplinary and so every member of the team should know at least a little bit about the following:

• XML - Extensible Markup Language. This is the coal that drives the trains. Learn this solid. Do not skimp. If you want to get ahead of the curve, check out XSL. We personally believe XSLT is the most under-utilized technology in Web 2.0 applications today. It’s been around for years and has some amazing properties. Yes, there’s a learning curve, but it’s definitely worth it.
• A Client Side Language- JavaScript and the DOM is the one everyone is screaming about right now, but there’s no reason why ActionScript (Flash has built in XML parsing by the way) or (gasp!) Java couldn’t do the job as well. Flash enthusiasts excited about jumping into Web 2.0 should definitely check out Macromedia’s JavaScript and Flash Integration Kit. There are big possibilities there.
• Server Side Language - Ruby on Rails is the hot stuff on the market right now, but there’s no reason why original flavors like PHP, .NET (which is VB and C#) and Python can’t do the job. Like foreign languages, the more you know the better you’re off. Once you get a good grasp of your Client and Server Side Languages THEN, you can start thinking about looking at Ajax (remember AJAX != Web 2.0) and other helpful kits and frameworks used to make your implementations both cooler to look at and faster to build.
• Hardware - This is the area I’m least familiar with, but it’s the area of expertise Particletree is worrying about constantly when it comes to scaling upwards. Yes, you can go the hosting route, but you’ll see that more robust solutions (like dedicated hosting) require a good amount of dough. Limitations in this area usually prevent a lot of the most philanthropic web services from supporting a global user base. If you can get a server man on your team, that’s obviously ideal. LAMP and IIS are two places to get started, but I would highly recommend taking a look at alternatives like Lighttpd for those that like the bleeding edge. TextDrive is a great place to start experimenting with these setups. If you’re thinking about offering services right away at larger scales, I recommend starting your education with load balancing.

Blog

The most important rule to follow when building for Web 2.0 is to share. And the easiest way to share information is through a blog. Blogging is also one of the best ways to build trust, a vital component for successful Web 2.0 relationships. It will help you find your voice and establish your reputation. How does the sharing actually work? Well, the medium of choice is syndication and that comes in two flavors: RSS and ATOM. Photoblogs, podcasts and videocasts are completely acceptable variations. Extra points are given to those who use web standards, tag their posts properly and help build plugins for their content manager of choice.

Remix

Steven D. Levitt and Stephen J. Dubner, the authors of Freakonomics, wrote a very insightful post on the Google Blog about their presentation to the search company’s employees.

>The best question of the day was, “What would you do with our data if we could give it to you?” We’ve thought about that quite a bit ever since; we’ll keep you posted.

>Steven D. Levitt and Stephen J. Dubner

My friends, they’re not the only people having problems answering the multi-billion dollar question. Remixing web services or creating “Mash-ups” are a great way to offer your answer to that very question. There’s another great article by Jonathan Boutelle explaining how the best metaphor for Web 2.0 is the DJ. Well, if the developer is the DJ then the samples used in the remixes are provided by APIs. The best way to get on the remixing bandwagon is to look at a list of APIs (we like the Web 2.0 API Reference), read the documentations and getting at least two of them talking to each other.

What is the best way to get your remixes heard? Social bookmarking. Digg is VH1 and del.icio.us is MTV2.

Open Up

>Power in the Web 2.0 comes not from controlling the whole system, but in controlling the connections in a larger network of systems. It is the power of those who create not open systems, but semi-open systems, the power of API writers, network builders and standards definers.

>William Blaze

If you’re a business in the tech industry, the best thing you can do for the future is open up your data. However, don’t believe the myth that’s been going around that says implementing a Web 2.0 business is easier than Web 1.0—that all you have to do is let go of control and free your data and developers will just use it and start programming features for you quickly and for free. There is no sitting back, relaxing and watching the money pour in when it comes to opening up your relationships with developers.

>In order to truly realize the inherent benefits of Web 2.0, organizations need to have technology in place that enables them to exploit the power of XML and Web Services without disrupting their existing IT infrastructure …

> …the ideal solution should incorporate traditionally distinct server features in a single server solution, including: a Web services platform, object-relational database (e.g., SQL and XML), replication server and Web application server, to name a few. By doing so, organizations never need to compromise the choice of their host operating system, database engine or program language—since everything is integrated into a single, platform-agnostic, standards-based solution that can support all of the functions required for Web 2.0 application deployment.

>Kingsley Idehen - Making Web 2.0 business opportunities a reality

It’s a lot more difficult thant you think. Basically, if you think of Web 2.0 as a network of relationships, remember that opening up in a personal relationship is a lot of hard work. Some of the biggest mistakes I see made by a lot companies manifest themselves in their API offerings. Biggest turn offs for a budding developer is to not offer enough data, place a lot of restrictions on that data (flow and acceptable uses) and to poorly document the services offered. Mash-ups are created out of love and sweat. Work hard to give your “biggest fans” the tools they need and you can bet they’ll reciprocate hard work back in their derivatives.

For more information about the connections between businesses and Web 2.0, check out the following resources:

• It’s a Whole New Web
• Web 2.0 can and will be commoditized
• TechCrunch
• A Web 2.0 business model for publishers

Incubate

I mentioned this earlier, but one of the limitations that face your local independent Web 2.0 developer is the costs associated with building a service that’s reliable enough for global use. Thanks to sites like DSL/Cable Webserver, any Web 2.0 hobbyist can start a creation, but that creation has no chance of survival (even on shared hosting plans with ridiculous bandwidth offers) if it becomes popular without monetization. The true limiting factors for a web service is not bandwidth, but the number of possible connections per day and the number of simultaneous users a connection can support.

>For example, assuming you’re serving a 64kb text only page with no graphics and the page is transmitted within five seconds, which is 12,672 bits per second per user, the following is the breakdown on the number of simultaneous users you could support based on connection type.

>Dedicated PPP/SLIP : 2-3
56K (Frame Relay) : 10-20
ISDN (using PPP) : 10-50
T1 : 100-500
T3 : 5000+

>Choosing the Right Connection

And if you know anything about T1 and T3 lines, you’ll know that they’re still not cheap. According to T1Shopper the average cost of a T1 line varies between $550 to $1200 per month and the average cost of a T3 line varies between $7500 to $14,000 per month. Fiber is great if you can get, but just as expensive. Dedicated hosting solutions are definitely a cheaper alternative, but they tend to be short term solution and still outside of the pocket range of most Web 2.0 dabblers.

If there is any hope for the future, then there are only two options in this area. 1) access to higher upload connection speeds need to decrease in price dramatically or 2) incubation programs for Web 2.0 hopefuls must increase in number. Since I know very little about the technology that governs bandwidth, I’m going to focus on Option 2.

As I see it, entrepreneurs and academic institutions are in the best position to create incubation programs for budding Web 2.0 development projects. Incubation/seed programs like Y-Combinator and investors like Seth Goldstein have already helped to build the infrastructure for such Web 2.0 favorites as del.icio.us and Kiko. I’ve noticed, however, that most unviersity internet policies do not allow students to engage in business practices on the school’s connection. Even worse, they do not provide an outlet or vehicle for practicing these endeavors. While there are some student business incubation programs out there, I believe universities and colleges need to do more to encourage and aid Computer Science and Information System students to work together to build the future of the web. Academic institutions are in prime positions (due to the fact that they’re usually the early adopters of large connection backbones like Internet2) to realize the potential of Web 2.0. They also have everything to gain when it comes to prestige, research and even income if they offer the right intellectual property incentives.

Conclusion

That’s pretty much it for the talk. Everyone just needs to stop talking and start making things happen. Good luck and good building.