Category: platforms

Blogging vs. Twitter

writing.jpeg

Chris Shiflett and I were talking recently about blogging and how Twitter had sucked some of the life force of it out for both of us. Ideas that might have become blog posts were getting distilled down into 140 (and then 280) character tweets and something was lost in the process. Chris came up with a “tweet only links” philosophy (with some important exceptions) and I signed on. This is the essence of why in Chris’ words:

I’ve been blogging for more than 15 years, but I blogged far more in the first 5 years than in the 10 years since. While there are many factors, I think joining Twitter drove the decline of my blogging habit more than anything else. Now, if I have something to share, I’ll write a sentence or two on Twitter and be done. Twitter lets me scratch the itch.

If I have something to share going forward, my hope is that this commitment will compel me to blog about it. If I can’t take the time to explore a thought by blogging, I should link to someone else who has. Twitter can still be great for spreading ideas, but it’s not a particularly good home for them.

I love Twitter and have been using it since January 2007. It’s good for banter and (as Chris notes) spreading ideas but the core ideas have to live somewhere. As well-crafted as some tweet storms are, they essentially disappear into the ether after the signal-boosting stops. In June, I wrote a 14-part tweet storm about how to become a foster parent:

 

Unless you were watching me tweet on that day and were interested in becoming a foster parent at that moment, this tweet storm faded into the ether. It felt good to write and perhaps it inspired a person or two to take action, but it’s not a way really get the word out in a durable way. If I had blogged about it (and maybe I should), there’s a pretty good chance my post would show up in a Google search. I know this because after blogging for fifteen years, I still get emails about years-old blog posts but almost never get engagement on tweets that are more than a few days old. On Twitter, twelve hours ago is deep in the past and yesterday is ancient history.

I’m going to try to be more mindful about how I use Twitter vs. when I write things down in a blog post. There’s part of me that thinks we would all be better citizens of the web (and the world) if we adopted the philosophy that Chris laid out. We would have to think more about what we’re saying, string thoughts together more coherently, write them as if they will live on forever, and really commit. We would waste less time writing important but transient content that gets shoved aside in a matter of hours. We could write without worrying about Twitter’s policies or changes in the algorithm or the inability to change our minds by editing our original thoughts. We could fully own what we say in every sense of the word (this, of course, assumes blogging at a domain you own and Fred does a good job of explaining why that’s important).

It’s a totally selfish wish, but I also would love to see some of the dynamic new voices I see pouring their hearts and minds into Twitter write more long-form content in blogs. We need those voices and I worry that their considerable talents are muffled by putting so much work into content that is designed to be transient on top of all the work of defending yourself on Twitter. Twitter is a great complementary tool to writing and online engagement but it’s not the end unto itself if you want to create long-lasting, durable content on the web. I’m going to try to remember that going forward.

Comments are disabled. Feel free to respond my tweet about this post on Twitter.

Image credit: Todoran Bogdan

 

Facebook and platform complementors: history repeats?

The longer I am in this business, the more amazed I am at the new things being invented daily. In an attempt to stay on top of things, I try to train my critical eye for common themes and patterns that transcend the breathless Techmeme zeitgeist because they usually provide the deepest and most long-lasting insights. And so it is with all the discussions over the past several months about platforms. Some of the pathways we’re currently seeing around developer platforms like Facebook have been well-worn in the past by pre-web companies like Microsoft and Intel. As always, though, things are just different enough now to make me think that there are entirely new lessons to be learned. As the old Santayana quote goes, “those who do not learn from history are doomed to repeat it,” but in Silicon Valley, those who rely on their command of history too much often find themselves getting crushed by a 23-year-old who skipped history class in favor of a CS degree.

My mind starting churning about the evolution of technology platforms when I came across “Facebook Walks Fine Line with App Developers” in Charlie Wood‘s del.icio.us bookmarks. It begins:

Imagine spending a couple months building a Facebook application only to wake up one day and see it launched as part of Facebook’s core feature set. That’s what happened to Amin Ariana who built the Friendmates application. Amin launched a friend suggestion and soon enough it was launched on Facebook. While I think this service is an obvious feature that would eventually launch, Amin did not sound to happy in his email to News.com.

The News.com story quotes the developer, Amin Ariana:

“I believe the outcome of this and similar moves without appropriate repercussions in giving credit to developers who are coming up with innovative ideas will ultimately result in the discouragement of such developers and a diminish(ed) effect on innovative thinking,” Ariana continued. “I know change cannot be stopped, but along the way giving credit to the little people underneath will be a key to success against competition.”

This scenario most certainly feels like a new sort of affront to committed developers like Ariana, but it’s nothing new. For a thoughtful take on the same dynamic, replace “Facebook” with “Apple” and check out Nat Torkington’s post at O’Reilly Radar from nearly two years ago: “Where does the Apple stop and the worm begin?“. The dance between platform providers and independent third-party developers is tricky to say the least. It has been for many years and will be for many more.

This dynamic was discussed at length in 2002 (before Facebook!) in Platform Leadership by Michael A. Cusumano and Annabelle Gawer, except it was framed as “platform leader” vs. “complementor” (i.e. third-party developer). If you don’t have time for the entire book (and who has time for books when you could be writing a Facebook app *right now*?!), you can get the gist of it by reading “The Elements of Platform Leadership,” a distillation of key points in the book from the Spring 2002 issue of MIT Sloan Management Review (available for purchase for $6.50).

While the authors focused mainly on Intel, Microsoft, and Cisco, the discussion applies to Facebook and other platforms that didn’t exist way back in 2002. On page 54 (the 4th page of the article), a sidebar entitled “Advice for complementors” addresses the plight of the third-party developer directly, comparing the interaction to dancing with an elephant:

Is it possible to dance with the elephant — that is, to avoid getting crushed when a powerful platform leader decides to compete? If complementors commit resources to innovations, they should focus on products that the platform producer is unlikely to offer. They need to work at continuous communication because changes occur rapidly. Complementors need to keep alert to a platform leader’s product plans and try to get early information on a move onto their turf. They need to react quickly to demands; slow response may give a platform leader an excuse to compete with the complementor later.

Although platform leaders need complementors as a group, usually the balance of power between a platform leader and one lone complementor is tilted toward the platform leader. The trick to being a successful complementor is always to have peanuts to offer the elephant — to create products that continuously enhance the value of the core product even as the core changes.

Of course, the advice that the authors give in the article might fall just a little into the self-evident camp (“focus on products that the platform producer is unlikely to offer” “React quickly to demands”) and the devil is in the details. Generally, though, developers like Ariana shouldn’t see their role vis-a-vis Facebook as essentially different to developers on any other platform historically. That being said, while I would still argue that the rules of the platform game are roughly the same, the overall velocity and number of participants in the new platforms makes the game today inherently different. Engaging with platforms (i.e. writing code) has become drastically simpler and I can become a “complementor” to a platform in a focused evening. The pace of development on a platform can often be measured in hours and days (certainly not the months and years of yore), making it difficult at times for everyone just to keep up with the baseline activity around a platform — even the seemingly all-powerful platform provider itself.

Velocity changes everything. As the developers dance faster in this new environment, so too does the platform elephant. The faster the elephant dances, the more likely “the little people underneath” (as Ariana calls platform developers in the News.com story) could get unwittingly trampled in the process.

Update: Charlie Wood offers his perspective and summarizes: “Clearly, the trick to keeping any platform ecosystem healthy is to selectively incorporate such third-party developments into the platform itself instead of running roughshod over them. Mastering this process is critically important for any burgeoning platform provider.” I agree!

(Credit: Flickr photo by Kevin Hamm, Creative Commons license)

Fire Eagle!

A big congrats to the Fire Eagle team for launching the developer beta of the service today, especially to Tom Coates who is standing on stage in front of me at eTech making the formal announcement as I write this.

While the magic of Fire Eagle is primarily on the backend where developers play, the Fire Eagle site itself is a true delight (just like the team that built it). Beautifully done. I’m really proud of the team.

fireeagle.png

Ping me if you want invites. Those of you who have them, go forth and build some apps!

While we’ve been testing over the past few weeks, the FireEagle integration that I’ve enjoyed the most is the one done by the good folks over at Dopplr. After our announcement this morning, Matt Biddulph posted the details on the integration over at the Dopplr blog. If you’re a Dopplr user, read Matt’s post and link up with Fire Eagle here.

Jon Udell and Yahoo! Pipes

I read Jon Udell’s post about Yahoo! Pipes today in which he said of Pipes: It delights me! I’m not sure if Jon remembers this or not, but when I had him over to Yahoo! to give a talk last March, Pipes creator Pasha Sadri described the general concept (then just floating around in his head) to Jon in a really fun session after Jon’s talk. I happened to snap a grainy cameraphone shot of the exchange:

Pasha Sadri and Jon Udell

If Pipes is a milestone in the history of the Internet, this shot feels like an important historical artifact. As Tim O’Reilly wrote today, some of the concepts Jon has been talking about for years were realized in Pipes. Tim also noted:

. . . it really is amazing how easily we forget the details of the past, and how important it is for future history for us to keep our notes. It gives real perspective on more distant history when you realize how hard it is to remember the sequence of events, and who influenced whom. . .

I’m glad to have that shot to remind us.

Yahoo! Open Hack Day: how it all came together

I have to admit — since Hack Day ended, I have been struggling with how to contextualize it. It’s hard to put a nice neat wrapper around something that was so profound for me. For the people who were there (and you can read for yourself), it felt like a defining moment. The best way for now is to point out some of the people who made it happen and tell some of the inside story. In some later posts, I’ll probably go through some of the principles that guided us in planning Hack Day (e.g. who we invited and why, approaches to making such an event work), but for now, I just want to provide some backstory and point out some of the people who helped make this happen. There are literally hundreds of people in the mix, so I apologize in advance for those who I have missed. This will be my first attempt “official recounting” (as Bradley put it in his post). Like all good stories, some things will be left between the lines, of course.

Before I get into the narrative, if anyone out there is wondering how we pulled this off, I offer one clue: total pros rolling up their sleeves to do whatever needed to be done. I’ve always been surprised at how intelligent people ascribe self-limiting qualities to organizations that they don’t really have to accept. Large companies are “slow.” Small companies are “agile.” “They” would never let us do this. What happens when you work in a large company and you are able to leverage the size of the organization to form a lean-and-mean ad hoc team with broad expertise (technical, management, legal, security, networking, etc.) on a moment’s notice? Something pretty powerful — you turn the cynical “they” who won’t let you do anything into the unstoppable “we” that won’t take no for an answer. I learned that inspiration might be the world’s only renewable energy source and it scales like a motherfucker.

Hack Day and getting things done

Beck checking out the hacksIt’s really easy to lose sight of the fact that in all the excitement of having a rock star like Beck on our campus, our Hack Day efforts (internal and external) help us get lots of real things done. We launched a ton of new stuff. Don’t take it from me that Hack Day creates results, though. Ryan Kennedy writes of our last internal Hack Day (where he won a “Technically Sweet” award for a kick-ass hack that used the Yahoo! Mail API that we eventually previewed for Open Hack Day attendees): “It [the internal Hack Day on September 15] was the event that reinvigorated my efforts to get mail ready for show time.” Ryan’s post crystalizes for me the clear relationship between our internal and now external Hack Day efforts. Ryan built the Mail API, then gave it a spin at our internal Hack Day with his winning hack, then spent the next couple of weeks refining it before giving a talk about it at Open Hack Day. Then he stepped down from the podium and spent his next 24 hours working alongside our visiting developers to build hacks using the same API (for which he got some shout-outs from the stage — read Ryan’s post for more info). Four cool hacks were produced by external developers with this brand-new API (see the list of all the hacks). If this isn’t a very good thing, I don’t know what is — this is the web ecosystem in action. Hack Day works.

The birth of the concept

As Bradley said in his keynote, we decided to do this just a few weeks ago, really, though we were inspired by the experience of doing seven internal Hack Days on three continents (the photo at right is of me at the beginning of the very first one). To get started on the first public Hack Day, I set up an Upcoming page and when I had to choose the category, I chose “festival” for a reason. I didn’t think the world needed another tired developer conference in a too-expensive downtown hotel where we stood in a booth and handed out t-shirts while our attendees racked up double-digit mini-bar bills just because they wanted a Diet Coke in the morning (more on this in a later post, I hope). We didn’t need that stuff anyway — we’ve got an awesome campus with a lot of space, tons of classroom space, a fat pipe to the Internet, beautiful lush corporate green grass, a cafeteria that could house and feed an army, and thousands of multi-talented people. So we launched HackDay.org on August 25 and posted these words:
First Hack Day at Yahoo!

We’ve opened up Yahoo! from the inside out with our world-renowned Hack Day and from the outside in through the Yahoo! Developer Network. Now we’re opening up Yahoo! itself to a select group of hackers and other special guests for a weekend festival of hacking, camping (yes, the tents-in-the-outdoors kind – we have really, really nice grass), music, and good times.

Yahoo! Hack Day will begin on Friday with a free all-day developer workshop, then we’ll kick off a 24-hour Hack Day with an outdoor party into the wee hours, with special guests providing the soundtrack. More details later, but we guarantee it won’t be your usual corporate-wedding-band-for-hire leading the crowd through 2am group sing-a-longs of “Brick House.” Stay tuned.

Yahoo! Hack Day will continue throughout the night (in tents, in URLs, our cafeteria) and conclude on Saturday afternoon/evening with judging from a panel of luminaries and special awards for the coolest hacks. After nightfall we’ll close things out with another round of entertainment that you would be happy to pay for, except that you won’t have to.

I wrote those words, and it was both the vision and the project plan. The only thing was that we had no entertainment lined up and nothing else worked out, just an idea of the environment we wanted to create — that’s it. That was barely four weeks ago!

Punk rock

After we got the idea rolling, I sent an email out to our internal Hack discussion mailing list (something I seeded after our first internal Hack Day in December of last year) and said, “who wants to help put together a public Hack Day?” Within a few days, I had about 80 people ready to help: engineers, product managers, business development, attorneys. . . . name a function and we had someone step forward. No coercion by management, none of the browbeating you might see in a typical corporate environment, no silly corporate brainstorming exercises, no discussion of “branding,” no PowerPoints (not one!) We had one planning meeting to kick things off (it was our first and last meeting), and pretty soon, I was standing back and watching the magic. People stepped up. We needed t-shirts, and they appeared. PR pros called BBQ vendors to arrange food. Some of the world’s foremost CSS experts stuffed welcome packets. Hard core backend engineers offered themselves up as low-level tech support for the hackers doing their demos. I talked to our totally awesome facilities team about our grass and the sprinkler system (needed to make sure the ground wasn’t too squishy for the campers). At one point when we were setting up the wifi network on Thursday, the guys needed 200 zip ties and several hundred feet of ethernet cable. I sent an email out to my list of volunteers and within the hour, it all appeared (thanks, Kent). Punk rock.

This kind of thing happened over and over and over. It was magical to watch.

Thank yous

It’s an impossible task to get this right, but there are some specific people I wanted to thank. First, there’s Bradley. When I moved over to YDN, we started talking about a public Hack Day almost immediately and the idea started crystalizing. I honestly don’t remember exactly how the “crazy” Beck idea came up, but when it did, it was Bradley who gave me that patented Bradley look that said, “dude, this is TOTALLY POSSIBLE!” and quietly lit the fire under me to make it happen. I’m hoping that everyone out there has a boss like this one day. (It’s cool that Nina caught me taking a shot of Bradley with my Treo while he was doing the Filo-to-Beck intro). Some of my fondest memories of this whole process were high-fiving Bradley in various meetings as we started to get the sense of what we were planning. We just couldn’t wait to share what we were doing with the world. Thanks, Bradley, for making work so fun.

Kiersten Hollars (in the far right in this photo) totally rocks. Bradley gave some props to Kiersten in his post, but I just can’t say enough. Her official job is PR, but if you had a slice of pizza or a doughnut during Hack Day, Kiersten is the one who made it happen. That’s not to say that Kiersten was diminished to phoning in food orders because she is an absolute pro at what she does. She just wasn’t afraid to dial Domino’s when we needed it and that’s why this whole thing worked. I won’t deny that getting this done had some stressful moments, but Kiersten and I kept each other calm. Kiersten doesn’t write code, but she’s an amazing organizational hacker. Rock on, Kiersten.

Once we got the verbal commitment from Beck, Jackie Waldorph (photo) and Christy Garcia on our events team took that ball and ran with it, dealing with the production issues, the stage, the sound, security, and anything else related to the show. It was a gargantuan task that had never been done before. One of my favorite moments happened about half an hour before the show was to begin when I ran into Jackie and she said, “Now that he’s here, Beck says he wants to do a longer show.” Well, OK!

The YUI team put the whole excellent Friday agenda together along with Dan Theurer on the YDN team. In one of the key roll-up-your-sleeves moments, Eric Miraglia (photo) brought a wagon from home to help move welcome packets, schwag, and anything else around that needed moving. A wagon hack! Eric’s contributions were immeasurable, as were his entire team (led by Thomas Sha, who was enthusiastically involved from the beginning).

To the extended Open Hack Day Team, you guys totally rocked — all 80+ of you. And a gigantic thanks to the YDN team that I am so freaking proud of: Dan, Kent, Matt, Jeremy, Jason, and Vernon. It’s hard to believe that this team really just started working together.

A big thanks to Tara Kirchner, whose various acts of heroism made a lot of the key ingredients for Open Hack Day fall into place. Micah Laaker gave us the logo after we told him we were stuck and had 20 minutes before we had to send a design to the printer, or no t-shirts.

For setting up our high-performance wi-fi network from scratch for all the visiting hackers, Tim Stiles (photo) and Tom Keitel (photo) deserve HUGE props. I also have to give a big thanks to our security team (network and physical), but I can’t discuss what they did or they would have to kill me. 😉 I used to be totally immersed in the world of enterprise IT, so I know IT rock stars when I see them. These guys fit the bill.

No one deserved this photo with Beck more than Nicki Dugan. And to that certain skateboarding hacker in our midst — thanks, man.

Mike Arrington was an excellent moderator. Keeping the demos moving is more grueling than you might think, and he handled it with great humor and skill.

As Bradley mentioned in his post, this crazy idea quickly gained support at the highest levels of Yahoo! and we appreciate it. David Filo outlasted nearly everyone on Friday night, and I was inspired by all the other Yahoo! execs who hung out with the hackers. Like Bradley, I also want to give a shout out to Jeff Weiner, the man who cleared the way for our very first Hack Day and helped us grow it at every turn. And to Ash Patel for encouraging us to make it even bigger when we moved into his organization.

new Canadian friendsLast but definitely not least, I wanted to thank the hackers who came out. You guys came from far and wide with nothing but faith that you were going to have a good and productive time partying and hacking with us. I’m pretty sure I’ve read everything anyone has written about Open Hack Day and I am more inspired than ever by your feedback. It’s a real honor to have put this together for all of you and I’m looking forward to seeing you around. (Remember, all the “winners” are listed here — but everyone was a winner. Seriously.)

Beck

And then there was Beck.

One of the hardest things about putting this whole thing together came when I was on the phone with Beck’s agent and manager very early on and they asked me if Yahoo! had ever done something like this before. I swallowed any indie cred I had built up in prior conversations and said, “Well. . . . we had Sugar Ray once.” Silence. “I’m really sorry I had to say that.” They sensed my pain at bringing that up and graciously moved on to the business at hand. All I know is that it’s gonna be a hell of a lot easier next time when I can say, “we had Beck last year.”

For the record, Beck’s entire team was incredible to work with, from the puppeteers to Beck himself. Beck could have jumped in his tour bus after the show and fled the building (especially since his dressing room was our gym), but he hung out and talked with us, even making some rounds to check out the hacks after the show.

The puppeteers were so impressed with us, that we converted one of them to Yahoo! Search. Read the comments on this post:

you yahoo’s were all amazing! if only you had a need for puppeteers on staff…i’d so be there!

for the record, you all have been so great…i’ve switched over to yahoo for my homepage search engine. it’s a little thing i know…but i do what i can.

Getting Beck was not so much about getting a “big name” (though he admittedly was), but more about bringing someone in who we saw as a hacker. Some people hack music and some people hack software. Some people even hack puppets. Mixing all of that up was one of the great joys of the event (aside: a special shout out to Jonathan Grubb and the Rubyred Labs guys for their help with the video). We saw Beck and his band as participants in the whole event, not just a stage show.

Love and community

Susan does an excellent job of connecting Hack Day back to Burning Man, FOO Camp, etc, and I’ve listed some of my own inspirations in the past. The interesting thing about Hack Day to me is that the spirit behind it all lives every workday in the halls of Yahoo! The best thing about Hack Day is that when it was over, I went back to “normal life” working alongside the same people who made it happen. It’s too early to tell what this all means yet, but for us back at Yahoo! this is at least different from the “temporary community” of a Burning Man.

Ultimately, I think the reason this worked so well and people were blown away by the event is that we took the genuine love we feel for each other and our joy in working together and we reflected it out to the hacker community, and they gave it back to us. If you’re the cynical type and you’re thinking, “yeah, whatever,” then don’t take it from me. There’s Ben Metcalfe’s post and many others but my favorite was Kristopher Tate’s post about the Yahoo! “family”:

I think the best thing that describes Yahoo! is family — Yahoo is an amazing, close family that was gracious enough to open themselves up to over 450 outsiders (including myself) over the last two days from the lowest levels to the very top.

Perfect. See you again next time.

Loads of new stuff from Yahoo! Developer Network for Open Hack Day

Lest you think our Yahoo! Open Hack Day was all about Beck (yes, it was really cool to have him), we also released an incredible stream of stuff for the hackers to play with while they were hanging out with us at Yahoo! There is nothing like a big event with a hacker rock star to mobilize the teams at Yahoo! to tackle the last 10% to get those releases pushed out! Here’s the list. This has been covered in many places already (I was happily buried with Open Hack Day stuff instead of blogging):

  • Browser-based authentication, or BBAuth: This is big. As Dave says, “If it’s easy to program, and delivers on what it says it does, this is a huge deal.” Agree or disagree with Dave, you have to listen. (see the YDN blog post and Dan Theurer’s post as well. It was Dan’s focus and tenacity that got this thing out. Thanks Dan!)
  • Yahoo! Photos API: combined with BBAuth, you can now write applications that have read/write access to users’ photos when they grant your application permission to work with their images. More on the YDN blog.
  • Upcoming PHP5 wrapper: Check out their post for all the details, but they delivered a PHP5 wrapper for their API and a couple of new method calls. Rock on (they’re hiring, too — Guitar Hero excellence preferred, but not required. Check out this photo of Beck with the giant Guitar Hero screen the Upcoming guys set up for Open Hack Day in the background).
  • Flickr support for JSON and Serialized PHP: Read all the details in Cal’s post to the yws-flickr group.
  • .NET Developer Center: A shout out to you Microsoft fans out there. Check it out.
  • Yahoo! Mail API: We gave everyone who came to Open Hack Day a crack at this API. Stay tuned for general release in a few months. This one is really exciting. Check out the News.com story for where things are headed.

The Yahoo! Developer Network team and our partners in the product teams around Yahoo! rocked harder than Beck did on Friday night to get this stuff out and put on our Open Hack Day, so the credit extends to hundreds of people inside Yahoo! for getting it done and to all the incredible hackers who jumped right in, built stuff (often side-by-side with the developers who built the APIs they were using), and gave us immediate feedback.

I’m totally sleep-deprived right now, so I’ll save any extended commentary for later — but the past few days have been among the most memorable and exciting in my life. It’s been that good.

Sex and Linux at Salon in 1999

I got a nice surprise in my inbox recently from Kent Brewster, one of my compatriots at YDN, when he saw the plea on my home page for a copy of my long-lost presentation at 1999 OSCON, Sex and Linux at Salon, which I did along with Jeffrey Radice, my partner. I knew it would turn up somewhere, but I feel a little silly now because it was sitting on the servers I used to run and I never tried Salon’s local site search. Oh well. I didn’t even remember the presentation being web-based, but it pleases my 34-year-old self that my 27-year-old self made that choice instead of PowerPoint.

So, why “Sex and Linux at Salon?” What did sex have to do with Linux? Some background, and it all starts to make sense. From 1996-98, I worked at CNN.com and CNNSI.com in Atlanta. Feeling the call of the west coast, but wanting something a little different than a run-of-the-mill Silicon Valley job, I responded to a job posting on Salon’s site for someone to lead the technology operation, emphasizing (if I remember correctly) that I was the perfect candidate for them: a wayward English major who had dropped his Shakespeare studies in favor of Unix and web development. (I later learned that this wasn’t so unique!) They called me back and I flew out to San Francisco and immediately fell in love with everyone at Salon. I made immediate plans to move and arrived in the summer of 1998. Once the new-to-SF buzz wore off, though, I found a technology operation in utter disarray. The servers were super-flaky NT boxes, there were no good backups, etc. At CNN, I had worked with what I’m certain was the best web operations team in the world at the time, so I decided to take some of the principles I learned there and crafted a plan to stabilize everything at Salon. I was a Unix guy anyway (Solaris mostly), so I knew the NT servers were not long for my world. All I needed was a little time.

To put it mildly, the summer/fall of 1998 was not a quiet one for a left-leaning San Francisco web site with a strong political point-of-view. As I was putting my technology plan together in my first weeks on the job, the Clinton-Lewinsky scandal was heating up, and Rep. Henry Hyde, head of the House Judiciary Committee, was leading the charge towards impeachment. The Starr Report was released. Salon had been in the fray from the beginning, offering (I think) a voice of relative reason in all the craziness. It was a great time to be at a place like Salon in San Francisco, and that summer and fall were some of the most memorable days of my professional life. I had no idea, though, about the tsunami that was about to hit Salon.

Salon really inserted itself in the fray when founder and editor-in-chief David Talbot decided to run old black-and-white photos of Rep. Henry Hyde with a woman sitting playfully in his lap — a woman with whom he had had an affair some thirty years earlier. I remember when the photos were unveiled in the office before we ran them. This was undoubtedly below-the-belt journalism, but those were below-the-belt times. When the photos and the story were published, we ran a story with our justification, “Why we ran the Henry Hyde story.” When I hear about the Clinton impeachment process, these words still echo through my mind:

Aren’t we fighting fire with fire, descending to the gutter tactics of those we deplore? Frankly, yes. But ugly times call for ugly tactics. When a pack of sanctimonious thugs beats you and your country upside the head with a tire-iron, you can withdraw to the sideline and meditate, or you can grab it out of their hands and fight back.

Anyway, to get back to the relationship between sex and Linux. . . . when we ran the Henry Hyde story, historical events overtook my thoughtful technology plan and I was stuck rebooting NT servers all day to keep the site up. Salon was denounced on the Senate floor — I rebooted the servers. The Salon story led all the network nightly newscasts (back when they still mattered a little) — I rebooted the servers again. Death threats, bomb threats, black faxes (my first experience with those) — more server reboots. A representative’s sexual indiscretions 30 years earlier led me to one conclusion: Linux. That’s where the “sex and Linux” connection became clear. We accelerated our migration plans after that day.

It seems a bit strange now that something like our little NT-to-Linux migration garnered so much coverage, but it did: Slashdot, Webmonkey, News.com, and PC World (in which I was somehow interviewed in a story about Xeon servers. Hmmm.) This coverage was largely driven by a press release that I authored along with our marketing department, with the bold title: Salon Adopts Linux as its Enterprise Internet Server Platform. That was really a fancy way of saying that a very small group of people stayed up for a few weeks straight dealing with all sorts of unforseen issues, but we ultimately completed the migration. We ran into lots of stupid issues, the case-insensitivity of the NT filesystem versus the case-sensitive Linux filesystem being one of them. We used a Windows tool on the NT box to make a tarball of our content (which was all flat files, no database backend at that point) and when we untarred it on the Linux box, the filenames were all funky: logo.jpg was LoGO.Jpg and things like that. Nothing that a simple Perl script using lc to rename all the files wouldn’t fix.

The coolest thing about our migration is that due to our constrained funds (Salon never seemed to be rolling in cash, at least for technology, while I was there and we were relatively frugal anway), we didn’t have a bank of new Linux boxes to migrate to, so we literally wiped NT off the boxes one-by-one and rolled out Linux on them until there were no more NT boxes. We never missed them, not even for a second. I don’t think I’ve done anything serious with an NT box since.

Asterisk is the new LAMP

I met with a startup today that does some interesting work bridging web services APIs with telephony, and I stopped them early in their presentation to ask what their voice platform was. The discussion was purely about their service, not the backend nuts-and-bolts, but I just had to ask: “Are you using Asterisk?” They were, of course. (I became interested in Asterisk and wrote about it just over a year ago in one of my last InfoWorld columns. There’s also an O’Reilly book on Asterisk that was published last fall).

I suspect that the “yeah, we’re using Asterisk” answer will become as commonplace and unremarkable as the “yeah, we’re using the LAMP stack.” Very cool. Expect some amazing things in this space as developers dreaming of new voice applications start playing with Asterisk more broadly.

Microformats are huge at Yahoo!

From the Yahoo! Local blog (which is itself new), a massive announcement about Yahoo! support of microformats:

Starting today, we’re happy to announce Yahoo! Local fully supports the hCalendar, hCard, and hReview microformats on almost all business listings, search results, events, and reviews.

In sheer volume, I’m pretty sure this means Yahoo! Local has the largest implementation of microformats on the web. In a broader sense, I think Yahoo! continues to lead the way in opening things up in big-bang ways. Good job, Vince, Andy, Ronnie, and Yahoo! Local team.

Reading 2.0 and microformats

Yesterday, I participated in the Reading 2.0 summit (organized by Peter Brantley of the California Digital Library), a small gathering in San Francisco about the future of digitized material, with the digitization of books being a primary topic. Tim O’Reilly did an amazing job of taking notes.

As Tim notes, I gave a short presentation about microformats at Yahoo! (borrowing heavily from Tantek Çelik and microformats.org, who I credited in an intro slide before I even got into the topic). Since my slot was a brisk ten minutes, I decided to briefly talk about what microformats are, but then go straight to the markup. This approach seemed to work a few years ago when I found myself explaining RSS a lot. I always found that pulling up an RSS feed and showing the the simplicity of the feed itself got the point across that RSS was not particularly complex. I think microformats are similar in that regard.

An interesting question came from Cliff Lynch, who asked if it might be possible to use microformats to mark up genomic information. I have to admit that I don’t know much at all about genomic information, but to the extent that this type of information is on the web, decentralized, and can be structured consistently (preferably modeled after an existing standard, as hCard is modeled after vcard), I don’t see why not. That’s the beauty of efforts like microformats — anyone with the ability to publish to the web now (which is everyone) can participate in creating a microformats standard by putting it into practice and sufficiently documenting it. hGenome, anyone?

For more on microformats, you can see a presentation that Tantek gave on a recent visit to Yahoo, and microformats.org. There is also a microformats-discuss mailing list.

An easy way to get started with microformats is to use the hCard creator to build your own hCard (see my hCard).

Again, be sure to read Tim’s notes. Really cool stuff.