Ludum Dare is an online game development contest based around 48 hour competitions. It celebrates its tenth anniversary this year. It's recently had a publicity boost because Notch, the creator of the mind-bogglingly popular indie game Minecraft, has been taking part (although he might not be doing it this time, alas).
How to Take Part in Ludum Dare
During the 48 hours, you can post blog entries directly to the main Ludum Dare site (if you want) and submit your entry via a special link at the end. Entrants play and judge each other's entries for a period of three weeks before the winners are announced.
The Basic Ludum Dare Rules
There's a proper rules page but the basics are:
- You have to work alone. (If you want to do a team effort, you need to enter the less restrictive 72 hour 'jam' contest.)
- All content and code must be created within the 48 hours (except for libraries, legally licensed fonts and drum/instrument samples).
- Your game has to be based on the theme given out at the start of the contest (though you can be creative with this).
- You must share the source code with the other participants at the end of the contest though you do not have to give it an open source license.
Super simple. Don't cheat, build something, submit it at the 48 hour mark :-)
The Ludum Dare Community
The contest has a popular IRC channel (which is already active) at #ludumdare on irc.afternet.org. I'm petercooper on there - say hi! I'll be lurking in there a lot. Also, follow @ludumdare on IRC for more updates and info if you're into Twitter.
To get a feel for the contest, check out this "keynote" from a recent Ludum Dare. There'll be a new one for this year soon though:
But What If I've Never Developed A Game?!
A common point! Lots of people enter Ludum Dare without having any game development experience. That's much of the point. Your goal is to spend 48 hours enjoying learning new things and producing whatever you can. If you strip things down to the bare essentials, it's amazing how quick you can come up with a simple game, and you can then make it more complex with the extra time you have. Just make something and learn along the way.
What Will I Be Doing?
While doing some last-minute research for Self Promotion for Geeks (it's close, I promise) tonight, I came across a talk Michael Arrington gave at Startup School 2008 on "how to get press for your startup" (or how to get TechCrunch to write about you ;-)).
It's a solid talk and still highly relevant despite being 3 years old. What stood out, though, was part of Michael's answer to a question about how he and TechCrunch were going to use his resources to take the startup/tech community to the 'next level':
What I'd really love to do, personally - which isn't the best business decision - is I'd love to let Eric, my co-editor, continue to write TechCrunch and I'd like to go start another blog that does nothing but writes about startups, like the true startups, really every one, again for the core audience. Because I wrote about almost every startup in the early days because the community wanted to know about every single one even if they weren't that interesting.
And today the audience won't put up with that, so 90% of the startups maybe we would have written about three years ago, we aren't able to write about. I miss that a lot. Now that isn't what's right for our business. What's right for our business is to keep trashing CNet, trashing Wired, trashing all the big media, and attacking them as much as possible, peeling off as many of their writers as possible, and then selling for a big multiple of earnings, and that's certainly what Heather wants to do, our CEO, which is why I hired her to be that person, but there's always a struggle because if we ever lose sight of what we love, we won't be very good at what we do anymore.
I remain an unashamed fan of Michael's because I started to read TechCrunch early on, loved his style, and he even got in touch to cover my startup at the time. But as time goes by, both he and TechCrunch get more criticism and it now seems almost trendy on Twitter, Hacker News and Reddit to piss on his bonfire whenever the opportunity arises.
What struck me, though, is that Michael was transparent with the direction he was taking TechCrunch even back in 2008 and that it was entirely a business decision, not one based on any stupidity or malice on his part as commonly implied. He saw an opportunity for his business, steered it in a different direction and, yep, two years later they were acquired. That's the sort of success any budding entrepreneur could get behind, right?
Will Michael ever follow through on his earlier ambition and get back into the game for the 'core audience' busy slamming TechCrunch's newer direction? Or has he been beaten to the punch by The Startup Foundry? It's a fine substitution that evokes the spirit of the early TechCrunch.
The unexciting answer is.. probably not for some time. When explaining why he sold to AOL, he said:
So we begin another journey. I fully intend to stay with AOL for a very, very long time. And the entire team has big incentives to stay on board for at least three years.
He also spoke of his exhaustion after five years of hectic TechCrunch work but I refuse to believe he'll be sitting at AOL for many years to come. There's too much to do and too much to say without playing second fiddle to Huffington. Barring contractual obligations, he'll be "back" surprising us yet again within the year. I betcha.
Starting January 10, 2011, I'll be teaching an online Ruby course through CodeLesson.com. It lasts 4 weeks and covers everything a novice developer (or merely a novice Rubyist) would need to know in order to become a confident, intermediate level Ruby developer. From the course, you could easily move on to more advanced Ruby stuff, on to Rails, or even go looking for a Ruby job.
Topics I'll be covering include:
- Installing and running Ruby
- Using the interactive Ruby shell (irb)
- Looking up Ruby documentation and help
- Expressions and variables
- Built-in data types (strings, arrays, hashes, etc.)
- Flow control
- Classes and modules
- RubyGems and library management
- File handling and IO
- Basic metaprogramming
- Web and network access
- Producing documentation
- The Ruby community and how to benefit from it
- Ruby project structure
- Rack and Sinatra (to produce basic webapps)
- Building and releasing a gem (optional)
- RSpec (optional)
The course is very asynchronous. You don't need to be online at certain times. Most of the work will take place through reading content I provide (including sections from my book Beginning Ruby - which I'll be giving to you for free), things I link to (where there authoritative, well-suited examples), or through watching videos I've recorded for the course (here's an example). There will also be forums where topics are discussed, problems are resolved, and so forth. I'll also be running some "surgery hours" on systems such as IRC or possibly Skype so that participants can have a more real time experience - particularly well suited for problem solving or walkthroughs. The timing of these will be determined as to the participants' various needs.
The course costs $295 for the 4 weeks (though there's a nice discount for group signups) and the main value comes from having access to me, asking me questions, and letting me walk you through particular sticking points. You can also be sure that the content I provide or link to is also up to date and well suited for learning Ruby in 2011 - that's the sort of reassurance no book can genuinely offer given how quickly things change in the Ruby world.
So, interested? Or have a boss/coworker/similar who'd benefit? Check out the Ruby course page on CodeLesson.com for more info. If you join the course, I'll see you next week!
We've all seen domains people have forgotten to renew. A high profile one was rubyonrails.org in 2009. We chuckle and think "Oh dear! I bet I wouldn't forget something like that!" but it turns out that some registrars will cut you off without you forgetting a thing..
On December 31, 2009, I came up with a name for my new coding news site - coder.io - and registered the domain name at Moniker.com. Few registrars do
.io domains and Moniker seemed the most reputable. As their control panel and their frequent update e-mails stressed, coder.io expires on December 31, 2010, so I had it in my calendar to renew mid-December.
Today (December 5, 2010) I received several tweets and e-mails from users asking why I've taken coder.io offline and lamenting its loss (aww!). I went to
http://coder.io/ and saw a "parked domain" page full of ads:
I looked up the WHOIS record (all fine and dandy) and logged in to Moniker's control panel to work out what had happened:
The Moniker control panel showed the expiration date as December 31, 2010, yet had it listed in the Pending Delete section. This is where domains go when they are not renewed by the renewal date but not 26 whole days before! The only solution available was to renew the domain immediately - so I did. Despite that, over an hour later coder.io is not working, though it's not going to a PPC ads page anymore at least - I hope it will burst back into action soon.
The crux of the matter, though, is Moniker deactivated a customer's domain name 26 days before renewal was due. If you're thinking of using Moniker or use them already and want a proper registrar, for most TLDs I'd recommend NameCheap, as they've been good to me and I have many tens of domains there. For .io domains? I'm stuck at Moniker for now but I Want My Name has been recommended to me and I'll be checking them out once the dust settles.
P.S. I'm not looking for general registrar recommendations - I like NameCheap! But if you have a .io domain and are happy with your registrar, I'm all ears.
Update 1- Moniker Replies and their Terms of Service
It was suggested that I hit up Moniker's customer service agent on Twitter - @MonikerSnap. So I did, and I got a response too (credit to them for being helpful, at least):
The link is to Moniker's Domain Name Deletion and Auto-Renew Details page. It explains little. It's basically a chart of times for different TLDs that Moniker will process an auto-renewal (if you have this turned on - I don't) and when Moniker will "delete" domains. For .io, the auto-renewal is 60 days prior to expiration and the deletion is 6 days prior to expiration.
I take issue that a registrar has the right to delete a domain name prior to the expiration date, as that makes a mockery of what an "expiration date" is. But ignoring that, 26 days still isn't 6 and even Moniker's own Terms of Service that I agreed to demonstrate Moniker's violation (from paragraph 6 - emphasis is mine):
You agree that after the expiration date of your domain name registration and before it is deleted or renewed, we may direct your domain name to an IP address designated by us, including, without limitation, to an IP address which hosts a parking, under construction, or other temporary page that may include promotions and advertisements for, and links to, Moniker's Web site, Moniker product and service offerings, third-party Web sites, third-party product and service offerings, and/or Internet search engines and/or advertisements, and you agree that we may place our contact information in the WHOIS output for the expired domain name.
I agreed that after the expiration date, they can do the typical registrar thing of redirecting my domain name to their parked domain advertising page, not 26 days before. Moniker's TOS stands for nothing.
Moniker's Domain Name Deletion and Auto-Renew Policy provides no more defense for them. They state:
At Moniker.com, domain names are registered for fixed periods and are subject to renewal any time during a valid registration prior to the domain registration expiration date.
I had planned to renew mid December and this is clearly "prior to the domain registration expiration date" of December 31, 2010. They also state:
If a customer does not renew a domain name registration by the expiration date, the registration may be subject to deletion [..]
Perhaps Moniker or someone else can prove me wrong, but I can find no basis for them to deactivate people's domains 26 days before they even expire.
P.S. It's now 6 hours after I renewed and Google's DNS is still returning the IP for Oversee/Moniker's parked domain server. Not cool. We've now been "down" over 14 hours. However, OpenDNS's cache checker and more direct querying yields success. Maybe this part is a Google issue..
Update 2 - My Theory
I suspect that because the
.io TLD is managed by a small, independent registry, registrars like Moniker have to fit in with weird payment terms or even file renewals and registrations by hand. Given this, Moniker would prefer to auto renew you 60 days prior to expiry in order to guarantee they have the money in hand for the process. I can sympathize with this and if I'd had an e-mail noting my domain was not safe to the expiry date, I'd have renewed early. But I had no such e-mail and their TOS do not, by my reading, reflect this possibility.
There's an awesome YouTube user called DJDiscocat. I don't know who he/she is but he uploads videos each day that are recordings of his vast disco and soul vinyl collection. Given my interest in these genres, I often want to get the songs as MP3s.
Till now I've been using the Download YouTube Videos as MP4 GreaseMonkey/GreaseKit script and converting the videos into MP3s using Quicktime 7. A bit of a pain in the ass though. But now I've discovered a much easier way.
I'm not going to get into the details of how to do this but for FFmpeg on OS X, I just ran
sudo port install ffmpeg and it went fine (I have MacPorts installed). I tried Homebrew initially but the build failed. And youtube-dl is just a Python script you can download, do a
chmod +x on and move to
/usr/bin/youtube-dl or similar.
The actual process
Step 1 - Find your video. Find a video you want to download and grab the basic URL for it. For example:
Step 2 - Download that video. Once youtube-dl is running, it's as simple as:
youtube-dl --title "http://www.youtube.com/watch?v=BVgM7qeAlko"
Naturally you'd replace the URL with that of the video you want.
Step 3 - Convert that video into an MP3. Now you'll have a
.flv file sitting around with the video in it. Time to use ffmpeg to convert it to a usable MP3. Simply:
ffmpeg -i flv_filename.flv -ac 2 -ab 160 output.mp3
And, as we say, Bob's your uncle.
Hacker Slide is a new miniapp I launched this morning after a few hours of development (rounded up to 4 after doing a little design work on this this afternoon). It lets you view the Hacker News front page over time with the time selectable with a slider so you can see stories come and go.
Hacker Slide was an off the cuff idea blatantly ripped from Reddit Snapshot. After the fad of producing "Instant" sites after YouTube Instant launched, I knew someone would probably make an HN Snapshot site pretty quickly so I decided I wanted to be that guy this time.
Initially I had it only crawling once per day but I realized I wouldn't be able to show it off for at least a few days if I kept it that way so I switched it to hourly and went to bed. On waking there were about 8 hours of data ready to "slide" through.
In retrospect, hourly works great because Hacker News's front page moves so quickly and it's useful to scan back hour by hour to find things that I missed while asleep/working/whatever. Hopefully some of you will find it useful for the same reason.
This afternoon someone posted Hacker Slide to Hacker News so I followed up by posting it to the Hacker News Facebook group and it went from there. It's only been a few hours but it's had around 3000 visitors so far and the feedback is generally positive (though people want to see how the items move around over time more elegantly - I'm still thinking on how to do this). I've also released the source onto GitHub.
So that's it. Nothing too intense. Just seeing someone else's idea, being inspired, and rolling out a "miniapp" after some Googling and head scratching. It's not just a great way to stretch your coding muscles but a good exercise in short term discipline or even a way to promote yourself - just ask Feross Aboukhadijeh about that.
It's been 6 weeks since I launched Ruby Weekly, an e-mail newsletter for Ruby developers. It's gone well and I've learned and observed a few things.
Subscriber numbers. I previously wrote about how I got 1120 subscribers in 2 days and the subscription rate has tailed off since then. It's now up to 2173 subscribers and I'm happy with that. My short term goal is 3000 subscribers at which level it'll make sense to explore advertising options.
Between August 27 and October 9, 2010, the subscriber count has gone from 1120 to 2173, a growth of 1053 subscribers. In the same period Google Analytics reports 1910 visitors to the site. Even though subscribing is the only thing you can do on the site, this strikes me as a high conversion rate (55.1%).
Kudos. I've had several e-mails and seen quite a few tweets with compliments about the newsletter, its format, and its content. This sort of recognition doesn't come with all of my projects so it's delightful to see and I appreciate it a lot. Knowing that people are "invested" in the project encourages me to maintain a high quality.
Open rate. The "open rate" of a newsletter is the percentage of people who are known to have opened it. MailChimp detects this through an invisible graphic added into the HTML version of your e-mail but, I believe, also through clicks on links where people have images turned off (and if you have link tracking turned on). This has averaged 66%.
Clicks. Ruby Weekly issues typically have about 8-10 links and on a mailing to ~2000 people, I've seen between 2000-2700 outgoing clicks in all. This isn't mindblowing but is far above average compared to MailChimp's stats. I suspect if I were reading Ruby Weekly I'd only click on a couple of the links so I'm reasonably happy with this.
The "weakest link" so far was to Ruby and Rails, an event in Amsterdam. I've had poor luck with linking to events on Ruby Inside so this didn't surprise me. From 2000 subscribers it got only 54 clicks overall. This isn't as gloomy as it could be, though. Those 54 visitors are obviously interested in the event and if Ruby and Rails were paying $100 to be in that mailing, say, then even picking up 4 or 5 registrations would be a good return.
Location. Subscribers from the United States by far make up the lion's share of the subscriber base. Taking a recent mailing, there were 964 US opens, 192 in the UK, 93 in Germany, 85 in France, 85 in Canada, 61 in Australia, 50 in Poland, and it tails off from there. I was surprised to see China outweigh Japan significantly at 41 to 16 but Japan seems to have its own sources for Ruby news.
Content. I've had nothing but compliments on the content of the newsletter which strikes me as odd because it's been so haphazard. For one issue, I was on vacation so I wrote 80% of it before leaving and just added a couple of news items on the day (while working over a horrible GPRS connection). No complaints and click rates remained level.
What has surprised me is that the most successful links are frequently to the "Cool but not Ruby" type sections I add when I find a link that might interest Rubyists but isn't necessarily about Ruby. One example was a news announcement about the Amazon EC2 micro instances. It seems there's an appetite for more general open source development ecosystem news than a "Ruby newsletter" should be providing. I am considering branching out to fill this void.
I'm a dabbler in the tiny, yet barely profitable, "developer news" industry with my sites Ruby Inside, Rails Inside, RubyFlow, Mobile Orchard and coder.io. Yesterday marked the launch of my latest experiment in a different medium: Ruby Weekly, a weekly e-mail newsletter for Rubyists.
I've first envisioned a weekly Ruby newsletter in February 2009 and bought
rubyweekly.com then, but it's only over the last six months I've been convinced of the value of e-mail newsletters. Key influencers include Jason L Baptiste, with his e-mail newsletters are still a serious business roundup, and Startup Digest's "e-mail mafia" piece and their how to start an e-mail newsletter company article.
I finally took the plunge due to four concerns:
- Competition. I've noticed, perhaps erroneously, that when I decide something's a good idea and don't do it, I'll see other people doing well with the same idea just weeks or months later. This is probably confirmation bias talking, but it's annoying enough for me to jump on to ideas quickly now (though this is not exactly an all-new idea anyway).
- Experimentation. 11 years ago I edited e-mail newsletters for Internet.com and eBoz.com - that's my experience with e-mail. It seems a great time to look at what's involved from start to finish and get a grip on something that seems to be becoming a hot topic (making newsletters for other people sounds like an interesting job, if nothing else).
- Captivation. Things I've read indicate that e-mail can enjoy a higher rate of engagement than the Web. To me, it makes sense. If I know I have 1000 people on a list and 700 readers have definitely opened my latest newsletter, that's a solid motivator to keep the readers happy. I have a hunch people might develop warmer, fuzzier feelings toward an e-mail newsletter they like than a blog, but I have no evidence for this (yet!)
- Promotion / Money If I have, say, 1000 people whose Inboxes I reach regularly, I can more easily launch new projects. I can't guarantee they'll all be interested in what I have to offer, but it'll get better results for less outlay than throwing a banner up on my sites or taking out some Adwords. Top Internet marketers all seem to have e-mail lists for this purpose. Ultimately, I want to write e-books and produce screencasts for my audience (software developers, mostly) to buy. It's a win-win because my subscribers get what they want and I get an audience I know could be interested in my wares.
Another alternative some people take is putting advertising in their newsletters. Targeted e-mail newsletters can get far better CPMs than equivalent Web sites. I could probably approach one of my Ruby Inside advertisers and charge them $50 CPM without too much trouble. But I want to keep Ruby Weekly "clean" for now. Advertising should never be started too early and, besides, I need the motivation to work on the products I want to sell instead!
The launch and the response
I threw open the doors to Ruby Weekly on Wednesday (August 25) and I've picked up 1120 subscribers in the two days since. I'm grateful to all of them and hope to keep everyone pleasantly informed. It's a far better short-term result than I'd imagined!
My "launch" started in a surprising yet low-key way. I posted a vague tweet the night before the "proper" launch and about 120 subscribers came through that avenue alone - the value of having a loyal following on Twitter! Twitter provides a quick and easy way to test new ideas and get the social media kindling alight. People who follow me include a lot of Hacker News and Reddit users and they frequently submit and vote my stuff up - without my asking, too!
Further posts on Ruby Inside (which has ~24,500 feed subscribers) and RubyFlow then got the floodgates opening. Yes, getting 1000+ subscribers in two days is a lot easier if you have a sizable user-base to promote your list to ;-)
Once the first public issue went out, the reviews that came back on Twitter were better than expected (though I'm keen to get good, critical feedback too!) Some commenters on Ruby Inside couldn't see the point of having an e-mail as well as a blog but, ultimately, it's just not for those people.
How the newsletter works
The technology behind the newsletter is basic. I created a one page Web site at RubyWeekly.com that gives a visual indicator of what people will receive (though this is just a mockup, the real thing looks different!) and invites people to subscribe. It converts awesomely and I think the image helps a ton. The form then feeds e-mail addresses through to MailChimp, who I'm using to deliver the newsletter and handle the list.
The focus for generating the newsletters themselves was to be as quick and easy as possible, so I've already built a simple template based system that lets me easily build newsletters and get well formatted HTML and text versions I can copy and paste into MailChimp. MailChimp's automatic HTML to text system leaves a lot to be desired (though it's "OK") so having my own hand-built templates is a boon. The issues themselves are written in a structured YAML-based format and are run through a Ruby script that uses two ERB templates which output text and HTML versions I can copy and paste into MailChimp. Simple as that.
I have a wishy washy video (with background music, sorry about that.. I left it on while recording) that shows off my templates and sucky Ruby code for the curious:
So where next? Well, it's the hard part - creating those products and services that I can encourage my readers to buy. Ay, there's the rub..
That said, I have one other e-mail newsletter project currently in progress (but unreleased). Almost two years ago, I wrote a popular comment on Hacker News about how to promote your startup. I plan to elaborate on those ideas and present practical demonstrations of how to promote your startup in a regular e-mail newsletter. If this interests you, follow me on Twitter @peterc for the next week or two and I'll be tweeting the URL to the project. You can always unfollow me again afterward ;-)
I was delighted to be invited by Jason Roberts and Justin Vincent to be the latest guest on TechZing, a great technology and development related podcast, the other day. You can listen to the episode here but beware, it's 1 hour 30 minutes long!
The main topic of discussion is coder.io, my developer news aggregator that seems to be in perpetual alpha, but we also talk about my previous startups, Code Snippets and Feed Digest.
I think the interview got more enjoyable as it went on, so while it's long, hopefully it'll keep your interest if you've got some time to kill (long car journey, nursing a newborn, or the 101 times I end up listening to long podcasts ;-)). If you like it, I also suggest subscribing to TechZing in general. They alternate between interview shows like mine and general discussion between Justin and Jason. I must admit, I rarely make it through an entire episode due to their length, but they're great guys and good fun to listen to nonetheless.
Three years ago today, I sold the assets forming Feed Digest to Informer Technologies, Inc. It has since been rebranded to Feed Informer but is still operating mostly as it was.
I made a nice amount of money from it and I don't regret the sale, but, ultimately, I was dumb for letting Feed Digest to get to a position where it was better to sell than not. I need to go into some background for you to see why.
The genesis of Feed Digest
Feed Digest was a pioneer in "serious" RSS (and Atom!) feed manipulation and syndication services. It wasn't the first, but it was the first to seriously try to capitalize on the idea rather than offer these services as an "extra" on something else.
Users included NASA, the Smithsonian Institute, MIT, and, most importantly, the Denver Post, one of America's top 10 daily newspapers, who used Feed Digest widgets all over their site. About 250 million "digests" were being served per month by mid 2007 and from the outside, it looked like a promising business.
Feed Digest spawned from a side project called RSS Digest whose main goal was to take my Delicious links and automatically put them onto my blog. After hundreds of others though it was a great idea, I started to take donations (several thousand dollars in a few months - not bad for 2005!) and let people use the tool too. From this, enough promise was shown that I decided to "go pro" and a month before launch, Kelly Smith structured a deal for Curious Office to make an angel investment in my idea (for this gamble on his part, I will always be grateful).
A popular service, headed by a business dunce
The nascent business had a problem though - me. Though I'd been working for myself for 7 years before launching Feed Digest, it would be an understatement to say I was naïve about the concerns of "running a business." Feed Digest's pricing was ridiculously low (even the biggest "enterprise" customer was only paying $200 a month - most users were $25-50 a YEAR) and while it was in profit from the third week and had a flood of customers throughout, it was only making several thousand dollars a month after 2 years. Enough to keep it going as a "job" for me, but not a serious business that warranted further investment.
As with most webapps, a lot of hope was put into developing an all-magical "version 2" and I made good progress with it. In 2006 I got an e-mail from Michael Arrington who wanted to write about Feed Digest for TechCrunch (yes, one of the biggest and most influential tech blogs in the world). Being a closet perfectionist, I asked if I could hold until the magical version 2 was released. A crazy mistake. Michael has been kind enough to follow me on Twitter and occasionally throw a comment my way in the years since, I hope I can make up for my stupidity by giving him a good story one day ;-)
Service was always a massive deal for me. What I lacked in business acumen, I made up for by delivering the best service I could. Every e-mail got a response within hours, every criticism either resolved or accepted gracefully. I forget the exact numbers but in well over 1000 transactions there were certainly fewer than 5 refunds ever requested (and all were given). Users genuinely loved the service.
Service is only one leg of the stool in any business, and without a serious idea of how to grow the business it was destined to stay small fry unless someone else took notice. In mid 2007, I got a terse e-mail from a Russian guy asking if I wanted to sell Feed Digest and, if I did, his company would be interested in buying it. Negotiations were quick and my angel investors - who were supportive, but a little forlorn over my inability to drive it as a "real" business - gave the thumbs up, since the number mentioned ensure they'd get a healthy return on their investment. The deal was sealed by the end of July 2007 (no big story here, both sides did due diligence on each other and a good escrow was used) and the money hit my bank account in mid August.
It wasn't a lot of money. Well, it was for me. It wasn't a million dollar acquisition, but certainly more than most of the population will earn in a couple of years. A low six figure sale. For something merely making "a living" and keeping me up all hours of the night, I think it was a good deal. It turned into some healthy savings, a wedding, a car, and a chunk of the house we live in now, so I can't complain.
The contract I signed with the buyer meant that I was contractually obliged to defend them against any third party claims over patents, copyrights, and the like, for three years, ending July 30, 2010. Today, then, is truly the day all ties with the service are severed. It's the final period on the last page of the book.
What I've learned since
A benefit of having some savings is that I've been free to do mostly whatever I like since then. I've tried a lot of crazy ideas, got into pro blogging (with Ruby Inside), read a ton of books, worked on open source, and devoted a lot of time to learning and experimenting with business. I've got to know a lot of people in business and get a feel for how things really work, if just at a high level.
One finding is that many people running startups are no smarter than I was when I started Feed Digest. The difference, though, between me and the successful founders are that they are good at delegating responsibilities for areas they're not strong at, whereas I took a strong DIY approach, building not only the technology, but keeping books, design, marketing, and so forth. Not only that, but I wasn't brave enough to charge a sensible rate for the product and didn't understand that I should define my market rather than sell $11.99 annual accounts to people adding widgets to their personal homepages.
I've not become a Donald Trump, but I can now see what I was doing wrong and how I could have turned Feed Digest into a "serious" business (where "serious", at my kindergarten level, means enough revenue and growth to scale to multiple employees and make serious inroads to enterprise deployments of our services).
Not quite the end
Despite my Feed Digest story ending, it has caused me to reflect. I've written about the business side of things here, but the technical opportunities have changed significantly since early 2005 too. Building a Feed Digest style service now is incredibly easy.
Making something seriously powerful and sellable at an enterprise level is no longer prohibitively expensive, just dependent on having the right know how. Which.. I have. I've been building feed processing and manipulation systems in the background for other projects (such as coder.io) in the interim. This has only just made me think: am I crazy for not getting back into the feed processing and manipulation industry again?
So, I'm investigating it - slowly. I know what I'm doing tech side. I have enough contacts now to get things rolling. And I have a lot more grace and life experience to actually ask for help and be brave in making business decisions than the 23 year old me ever did. The industry is still small but, importantly, still growing (Superfeedr is a notable new player) and still considered important by the right people behind the scenes.
Should I get back to what I know and build a "serious" high quality product or service on my existing knowledge base? Honestly, I don't know, but it's going to be interesting trying to find out. After three years, it no longer feels like an unethical thing to consider.
Added: I want to take this opportunity to thank Marshall Kirkpatrick - now of ReadWriteWeb - who championed Feed Digest quite a lot in its early days. He is easily the most RSS-obsessed person I know this side of Dave Winer.