Some interesting M&A and partnerships of note over the years:

•  10-18-2006: Logitech acquires Slim Devices ($20 million+)
• 05-03-2007: Netgear acquires Infrant Technologies ($60 million, $20 million earn-out)
• 09-24-2007: Echostar acquires Sling Media ($380 million)
• 10-23-2007: Citrix acquires XenSource ($500 million)
• 01-23-2008: Dell Partners with Fonality as their go-to-market partner for offering VoIP phone systems to its small-to-mid-sized customer base (Makers of trixbox VoIP appliance and software package)
• 02-11-2008: Microsoft acquires Danger (mobile OS software company)

A few weeks ago Carla, an MBA classmate, introduced me to Pixie Maté (blog), a Boulder natural beverage company producing a line of maté teas. Maté is derived from the Yerba Mate plant found in South America (plus a handful of other places) and is naturally caffeinated. Since I’ve been drinking the Pixie Maté brews, I’ve found it to be a great alternative to coffee (which I refuse to drink) and Red Bull which has been my coffee alternative of choice as of late. I especially recommend their Lemon Ginger Black Tea Maté.

Prior to maté I have always found most energy drinks and caffeinated beverages to have little overall effect on my energy level. Maté is the exception. I have found the maté to provide a noticeable increase in energy that is sustained for several hours. More importantly though I find I am better able to focus on tasks, and that the caffeine boost plus the increased level of focus makes me more effective at getting things done.

Next time you find yourself going to a open coffee club such as this one, but are in the non-coffee-drinking minority like myself, order up a maté and enjoy the effects of this energy beverage alternative.

SaaSaaP, an acronym I came up with before reading about Appliance-based Software Delivery (AbSD) (here, here, here) is, what I believe to be the next step in the evolution of SaaS (or just application delivery in general). SaaSaaP / AbSD involves taking the SaaS hosted in the datacenter and placing it behind the corporate firewall, essentially turning your software service model into a product model (see: Google Search Appliance)

The availability of good virtualization technology can allow a SaaS company to make the jump from a SaaS to appliance-based delivery very straightforward. Additionally SaaS companies should evaluate whether their applications have opportunities that can be better realized behind the corporate firewall. Besides, SaaS is the analogue to what software hosted on mainframes were many decades ago, and as history is known to repeat itself, SaaSaaP would be the next step in the evolution of software delivery, except this time you get the computing platform and the software packaged all bundled into one efficient appliance, instead of a PC and a CD and the need to run setup.exe

Oh yeah, and Cisco just validated Appliance-based Software Delivery with its purchase of IronPort for $830 million.

I read a great article by Liz Ryan today in the Daily Camera titled “Who’s wasting time?” about companies that like to monitor their knowledge workers’ surfing habits:

Liz Ryan asks (of a PR guy that works for a monitoring software company):

“Why do we care what they’re doing online? If a person can build a DNA sequence by working for 10 minutes and then spending 10 minutes on the Camera blogs, what do we care?”

“‘We care because people should be working,’ said the PR guy.”

…

“‘Also,’ I asked, ‘if the person isn’t online at some non-work-related Web site, does that mean he or she is working?’”

…

“We say we want to move past the Henry Ford assembly-line era, but we don’t”

— — — —

But in the end, it’s good to know that these monitoring systems are easily bypassed with a regimen of Remote Desktop tunneled through SSH. Problem solved.

Update: Remote Desktop over SSH references: here, here

I’ve been on a blogging tear lately, finally getting around to writing posts on topics that I’ve been meaning to write about for a while now. I have a series of posts that I’m working on in the category of virtualization, so I thought it might be useful to write about my experience with Amazon EC2.

I first became aware of Amazon EC2 when I was investigating rPath Linux and their rBuilder suite of appliance packaging tools. I first used EC2 at Startup Weekend Boulder because it was an easy way to instantly provision a server with pretty good horsepower (1.8 GHz, 1.8 GB RAM) while keeping costs low ($0.10 per instance hour per month), and didn’t require any contracts or setup fees. I also thought it would be great for scaling should Startup Weekend Boulder produce the SaaS hit of the century and all of a sudden get overwhelmed with traffic - Just start up a few more instances to handle the load and we’d be set.

EC2: A Great Service, Except For That Ephemeral Storage!
While I was setting up the instance at Startup Weekend, I quickly realized the biggest problem with EC2: The ephemeral storage. The ephemeral storage is the 250GB slice of storage that is mounted at /mnt of every EC2 server instance and is the only local storage available to an instance as the Amazon Machine Images (AMI) images have root filesystems that are limited to around 10GB. The problem with the ephemeral storage is that should the server instance get terminated for any reason (such as the recent accidental termination due to their management software upgrade), you will lose everything stored on the ephemeral store, and this usually includes your application and any databases it may be accessing, not to mention any server customization and configuration that you may have implemented.

I spent a lot of time at Startup Weekend figuring out how to save our customized AMI image and dump our database to Amazon S3, I figured worst case if we have the image and data saved we can get things going again in a reasonable amount of time (although “reasonable” probably doesn’t hold for very popular production sites).

Accidental Instance Termination
Speaking of this recent accidental termination of EC2 instances, one of my instances that I was using to temporarily host my (wah) cool “RaceBib” Facebook app (I didn’t want to be left out of the “Facebook is the new Internet” club) was shut down. This termination was my motivation to finally move this application over to something more permanent and less costly (see my previous virtualized hosting article). I knew eventually an unexpected instance termination would happen and took the basic precautions of copying the database to S3, so I didn’t lose any data, I just had downtime which while unfortunate wasn’t a huge big deal with only a handful of Facebook users.

Anyone who complains to Amazon about this accidental termination should have expected it in the first place. Amazon states clearly that instances are subject to termination at any time, and they recommend that users plan accordingly and implement redundancy and backup measures. If I recall correctly I think they even say to expect an average of 90 day termination or maintenance events. Anyhow, setting up redundant MySQL servers or brain damage of that nature seems to reduce the cost effectiveness of the service (having to setup multiple instances), and reduces the ease of implementation of the Amazon service. From what I’ve read I believe Amazon is aware of this weakness in the EC2 service and they’re actively working to create a more permanent “ephemeral store.”

Amazon EC2: What other VPS Providers Should Emulate
One of the main things that caused EC2 to quickly get my attention was the ability to bring your own virtual image (AMI) to Amazon and have them run it on EC2. This was one of the build options that rPath’s rBuilder provided and what sparked my initial investigation into the EC2 service. Currently most VPS providers will offer you a wide array of stock VPS operating system images that they’ll let you run. Pick one, load it up on your VPS, customize it to your application’s needs, but if you ever decide to leave one VPS service for another, you have to leave your image behind with all your configuration.

Additionally if you simply want to replicate your application’s configuration to additional servers on the same service, you have to start with the stock OS image and reconfigure everything manually. But then maybe some of you out there actually get a kick out of repetitive server configuration. Regardless, Amazon EC2 is perfect for all of these. Once they get their ephemeral storage issues resolved, it will be in my opinion, the perfect hosting option (especially with it’s integration into the S3 service) and I will continue to recommend it as a hosting option to others.

All the servers I’ve been provisioning lately are packaged in a virtualized form. If a VPS service can’t afford the flexibility to host my pre-built image, or allow me to download a server image I’ve customized either to move it somewhere else, scale it, or keep it for backup purposes, then they’re missing the some of the greatest benefits of virtualization. If you’ve come across this post, and you’re looking for someone to host pre-built virtualized images, I offer VMware image hosting through my company, Obility, LLC. Contact me and I can work with you to help you realize and take advantage of everything virtualization has to offer.

Are you having difficulty separating your server applications and data from your server hardware? Wish you could use that inexpensive NAS to store application data, but your applications don’t work over NFS? Wish you could easily switch between server hardware without having to physically move storage from one server to another? These are problems I’ve had for a long time that virtualization technologies have now resolved.

The Problem: Decoupling Server Hardware and Storage
Traditional server configurations involve a single piece of hardware (processor, memory), and some storage (a single drive or RAID configuration). Load on this an operating system, configure your applications and you’re off to the races. When the server hardware fails or you want to upgrade the server, you have to physically move the storage from the old server to a new one and deal with any RAID issues. This can be a time consuming, error-prone activity, especially if you don’t have quick, physical access to your hardware.

The Virtualization Solution
With server virtualization you can easily decouple your server hardware from your application and OS storage. The benefits to this approach allow you to incorporate inexpensive server hardware and low cost storage solutions to create a complete solution that affords reliability in the event of hardware failure and flexibility in the face of server re-provisioning and upgrades. Running a virtual server on the server hardware and storing the virtual images in a NAS is a solution that has been revolutionary in the way I am currently provisioning and running my server applications.

My Configuration
My current configuration uses commodity server hardware running a stripped down version of Ubuntu Feisty server and an install of VMware server. I have saved this server install and can quickly replicate it to bring up new server hardware if needed. I am currently experimenting with loading this setup from a 4GB compact flash, as there is no need for the server to have a hard drive. I have created stock VMware server images and store them on a 2TB ReadyNAS. The servers mount the VMware images via NFS. Benefits of this setup include:

• I have commoditized my server infrastructure. I can rely on an array of inexpensive non-redundant server hardware to run my virtualized servers and applications. If server hardware fails, I can quickly switch the virtual image to another working one.
• The server hardware runs a minimal set of applications (base OS and VMware server) this configuration is easily and quickly replicable.
• I can run multiple virtual images on a single server, making more efficient usage of the hardware and easily separate applications that may interfere with each other.
• All the applications and data are stored on the ReadyNAS, a device that that is designed for reliable high-capacity storage of data.
• Applications are encapsulated in virtual images and are not affected by the use of NFS. I have always use Cyrus IMAPD to serve my email. Using Cyrus IMAPD over NFS is not recommended and can result in corruption of key system files. I am now using Cyrus IMAPD in a virtual image over NFS, and am immune to typical NFS problems. Same holds true for all other databases and applications that have issues running over NFS due things like file locking or delayed writes.

If you’re struggling with the issues I’ve mentioned above, give server virtualization a hard look. It has the potential to change how you go about deploying your servers and applications. Feel free to contact me if you have any questions or would like some more information on how to simplify your server deployments using virtualization technology.

An idea came to me while I was working on VoSnap the other day. It was also partly inspired by Intense Debate who has been developing products to essentially own a part of the Internet, in their case, blog comments.

I got to thinking, why hasn’t anyone done anything with email subject lines. Through all the years email has been around, and all the innovation that has gone into email products, the subject line is still a static, plain element in your mail reader. Certainly it could be possible to embed HTML in the subject line and have it displayed with a little pizazz. If I remember correctly, Colorful subject lines were a feature of BBS systems back in the day, thanks to a helping of ANSI graphics.

Then I was thinking - Why does the subject line have to be static in the first place? Take for instance VoSnap. Why can’t the email subject line show how much time is left in a vote, and update every minute until the vote is closed. Sure providing executable / dynamic code in the email subject line would be “subject” to all the issues and nightmares that come with executable code anywhere. Spammers would probably love it, and no amount of Xanax would prevent Microsoft Vista from going off the deep end due to an active-subject line induced anxiety attack.

For applications such as VoSnap, meeting requests, and things of that nature it could prove to be very useful as the email subject line is the first and many times only thing that is consumed by the recipient.

Watching and participating in the several Startup Weekends has given me some insights into common elements of each weekend that could be streamlined with the use of additional tools, preparation (no, not like Toronto), or services.

One thing that each Startup Weekend implements, as do a number of Software as a Service companies, is the pre-release splash page. This is the page that announces the imminent release of the product, and allows an interested user to signup with his or her email address to be notified when the product launches.

I envision a service that manages and hosts pre-release splash pages on behalf of SaaS companies. I know, in the case of Startup Weekend Boulder, when we were developing VoSnap, we got our page up late in the game. We also had to spend time and resources designing and posting the page on the production server.

I believe the pre-release splash page is a simple yet very important of any startup company. It should be posted as soon as a domain name is available to capture and gauge customer interest, and to develop a mailing list that can be used for marketing purposes and a way to continue generating “buzz” about your product long after a potential customer’s initial visit to your site.

Pre-release splash pages are relatively simple to create and usually adhere to a common structure. I believe a pre-release splash page hosting service would be beneficial to SaaS developers because it would eliminate the need to spend time reinventing the wheel by developing and hosting their own custom splash page. It would also provide additional benefits such as list management, email campaigns, mobile SMS text notification, and analytics, that a roll-your-own solution would not be able to provide. It could be monitized through advertisements (of course), and fees for premium services such as SMS text and analytics.

I just finished upgrading my pfSense firewall to the latest 1.2-RC2 release. I’ve been running 1.0 (and a pre-1.0 release before that) on a network appliance for several years now. It’s a very solid and stable firewall with a bunch of features usually only found on higher-end equipment.

pfSense is a firewall appliance derived from m0n0wall, based on BSD and has a great web-based configuration interface. I installed this latest release of pfSense into a VMware virtual image, and also have it running on a 1G CF on a mini-itx VIA motherboard.

I have been using pfSense successfully to manage a static IP subnet, using its 1:1 NAT and virtual IP addressing features to route the static IP block to the servers to which the static IPs are assigned. I also use the traffic shaping features to allocate bandwidth for VoIP accounts that terminate at an asterisk appliance on the internal network. Real-time traffic graphs and traffic logs also give and idea of the bandwidth loads on the network.

The pfSense  firewall appliance also serves as a VPN endpoint into my internal network, pfSense offers VPN services through IPsec, OpenVPN, PPPoE, and PPTP. I’m currently using PPTP with Windows XP clients.

Other features of pfsense include captive portals, load balancing, CARP for failover protection, OLSR, RIP, SNMP, UPnP, DHCP server and relay, DNS Forwarder, Wake on LAN, and a packaging system that lets you add on third party packages to the firewall such as radius servers, network monitors, web proxies, and security tools, to name a few.

pfSense contains all its configuration in one XML file which makes it easy to upgrade and configure the firewall. pfSense can be run in an embedded environment (off of a compact flash card, with no console/keyboard) or on normal equipment with I/O enabled. Packaging pfSense into a VMware image was also very straightforward and worked as expected. This virtual firewall image can then be used to decouple the firewall software from the hardware and give me the flexibility to quickly switch hardware as needs change or hardware failures are encountered.

Sorry to leave everyone hanging after that last post about Startup Weekend, Toronto. While I enjoyed the weekend, hanging out with Andrew Hyde, Erica O’Grady and Steve Poland, being a tourist in a new city, and such, the Startup Weekend event resulted in a lot of lessons learned, and whole new appreciation for the Boulder tech scene and everyone that made SW Boulder an incredible success.

I signed up for SW Toronto because I was very excited about this new concept of Execution that Startup Weekend promised. From the time I signed up, I was a little worried about all the planning that was taking place, but at the same time I also saw a bit of hope that some of the planning might resolve and expedite some of the issues (such as development platform selection and environment setup) that we encountered in Boulder.   It was also the second startup weekend, and I wanted to give it another go, just in case the concept should happen to fizzle out by the time one of the later events came around.

Summary of the weekend:
We got to the event on Friday evening all pumped and excited about what was about to take place. By Friday night around 10:30 PM, we finally picked the idea for the weekend - an idea that thank god wasn’t a Facebook application, but wasn’t all that amazing in my mind - not that my opinion on the excitement of the idea matters - I’m sure just as many people thought VoSnap was lame (and perhaps still do). The first thing I thought of when Lobby Them was pitched was - Comcate - Ben Casnocha’s company he formed for to enhance customer service at the government level. Most everyone left at 10:30 for the night, in the back of my mind we were already behind schedule.

This evening was also the first time I read the SW Toronto founders agreement which turned out to be the biggest red flag of the weekend. It defined the idea of “managers” and “participants” (hierarchy), a skewed company ownership structure to the “management” team for a TBD number of pre-event planning hours, and a huge chunk to the person that generated the idea. A miniscule 15% or so was left for the go-forward team (post-event) which I believed was way too little to incent any future management team to build a successful company and thought it would be a problem in the eyes of any investor. Then there was the Saturday morning confrontation, which basically killed any remaining vibe I felt for the weekend, and by around 12PM we were finally coding and off to the races - way behind schedule (at least they picked Rails!). The whole weekend I felt like I was back in some shitty corporation working for “the man.” SW Toronto lacked transparency (very few group meetings, everyone was segregated in different rooms), and neither was the ownership, the fun vibe, or the excitement.

Like I mentioned in the comment in the last article - I believe there was some desperation and greed that cropped up between the time the Toronto managers decided to do the weekend and the time it all went down. I don’t blame anyone, and I believe it’s easy to fall into this trap - The night Andrew brought up the Startup Weekend concept, I started thinking about all the things that would have to be done to make it happen. I entertained notions of extra shares for special people, I worried about having slackers present sitting around doing nothing but collection ownership. I basically toyed around with the Startup Weekend concept in my head until I developed it into an impossible mess of rules, and restrictions.

I soon realized that if we didn’t let the community of founders decide the majority of the issues at the weekend, then we’d lose the sense of ownership, freedom from pre-defined rules and restrictions, and equality we all had for the product we were creating. In order to go down the path of self-organization (see Barcamp), I believed we’d need to make a lot of decisions quickly, and thus the idea for VoSnap was born. I also we’d have to ignore 20% of the possible annoyances that might crop up during the weekend (such as slackers) in order to focus on the 80% of what’s important - the people that are truly vested in creating something great in a short weekend.

Additionally we were able to eliminate 80% of unnecessary planning with the remaining 20% of pre-event work done on a volunteer basis (no share compensation considered). Finally, being the one to have come up with the VoSnap idea, I personally rejected any sort of additional share compensation for the idea because I believed 1. That ideas are a dime a dozen and not worth anything, and 2. The weekend was not about me and my “awesome” idea, it was about a bunch of people working together on a common goal, having fun, and that to take additional shares would create an unnecessary hierarchy or advantage over everyone else.

To conclude. A lot was learned. I met a bunch of great people in Toronto. I believe for the most part that everyone there had the best of intentions. I had a great time visiting Niagara Falls, Toronto Island, and eating at a lot of cool restaurants downtown. I miss my  friends that I hung out with during the brief time.  I believe the Startup Weekend concept is a huge success, and that Andrew will bring more structure and guidance going forward. I am eagerly anticipating watching the progress of Startup Weekend New York City which goes down this weekend. Good Luck!