He begins by explaining how he arrived at his conclusion:

I began the hunt to find a technical co-founder – a software engineer who works for no cash – to help me build my dream website. Twelve months into my startup journey I had four half-built websites that had been built by my four ex-technical co-founders.

It’s entirely possible that he picked four flaky technical cofounders. But it’s also possible that:

• He didn’t communicate his idea and vision well enough for them to be implemented.
• His idea was too vague or his vision changed too often to be fully realized.
• He had trouble selling his credentials to his cofounders, causing them to lose faith in him.
• He was a delegator, not a doer. (link goes to Everybody Works from 37signals’ Rework)
• He picked engineers who were technically-driven but not entrepreneurially-driven.
• He picked engineers who weren’t comfortable taking risks as great as he wanted to take.
• He was difficult to work with.
• His cofounders felt he wasn’t was pulling his own weight.

I don’t know Michael, and I’m not leveling any accusations here. There are many possibilities for what went wrong. But the simple fact that things did go wrong is not a referendum on the value of having a technical cofounder, nor is it sufficient evidence to conclude that good technical cofounders don’t exist.

Michael’s second problem comes from holding software engineers to an unprecedented standard of business savviness:

Most software engineers aren’t business people. The only way a software engineer can tell a business idea is a viable is to see the money coming in. A business geek with no money and no income isn’t going to inspire confidence in a software geek. If a software geek really wants to try building something for no pay, they’re going to work for themself instead of following another cashless entrepreneur.

There are three double standards here. First, it’s true that “most software engineers aren’t business people.” But it’s also true that most people aren’t business people. If you are looking for a business-savvy technical cofounder, then your requirement is not merely a “software engineer.” I’m a fan of Micah Baldwin’s post on Hackers and Hustlers. If you want a technical cofounder, look for a hacker as Micah describes it.

Second, nobody knows the viability of a business idea without seeing financial numbers. Picking winners is extremely difficult, and doesn’t work. When it comes to picking the next big thing, the best VCs have worse batting averages than MLB pitchers. It’s not just software engineers who are lacking in this department. Furthermore, there’s more to a business than the idea. There’s the team. There’s execution. There’s competition. None of these things are entirely predictable, even for the most savvy people in the industry. If they were predictable, investing wouldn’t have risk.

Third, most people, not just software engineers, would choose to work for themselves if they could do it in a financially viable and risk-minimized way. What makes software engineers different in the startup world is that they have the requisite skills to hack together an idea on their own if they so choose. But software engineers also pay a price for working by themselves. It means they have to deal with finances and customers and investors and other things that aren’t what they love to do, which is building software. I have side projects, and I hold entrepreneurial ambitions. I absolutely want cofounders when the time comes.

Michael’s last gripe is that “software engineers don’t work for free.” I believe that by this he means they want cash rather than equity. Based on counterexamples I know for a fact that this is an over-generalization. But conceptually it does ring of some truth. Let’s examine why this is the case.

“Business people” and “software people” are misnomers. A “business person” can fall anywhere on the charts of aptitude, skills, education, experience, wits, and a handful of other areas relevant to starting a company. A “software person” on the other hand is more narrowly defined. Skills and education are a known quantity, and experience is more easily described. These traits of a software engineer are always in demand by a great number of companies.

Business people have it tougher. A business person may have equal or more valuable skills than a software person, but they are not universally understood in the simplistic way that software people’s skills are. Ask anybody what a software developer does and they can give you the one-sentence “makes software” answer. Ask them what a “business person” does and you’ll be lucky to get a coherent sentence. That’s because business people cover a wider range of skills and responsibilities; the work they do is more varied.

My hunch is that most good software engineers only work for cash because they don’t feel that working for equity is worth the risk of failure. They can make good money consulting or working as an employee of another company. They can easily get great benefits and a six figure salary. The risk of failure doesn’t seem worth it, especially when the potential reward seems so far away. But an important distinction is that this has to do with their options, not with their profession. If we look at business people who have skills-specific training like software people have, they fall in a similar risk-averse bucket: only 3% of Harvard MBAs use their educations to start a company.

A more appropriate conclusion to draw from Michael’s experience, and one I see first-hand in the startup world every day, is that finding good cofounders is very difficult. One need only look at the necessary traits to find that the odds are stacked against the seeker: you need somebody you trust (ideally whom you know well), who shares your ambition, who complements your strengths, who compensates for your weaknesses, who is in a life position to take a big risk, and who is in a financial position to afford to take such a risk. Forget the haystack; you’re looking for a needle in a field.

Finding good technical cofounders is particularly difficult. This isn’t because technical people are flakier or inherently less entrepreneurial; it’s because by definition they have a narrower set of highly in-demand skills. They have lots of options because, for every one of them there are several “business people” trying to get their attention.

I’m not an attorney, but I am a human capable of reading and inferencing. The legal issues concerning the GPL seem pretty clear to me. There’s a reason why Dan Rivcher is cited by the Software Freedom Law Center’s compliance guide. There’s a reason why the SFLC sides with WordPress. There’s a reason why lawyers at big companies tell their engineers not to use GPL open source projects. There’s a reason why the LGPL exists. There’s a reason why many communities, like the Ruby community, have moved to use the MIT license instead of the GPL. All of these reasons are the same: the GPL is a highly viral license that infects everything it touches. If your code uses GPL, your code needs to be GPL. I don’t know this because I’m a lawyer; I know it because every credible lawyer I talk to or read about or am influenced by reaches the same conclusion.

And I’m reminded of how well I know this, because I gave up healthy means of income in order to abide by it.

My Experience with the GPL

The GPL gave me my first headache when I was in college. I was building my mother’s blog, which required me to build what became ArtPal, a WordPress plugin that lets artists post their work to their blogs and sell it with PayPal. Today, ArtPal is fairly popular for a niche plugin. It has 3,000+ downloads from artists all over the world who use it to sell their paintings, drawings, sketches and digital compositions. A modest estimate would have it responsible for hundreds of sales.

What is my cut? $0, thanks to the GPL. I say this without vent or complaint. I have no regrets about ArtPal being free, and I’m thrilled (really! I get a warm fuzzy feeling!) to know that the hard work I put in for my mother is helping tens or hundreds of other artists to sell their work online. I point out the following merely to explain how the GPL license can undermine the business worthiness of a technical venture.

I started out by retaining the full rights to ArtPal under the name of Digital Sublimity, the corporate outfit I used for my consulting work. I let myself live in denial, trying to convince myself of the argument that Chris Pearson put forward yesterday. “It’s its own thing; it just adds functionality to WordPress,” I would assure to myself. “ArtPal was my innovation, not Automattic’s.” I felt I had an ethical, exclusive right to own my product, and I did not accept that the legal terms of the GPL might preclude that.

But some time after my first client, my intellectual curiosity won out. I read the GPL, did some googling, and accepted the truth. ArtPal integrates with and requires WordPress to function. That makes it a “derivative work” of WordPress, which is also GPL licensed. Consequently, I must apply the GPL license to ArtPal. From this point on, ArtPal was open sourced and formally GPLed. Doing this did not prevent me from selling ArtPal, but it did give others permission to give ArtPal away for free. It doesn’t take a strong economics background to see the problem I quickly faced. While it made good resume candy, I never made another dime off of the plugin.

Common questions I get when I tell this story include “Did it ever bring you money in other ways? Did it ever get you new clients? Did anybody pay for support?” No, no and no. I tried. I advertised ArtPal as being commercially supported by Digital Sublimity and referred people there if they ever wanted it customized. But nobody did. The problem, I suspect, is that I built ArtPal to be simple and easy to set up. Plug in your PayPal email address, choose a “buy it” button, and you’re up and running. If you can install a PHP app on a web host, you can configure ArtPal. If you have a web guy who runs your blog, he can configure ArtPal. An end-user has no need for me. I do answer questions on my ArtPal page as they come up, but they are never in-depth enough to warrant a paid support contract.

The GPL effectively rendered ArtPal a pro bono project. As a part-time effort, I was unable to make it businessworthy while abiding by the full terms of the license.

Why the GPL Is Good for WordPress

You might expect me to be resentful or frustrated given the aforementioned story, but I have no beef with Automattic for choosing the GPL license for WordPress. I would probably have made the same decision if I were Automattic.

By GPLing WordPress (and therefore its plugins and themes), Automattic ensures that any WordPress user can get up and running with all the community has to offer, for free. A user may need to pay for support or for customization, but they can get any plugin or theme out of the box for $0, because the GPL stipulates a number of things that make such content freely available. This effectively lets WordPress outsource the development of thousands of features to its developer community for free.

Less obviously but more importantly, it commoditizes plugins and themes, which are complementary goods. Joel Spolsky famously wrote about this business practice known as “commoditizing the complement.” More recently, Chris Dixon called out Google for disingenuously using the same strategy. For those who aren’t familiar, here’s what “commoditizing the complement” means for Automattic: a blog platform + theme + plugins + hosting is worth $x to a customer. By making plugins and themes free, more of that x can be captured under “blog platform” and “hosting.” Not coincidentally, “blog platform” and “hosting” are the things that Automattic sells at wordpress.com.

The GPL lets Automattic outsource development efforts for free while capturing a bigger piece of the pie.

What the GPL Meant for Me As a WordPress Developer

The GPL limits occasional WordPress developers like myself to service-oriented businesses. Charging for a plugin is not practical, but charging for a customization is. Designers may find themselves in similar situations where they cannot realistically charge for a stock design, but they can charge to custom-tailor it for a client.

One might argue that this provides a disincentive to develop plugins. Why spend all that time building it if somebody else can customize it and earn the money off it? The business counter-argument is reputation. ArtPal created a lot of possibilities for me. When I did WordPress consulting, people had an immediate trust in my work because (1) they knew I built it and knew how to tweak it; (2) I had a strong online presence with a reputation for backing what I built; and (3) I had personal interactions with many of them in the comments section of my blog.

I never capitalized on any of this. The projects that people wanted me to do were too involved for what I had time for. Nobody wanted to pay me just to set up ArtPal; they wanted to pay me to set up, maintain and monitor an entire blog. But for me ArtPal was just a side project, and with a full time job I didn’t have time to be a tech support guy for all of the people who wanted to use it.

ArtPal was too small of a project to be made into a business under the GPL. But had I wanted to create a bigger business, ArtPal would have opened the doors to a larger client base.

• Most celebrate success, and criticize failure. That’s 100% backwards. Do the opposite, and your edge will be 100x sharper.
• The essence of mastery isn’t running the race faster. It’s being able to sit stiller.
• If you’re always trying to catch up, don’t run faster. See further.
• Success has more to do with how you feel – and what you can feel – than what you know. So feel.

Quotes like these get lots of attention in the startup world because they are contrarian and counterintuitive, adjectives which are too often mistaken for “intelligent” and “profound.” Authors of such statements shock their audience, which Paul Krugman once explained is the key to distinguishing oneself in politics:

For a long time, there’s been an accepted way for commentators on politics and to some extent economics to distinguish themselves: by shocking the bourgeoisie, in ways that of course aren’t really dangerous. Ann Coulter is making sense! Bush is good for the environment! You get the idea.

I’m seeing this trend more and more in the startup world, and it saddens me that such anti-intellectualism can propagate so widely among a highly intelligent group of people. This form of contrarianism is particularly dangerous because I hear it frequently among the very people it can poison. (If you’re wondering, Krugman reaches the same conclusion, albeit in a different context):

Clever snark like this can get you a long way in career terms — but the trick is knowing when to stop. It’s one thing to do this on relatively inconsequential media or cultural issues. But if you’re going to get into issues that are both important and the subject of serious study, like the fate of the planet, you’d better be very careful not to stray over the line between being counterintuitive and being just plain, unforgivably wrong.

Indeed.

The most common contrarian phrase I hear has many derivations. It ranges from Umair’s “celebrate failure” to “fail often” all the way to “seek failure.” Like Umair’s aforementioned tweets, these phrases also receive lots of attention because they are counterintuitive and controversial. But there is nothing fundamentally intelligent about these phrases. They are no more profound than if I were to declare we should look to the west to see the sun rise, or that we should seek salt to quench our thirst.

At SXSWi 2010, Jason Fried concluded with something along the lines of “‘Fail often’ is probably the worst advice I’ve ever heard” (I don’t have a link to that, but here’s a similar tweet). I agree. All of my successes in life have come from drive and determination to succeed. Whether it was as big an undertaking as climbing Denali or as small an undertaking as writing this blog post, I’ve succeeded by seeking and thinking about success. On the flip side, my worst experiences have come when I doubted my ability to succeed and instead dwelled on failure.

“Celebrating failure,” as Umair puts it, is very different from making the most of failure, which many thoughtful people talk about. Josh Bokardo pointed out yesterday that learning can come from failure. Brad Feld has written several astute posts on improving on failure, covering his own experiences and arguing that it’s better to fail quickly than slowly and that failure is often worthy of introspection. These are all excellent points. If you’re going to talk about the virtues of failure or any other counterintuitive concept, please follow the Brad Feld strategy of reason, and avoid the Umair Haque strategy of shocking contrarianism.

Mature, profitable sites often take SEO to the next level by altering their visible content as well. In effect, they write their copy for machines instead of for people. From a user experience perspective, it shows. There is often an inherent conflict between what is best for a user and what is best for Google.

An instructive example of this came in a conversation I had with Sachin Agarwal with respect to our page titles at oneforty. The title of our home page reads “Find the Best Twitter Apps.” Sachin argued, correctly, that a better title for SEO purposes would be “Find the Best Twitter Apps and Twitter Tools” because it would match search queries for “twitter tools.” I agree completely with his analysis, but I didn’t want to make the change for a few reasons:

1. It’s redundant.
2. It’s more wordy.
3. It would read “Find the Best Twitter Apps and…” in many browsers, which leaves the reader hanging.
4. It provides no benefit to a user who is already on our site.

Startups are different from the mature, profitable sites that can afford to play these SEO games in that they are more strictly about solving users’ problems and providing them optimal experiences. Established companies, on the other hand, can make compelling business cases to diminish a user’s experience in order to reach and help a greater number of people. I hope oneforty gets there some day, but until we do, I will tirelessly advocate for a user’s experience over Google juice.

For a more typical example of what I’m talking about, look at the TripAdvisor home page. An easy way to display hotels by city would be to have a heading called “Hotels” and under it list a bunch of cities. Any human could easily understand such a presentation. But TripAdvisor does something different:

Notice that it repeats the word “hotels” after each city, reading “Atlantic City hotels”, “Boston hotels”, “Chicago hotels”, etc. It does this because it wants to rank highly in Google for queries like “Boston hotels.” If it just used the word “Boston”, Google wouldn’t associate the link with content for a hotel (Google might be able to deduce this, but TripAdvisor doesn’t want to leave that to chance). To Google this is highly descriptive content, but to a person it’s cluttered and repetitive, using twice as much text as needed.

Redundant headings are another common form of SEO-inspired messiness. Headings are heavily-weighted in search results, and so many sites overuse them and cram them with keywords. An example of this can be seen on Yelp’s “Cambridge Restaurants” page. Look at all of these redundancies:

These phrase-based headings work wonders for Yelp’s search rankings, but they make for a terrible user experience. There’s no reason to tell me 9 times that I’m on the Cambridge Restaurants page when I’m the one who searched for restaurants in Cambridge. A title is fine; a heading is fine; but 9 of them is verbose and distracting. To make matters worse, the headings are all so similar that it’s unclear which section actually contains what content. It’s good for Google, but bad for people.

Writing for people is about cleanliness and brevity. Writing for Google requires clutter and redundancy. Startups should write for their users because companies need to prove their value before they market it. Any startup that’s writing for Google is getting ahead of itself.

I recently replaced my work and home keyboards with the Kinesis Advantage. These are my collected thoughts on it after two full months of daily use.

Adjustment Period

Adjusting to the Kinesis Advantage layout took some time. It is not a typical ergonomic keyboard, and the differences are more than the separated hand positions. It spaces and aligns the keys differently. Many non-alphanumeric keys have different positions. Even if you have perfect typing habits, you will suffer during the break-in period.

The good news is that the pain ends quickly. For alphanumeric keys, I was back to my normal speed within a week. For special keys (chiefly command, option, control, tilda, backspace) it took me two to three weeks to reach full speed. The arrow keys were particularly difficult to adjust to; they required a full month.

Comfort

My previous keyboard was a standard Apple chiclet model. I’ve always had minor wrist discomfort, but the Apple Keyboard brought out the worst of it. It became unbearable. I had to rest and flex my hands after only 20 minutes of typing. Using a computer had become unsustainable. When I heard about the Kinesis, I read as many detailed reviews as I could find online (not many). I then talked to my friends @zapnap and @nirvdrum, both Kinesis owners, who had nothing but nice things to say about it. I took the plunge.

What a world of difference. Two months later my wrist pain is gone. Not only does it feel better when I type, but also when I play guitar and piano. There were certain discomforts that I had grown accustom to over the years, which I had accepted as common or inevitable. Yet after just two months with the Kinesis they are gone. I began feeling relief within a couple of days. My wrists gradually felt better for a little over a month until the pain was entirely gone. In hindsight I cannot believe I waited so long to do something about it.

Typing Speed

My typing speed has also benefited. Part of this is because my hands are more relaxed and I can hit the keys faster, but mostly it’s because my hands don’t travel as far for routine tasks. I don’t have to move my right hand to use arrow keys; I no longer have to place my pinky, middle finger and thumb into an awkward position to hit control+command+3; I no longer need my pinky to press backspace (overuse of the pinky stresses tendons, which can lead to wrist pain). The Kinesis layout, once I became used to it, proved much more efficient than a traditional qwerty layout.

Macros

The Kinesis takes an optional footswich ($35), which I highly recommend. It allows you to activate the number pad in a hands-free manner. It also gives you quick access to your custom macros.

I did not expect to use macros, but they have proven very useful for inputting certain keyboard shortcuts. For instance, I have an app called MercuryMover that moves windows to preset locations. It is activated by pressing control+command+up. This is awkward and difficult to remember. Instead, I have a custom mapping to footswitch+w, which triggers that series of keys.

Quirks

There are a few things about the keyboard that I would change if I had the chance:

1. It’s loud. Clickety-clack is unavoidable when using it.
2. Macros cannot be listed, backed up or restored. If you overwrite them, they’re gone. If you forget one, there’s no means to recall it.
3. There are no finger placement indentations on the “f” and “j” keys. The Kinesis has a unique feel to it that in my opinion renders these unnecessary, but I missed them until I fully adjusted.

Answers to Anticipated Questions

1. Dvorak legends are available.
2. If you don’t like the default layout, you can map any key to any other key.
3. Look for refurbs! I saved $60 per keyboard by choosing this option. It looks brand new and carries the full warranty.
4. In my opinion the Pro model is not worth the cost difference. The memory provided for macros on the standard model is plenty.
5. The foam wrist pads (included) are a nice touch. They are definitely more comfortable than the bare plastic.
6. I have no issues switching between a Kinesis and a traditional keyboard. I routinely use my MacBook’s built-in keyboard when I travel.

If you’re considering buying a Kinesis, feel free to ask questions in the comments of this post and I will respond to them.