Archive for the ‘Book’ Category

Pet Peeve: A**wipes in intersections

Wednesday, December 3rd, 2008

Ok. Generally I avoid off-color language, but I’ve got yet another rant to get off my chest. And while it’s mostly off-topic for this blog, I promise to connect the dots…

So there I was, walking the dogs home from work. I crossed the Fremont bridge, then down the block to the one major intersection I need to cross, just in time for the walk sign.

But there are cars stopped right in the middle of the crosswalk, underneath the red light. And not just the crosswalk–there were fully 3 cars stopped on the intersection side of the the crosswalk, blocking cross traffic.

The guy parked squarely across the crosswalk shrugged and looked pretty embarrassed as our pack went around behind him. And then I had to walk up between the cars back to the crosswalk, along side some asswipe who had her head totally inside the car doing something or other that apparently was more important than driving or obeying traffic rules.

I rapped on her window as I walked by, and she let out a terrified shriek. Then she started yelliing at me. I was listening to the radio, and really didn’t care what she had to say, so I hollered “you’re in the middle of the intersection.” She rolled down her window to yell something more at me, so I hollered back at her, “you’re in the middle of the f**king intersection!” And continued on into the neighborhood.

Now, I’m usually a very calm, even-tempered guy. You never hear me say things like that. But assholes who think they need to make it through the next light at the expense of everybody who happens to be going the other direction really piss me off.

Don’t get me wrong–I’ve been caught unexpectedly in the intersection when the cars ahead didn’t move as much as I thought they would. And when this happens, I’m very embarrassed, and hyper-aware of everything around me, trying to get out of the way of any pedestrians or other cars I’ve unintentionally blocked. This woman received my moment of wrath because she was startled that I was even there, and couldn’t care less that her selfishness is the kind of thing that causes gridlock and endless traffic jams.

So how does that relate to our topics of open source, computers, business, and economics? A couple ways.

First, there’s the obvious parallel to network congestion. If you’re on a DSL connection, incoming and outgoing traffic have to alternate over the same pair of wires. If you flood the entire connection one way, the other way starts to suffer. For example, if you’re uploading a huge file over a network connection, it can greatly decrease your download speed, much more than you might expect. By keeping your traffic in either direction slightly under the maximum rate, the other direction can continue to flow freely. But if you max out one direction, the other direction suddenly can’t get through, just like lame drivers who block the intersection because they’re too impatient to wait for the next light.

The other point is about selfishness. Ayn Rand wrote some quite influential books. I read both Atlas Shrugged and The Fountainhead as a teenager, and they make a very persuasive case that people acting in their own self-interest can help the greater good. This is much of the justification for our current financial system, the whole idea of trickle-down economics that suggest if you do what’s in your interest, you’ll make lots of money and create jobs for others.

But gridlock provides a great counterpoint to this–the selfishness of a couple people who enter the intersection with no where to go can lead to stopping the cross-traffic, which could well be hundreds of other people. The actions of one person trying to get ahead can come at a cost to hundreds of others. The actions and profits of the big businesses that dominate our economy have come at the expense of the rest of us. One relevant economic phrase related to this is the tragedy of the commons.

Socialism, individualism, and open source

Tuesday, November 18th, 2008

I just heard a Republican pundit on the radio talking about how Republicans are supposed to stand for individual efforts over taking care of others, and small government rather than large. He posited that Republicans had lost the election because they hadn’t adhered to these core values.

A colleague who sounds a bit upset at last week’s results twittered a link to a blog post that accuses us of being “sheeple”, and going down the path of socialism, and apparently the author believes this will cause our country to collapse. The tail end of the McCain/Palin campaign hurled the Socialism epithet as well. Other colleagues have been sending cartoons of trick-or-treaters collecting candy on behalf of their friends who are “too lazy” to trick-or-treat.

There must be some fundamental difference in the way people see the world. I hear these things, and several thoughts come to mind: (warning: long, rambling unedited rant ahead)

  • We’re facing some awfully large problems. Sub-par health-care system. Failing education system. Crumbling transportation infrastructure built around gas-guzzling cars as the cost of oil goes up. Failure of the free market to regulate itself. It strikes me that these are all problems we need to solve together, not leave to the laissez-faire system we’ve had that have rigged the playing field towards the rich, redistributing our country’s wealth to the very top.
  • Why does the word Socialism have such negative connotations for the right wing? Is it just because it was part of the USSR’s name? Most of Europe has socialist programs in place, resulting in much better health coverage and a social safety net to help reduce homelessness.
  • The word “lazy” is used as a broad brush to dismiss the efforts of anybody who hasn’t reached some level of success, often by people who are struggling themselves. I’d argue that people at the bottom of the pay scale, working 2 minimum-wage jobs and barely scraping by, are anything but lazy. Opportunity is capricious, and not evenly distributed.
  • Open Source provides a proof-of-concept that illustrates that we’re better off working together to solve our problems, rather than keeping our solutions close to our chest and not sharing with our neighbors.

Us versus them

Our country was founded with a common enemy. For many people, it seems that patriotism depends upon having an external enemy. First the Brits. More recently, the Nazis and Japan, and then the Soviet Union. Now, it’s terrorism, along with illegal immigrants.

But Franklin Roosevelt, at his inauguration in the midst of the Great Depression, famously said “the only thing we have to fear is fear itself—nameless, unreasoning, unjustified terror which paralyzes needed efforts to convert retreat into advance.” And indeed, that is exactly what we fear today–terror. We’ve declared war on it, to the detriment of our civil rights and our moral standing in the world.

I think many people have transferred their fear and uncertainty of their own economic circumstances to this external threat of terrorism. But our real enemy, both here and abroad, is poverty and an unwillingness to work together in the face of much larger looming disasters, such as peak oil, climate change, water and energy shortages, overpopulation, mass extinctions. Instead of dealing with these issues, we’re blaming others for our problems.

I fail to see how the problems we face in the world are all because of terrorists, Democrats, or lazy people. I would argue we have terrorists because we have poverty, and hugely imbalanced distribution of wealth. If we don’t deal with those issues, we’ll surely see more terrorism in the future.

The individualist end game

Time is running out on many fronts. The sheer size of our population is putting a strain on the natural systems of our planet on which we’re completely dependent. Yet we squabble on how to divide up the planet, and those who play the dirtiest have long been winning.

In economics, there’s a distinction made between rivalrous and non-rivalrous resources. Rivalrous resources are those that can only be used by one person at any given time. Non-rivalrous resources are generally things that can be used by many at the same time. For example, my backpack is rivalrous–if you take it from me, I don’t have it anymore. A song is non-rivalrous–I can sing “Happy Birthday” without taking that away from you. Or at least, I should be able to…

In our current economic system, we have made more and more things rivalrous, at least in our legal system. We have carved up our land and made the vast majority of it private. We have granted patents on our very genes. We have allowed corporations to claim ownership of drinking water and charge people for access. We have companies whose sole purpose is to own a patent portfolio and make money off the use of ideas, whether or not other people came up with the same idea independently.

If you’re an individualist, you might see these things as capitalism at work, and the way it should be. But this is really a short-sighted view. Taken to the ultimate result of more and more people fighting over less and less, and you end up with situations like Rwanda in the 90s. According to Jared Diamond, one of the biggest factors leading up to the genocide was population-pressure–the population density had reached a level not seen anywhere else in Africa. Sons were fighting over postage-stamp lots of land to have something they could grow food on, as fathers divided the land into ever smaller bits. There were no shared spaces left, no mental buffers, not enough land to support the people. The rate we’re exhausting our planet’s resources, we risk a similar fate.

We’ve been steadily turning our common wealth into private wealth, redistributing wealth to a tiny few, leaving not enough for everybody else. We’ve been spending resources like oil that have taken millions of years to accumulate in a few generations, polluting our seas and soils, shipping our waste anywhere out of sight, and seeing all of this as somebody else’s problems.

Our country was founded on the principles of working together in the face of a common enemy. Ben Franklin is full of relevant quotes: “We must hang together, gentlemen…else, we shall most assuredly hang separately.” The biggest problem is that while these big companies take, take, take from our environment and people all to maximize their own profits, they’re stealing the resources everybody else will need in the long run, and socializing the true costs of them doing business.

Scarcity versus abundance

Ironically, the way out of this mess is to change perspectives and realize we really are blessed with tremendous resources. Among the largest, most under-utilized resource we’ve got are millions of smart people locked up doing menial work as cogs in the machinery of these big corporations. We’ve largely moved slavery out of agriculture into minimum-wage jobs across the country, and lower-wage jobs abroad. The term “wage slave” is not far off the mark. Prices of everything has been spiraling up while wages have flat-lined. In the past generation, the cost of buying a house has gone up by a factor of ten, while wages have doubled. Yet more people have bought houses than ever before, and we now see that it was mostly on borrowed money they couldn’t possibly pay back.

You hear the right wing complaining about big government, and how liberal policies reward people for not working. Our policies say a lot about what we value, and just about every decision congress makes benefits some people while penalizing others. We need to get a lot more strategic about our policy-making, and align those policies to address the big problems we’re facing–a health care crisis, global warming, deforestation, peak oil, the financial crisis, and more. If our most abundant under-utilized resource is brainpower, let’s make some policy changes that rewards using those resources, while penalizing the use of the natural resources we’re quickly exhausting.

We need to find ways of penalizing companies that consume natural resources and burden our systems with waste. We need to find ways of rewarding smart, responsible people and companies who help reduce waste in the system.

So how do we make this happen?

Let’s go back to the basics. What does everybody need? Food and shelter, obviously. Today, health-care needs to be a right–we’re a wealthy enough country that it’s absurd people have to choose between food and medication they need to treat and prevent a health issue. Beyond that, people need opportunity, and motivation. For far too long, our policy has been to motivate through fear. Make people afraid they won’t have enough food or have a place to live, and they’ll do drudgery work to avoid that. But it’s hard to give creativity free reign when you’re trying to scrape together the basic things you need to survive. Too many of our people are in exactly that position. And we need their help solving the bigger problems.

In fact, some of our biggest problems are caused by exactly this issue–people not having adequate food or shelter. Terrorists come from places where the future is bleak, where people aren’t secure that they’ll have a safe place to live and enough to eat, let alone make any positive contributions. But there’s always an opportunity to be destructive if your situation is dire.

Now, as much as I’ve been railing against big business, I do think business is the answer. We need to re-align our policies to favor small businesses, and lots of them, to power our way through this mess. Small businesses need to be part of their communities–they can’t just take their jobs to the lowest bidder. Small businesses are much more entrenched in location, and able to make contributions to help their communities. Small businesses provide jobs, solve multiple problems, and are able to think about things beyond merely satisfying their shareholders’ greed–they are able to optimize their business to fit in their part of the economic ecosystem, rather than doing whatever it takes to maximize profits. And small businesses succeed by recognizing that others need to succeed too.

The current barriers to people creating small entrepreneurial businesses that solve real problems are many:

  • A workforce trained to be wage slaves, rather than thinking, and making decisions, for themselves.
  • Crushing costs of doing business: payroll taxes, health care, business operational overhead that is a high cost of doing business.
  • Lack of knowledge/experience in creating a business. Very few people who start a business have done it before, and until you’ve started a business, it’s hard to understand the magnitude of the task.
  • Money. It takes money to get started. It takes money to hire people, provide training, lease space, buy equipment, get insurance, handle bookkeeping and taxes, and obtain licenses, let alone buy the raw materials that become your product.
  • Time management. If you’re a service business, you need to have enough billable hours to cover your costs and make a profit. If you’re a product business, you need to create or manage your products. You need to devote some of your time to marketing and sales before you make any money at all. You need to divide your time effectively between doing the stuff you get paid for, letting the world know you exist, developing the key relationships with partners and vendors and customers, and handling all the little stuff that needs to get done to keep the business running.

The bottom line is, nobody can do all of this alone. To succeed in business, you need help, and lots of it. You need customers who will spread the good word. You need vendors to help with all the operational aspects of your business. You need employees to do the actual work of your business. You need competitors to prove to the marketplace that your product or service is valuable.

So that’s a very long-winded way to get to the point that the vast majority of businesses do not have a monopoly on their product, and do not need “Intellectual Property” (IP) protection to be successful.

Venture Capitalists are always looking for IP: patents, copyrights, trade secrets, or some element that gives a company an advantage over every other potential competitor in the market. They need this because the venture system is based on home runs–they expect that out of 10 businesses, 7 will fail, 2 may break even, and 1 will be successful enough to cover the losses of the other businesses. They don’t know which business will be that home run, so they’re going to invest in the businesses they think stand the best chance.

I’ve spoken with hundreds of people who think their idea is unique, and they don’t want to tell you about it because you might steal it and make a ton of money–or at least be a competitor. The problem is, there are lots of good ideas, and many people come up with very similar ideas independently–the real shortage is the talent to execute those ideas, turn them into a viable business.

One of my biggest challenges as an early open source solution provider was having my potential customers take my solutions seriously. After all, if the software is free, how can it be any good? And if it avoids vendor lock-in, why am I the only one proposing it while they’ve got a dozen vendors pitching Microsoft or Intuit solutions?

While the idea behind my business is wide open, and there’s no prohibitive barrier to competitors setting up shop and doing exactly the same thing, our business is succeeding on execution, on the talent of my employees. It doesn’t matter what your idea is–what matters is whether you can bring it to market.

Systems thinking

To wrap this long meandering post up, we can no longer afford to run businesses that maximize a single factor (profit) at the expense of everything else (people, environment, waste, the future). We need to start optimizing for all critical factors. Our products and businesses need to account for the full impact of what we’re doing, and if it doesn’t make the world a better place in some small way, it shouldn’t continue to exist.

Businesses don’t exist in a vacuum. Businesses can serve a highly constructive role in our society, and help address all of the major challenges we face. But we need to adopt the Unix architecture, create them as small pieces loosely joined, not big monolithic monsters that crush everything in their path.

First impressions of Intrepid Ibex

Sunday, October 26th, 2008

Ubuntu is about to release a new version of their operating system, code-named Intrepid Ibex. It’s due this coming Thursday, October 30.

I’ve got a list of niggling things that have been bothering me about the current Hardy Heron release. Since the biggest of these issues are related to hooking up a projector or external monitor, and I’m giving a guest lecture Wednesday evening, I decided to test-drive the Intrepid release candidate to see if they’ve resolved these issues.

It turns out, the answer is yes.

I’ve been running it for a few hours now, and I have to say, I’m finding a lot of nice little improvements. If you’re new to Linux, please forgive the technical nature of a few of these notes… just some random unedited thoughts. Here are some things I’m really liking right now:

  • External monitors. Finally, after being promised for the past three releases, I can add an external monitor and configure it through a GUI, without needing to edit a configuration file. I can extend the desktop across both monitors, or clone the screen. For the past year, I haven’t been able to do this at all without the video display locking up. Now it’s working great. Fantastic!
  • Broadband card support. My USB Verizon broadband card works in Network Manager. All I have to do is tell it to connect, and it does–no configuration necessary. Previously I was using gnome-ppp, which took a lot longer to make the connection, and took some configuration.
  • Appointments show up in the panel with the right colors. I’ve used Evolution for appointments for years. I have a bunch of different calendars loaded–different ones for work and social events, and the calendars of my employees. In Evolution, I set each calendar to a color so I can easily see which calendar an event is on. However, until Intrepid, these colors did not get used in the Gnome display–that used some random set of colors. Now they match. Small, but much appreciated improvement.
  • Suspend/Resume is much quicker. While suspending the machine has worked pretty well for quite a while, under Hardy there was a lot of load that kept you from getting to work right away. If you had a few applications running, it could take 10 minutes before it was usable again! Under Intrepid, you can start using the applications immediately after starting up. I see that the system is under high load for a similar period of time, but the user interface is no longer sluggish at all, and the load seems to drop much quicker.
  • Avant Window Navigator plugins work. I’m hooked on this little launcher utility, but the one available in the Hardy repositories didn’t work with any plugins. With Intrepid, they’re all there and work great.
  • Firefox with Flash doesn’t crash so much. Okay, this isn’t anything to do with Intrepid, so much as tracking down the nspluginwrapper package, which allows Flash to crash without taking the browser down with it. I found this based on a how-to on getting Flash sound to work.

Which brings me to the problems. I’ve hit two pretty substantial problems. Both of them are more of a nuisance than any sort of show-stopper, but they are the kind of nuisance problems that might keep some people in Windows:

  1. Sound did not work correctly out of the gate. I first noticed this in a flash video. Here it is the second release with Pulse Audio, and it still doesn’t work correctly without some manual configuration. To get it working, I followed a how-to on the Ubuntu forums, basically installing libao, padevchooser, and some other libraries, removing previous config files for alsa and pulse from my profile, and making libao use pulse by default. This only took a couple minutes, but for somebody unfamiliar with Linux, this might be a big barrier.
  2. Bluetooth. I have a bluetooth mouse, and hooking it up was a piece of cake. However, it doesn’t remember the connection. I have to delete the bluetooth profile, and re-pair it every time I shut off the mouse or suspend the computer. I’m sure there’s a pretty simple fix by editing a couple configs, but the point is, it should just remember that I’ve paired this device and not bother me again.

Those are the only two new issues I’ve seen appear in this release, so far. And I really only see one other major issue: I’m still seeing memory usage of Xorg creeping up as I use the system, especially after a suspend/resume cycle. It’s currently up to 835M, which seems like an obscene amount of RAM for the graphical environment. I saw this same type of memory leak under Hardy, under similar conditions, but to Intrepid’s credit, the system seems completely responsive and speedy. So it looks like I’m going to continue needing to log out and back in every couple days to free up the memory consumed by X.

Overall, I’m quite impressed, and not seeing any downsides to this release compared to Hardy, which was already pretty great.

Business Social Networking Geography: Yes Location matters

Saturday, August 23rd, 2008

Esther Schindler wrote a thought-provoking column on CIO.com last week, Business Social Networking Geography: Does It Matter Where My Contacts Are?

Although the Internet is global, and you may do business with people anywhere in the world, most people tend to look for people-networks close to home. Or do they? Should they? If the point of social networking is to connect with other people, ought it to matter where we are?

At Freelock, we have a handful of remote clients, but upwards of 90% of our clients are local. I founded the business on the assumption that people want to know who they’re doing business with, be able to see them face to face, and grow to trust them over time. Nothing breaks the ice like talking about a project in person, over a coffee or better yet, a margarita.

Good or bad, business gets done through personal relationships. How many deals have been cemented on the golf course? It’s a lot harder to say no in person, than it is with a quick dismissive email. So much communication happens non-verbally, through body language, tone of voice, and other channels that just aren’t available online. A video conference is a poor substitute for a face-to-face meeting.

I’ve gotten quite a bit of help from IRC. We have a private company jabber server so when we’re not in the same room, we can still have the feel of a team. We’ve had people helping us out from Bellingham, 120 miles north. The Internet enables some amazing things, and I definitely think it’s possible to work effectively at a distance. Many professions, including writing and coding, can be done quite effectively by individuals working by themselves, anywhere in the world.

But you can’t directly diagnose a connectivity issue in an office in Bellevue when you’re in India, or replace a hard drive. You can’t assemble a car from the other side of the world. And even for creative types who can work effectively on their own, relationships and trust only truly get cemented by meeting their editors, testers, or project managers in person.

Another founding principle of my business is that it’s much easier to ensure quality by having people work in person. If team members can do impromptu code reviews of each other’s work, quality goes up. The solitary developer working late at night may bang his head for hours against a problem that a colleague could solve in a 5 minute conversation. Having a team of people with complementary talents and different strengths working in one place leads to better results.

Once you’ve established that level of trust, remote work becomes more effective. You know when somebody’s cracking a joke, and it doesn’t sound so strange. You’re more likely to ask a quick question in a chat when you can preface it with a comment about an outside shared interest.

Yes, location matters. It’s not everything, and the Internet makes it possible to work together from a distance–but it still matters.

TLLTS vs. TWIT: Linux support slam-a-thon

Sunday, July 13th, 2008

The Linux Link Tech Show (TLLTS) has a great segment dissecting the criticisms/wild flames put forth on a series of shows on the TWIT network. Wanted to add a couple comments missing from their discussion.

First of all, the Mac Break Weekly show apparently spends some time bashing the open source community, calling out Drupal, and how difficult it is to solve “simple” problems like uploading images for blog posts. In practically the same breath, the hosts claim that the open source community never has any innovation behind it. Irony drips:

  • In the world of content management systems (CMSs), most of the innovation starts in open source projects these days, and Drupal is at the cutting edge of this with its powerful system of taxonomies, and hundreds of add-ons freely available.
  • I can think of a grand total of 2 proprietary CMSs that have anywhere near as widespread use as most of the open source CMS systems. One has turned open source itself: Movable Type. The other is Sharepoint, and it’s widespread because Microsoft has shipped it out on lots of its server products.
  • Complain about usability all you want, but name a proprietary product as powerful as Drupal, that’s easier to install, administer, and configure.
  • The TWIT.tv site itself is running on Drupal.

So let’s talk a little about innovation. While Photoshop may still dominate the world of graphic design, but the lines aren’t so clear when it comes to animation. The Blender project recently released its second short animated film, Big Buck Bunny. While you might argue about the strength of its story, you cannot deny that the technical effects are as stunning as any major animated film coming out from the big studios. And it was created by 7 people in 9 months, using open source software. Even the big studios like Pixar, Dreamworks, and Industrial Light and Magic rely on open source software to deliver their magic, such as CinePaint, POVray, and several others.

On the subject of innovation, KDE4 is breaking new ground and stirring up controversy, laying a bedrock that promises the ability to do things beyond the standard “Desktop” paradigm that was invented over 30 years ago and we’ve all used ever since. Meanwhile, the GNOME team is working on creative ways to embed web applications into your desktop.

But the real innovations of the open source community are all a few layers deeper in the application stack, all the plumbing that powers the Internet. Microsoft itself borrowed its early networking stack from BSD, one of the earliest open source operating systems. Domain Name Service (DNS) and email were first implemented on the Internet using open source software (BIND and Sendmail).

The open source community tends to snicker whenever Apple claims to be innovative. Its core “innovations” were all invented somewhere else:

  • The Mac Desktop interface borrowed heavily from Xerox PARC labs
  • OS X uses BSD under the hood
  • “Spaces” were in use in Unix systems for a decade before they arrived on the Mac
  • The “Time Machine” functionality in Leopard is standard in many source code management tools

To its credit, Apple polishes these features better than anybody else, making them easier to find and use by normal people. But many, if not most of its innovations come from somebody else.

Read the previous post for more discussion about Linux support.

How Open Source support is different

Sunday, July 13th, 2008

I started writing a response to a discussion in the latest “Linux Link Tech Show” episode, but ended up with something far too long, so I’ve split it up into 4 posts. The next post is about the TLLTS vs TWIT debate, and introduces this set of post. The previous two are about open source support–a true story of a support incident I had, and the unwritten rules of open source support. In this post, I analyze the fundamental differences between Windows, Apple, and Linux when it comes to support.

Dann and Linc had a quite spirited debate about the merits of having a company hire low-end tech support with scripts (Dann) versus having an experienced, savvy, tech professional able to really solve the user’s problem (Linc). Dann’s point was that it can easily be more cost-effective for both the support company and the end user to go straight to reinstalling a system if rebooting doesn’t solve the user’s problem, while Linc seemed to think a savvy tech person could get to the root of the issue much quicker, and brought up the point that there’s a cost to the frustration of users being put through the whole front-line support nightmare.

I’d suggest the situation is even more complex than that, but it also differs greatly between the open source projects and proprietary operating systems. First, let me make a bold statement:

Linux support is far better than Windows or Mac.

But it also has a completely different set of rules. Learn those rules, and you’ll be able to solve your problems more satisfactorily than it’s possible to do in the proprietary world. Let’s talk about these differences, looking specifically at a who, where, what, and how long.

Who can help with your problem?

Let’s take a look at who can help with your problem:

Level of support Windows Mac Linux
Very basic help, no charge Friends
Family computer guy
Newspaper columnists
Web Forums
Friends (fewer than Windows)
Family computer guy
Mac User groups
Web Forums
Friends (if you know any)
Local Linux User groups
Web forums
Mailing lists
Developers on main applications or distributions
Paid support Local IT consultant
Franchises like Geek Squad
Microsoft, application companies
Mac consultant
Apple Genius Bar
Linux consultants (like Freelock)
Distribution companies (Red Hat, Novell, Canonical, others)
Linux support companies (SpikeSource, SourceLabs, etc)
Application companies (SugarCRM, MySQL/Sun, Command Prompt)
Developers

The bottom line here is that while you probably know fewer people personally who can help you with Linux, there are more options for commercial support, and you can reach people who can do more to solve your problem for free, than you can with either Mac or Windows.

The fundamental reason for this is that anybody can read the raw source code of any open source product out there, and with enough skill and talent, can solve your problem without needing to pay anybody for the right to do so. In the proprietary world, only one company can help beyond a certain point: for Windows problems, that’s Microsoft. For problems in an application, it’s the application developer.

So the next question is:

Where can you get help?
Again, let’s compare the options:

Type of problem Windows Mac Linux
Very basic usage help Google
Friends/family
Forums
IT consultants
Seminars
Paid support from vendor
Google
Friends/family
Forums
Mac consultants
Seminars
Paid support from vendor
Google
Friends/family
Distribution Forums
Distribution mailling lists
IRC
Linux consultants
Seminars
Paid support from dozens of companies
Hardware problems Google
IT consultants (may or may not be able to help)
Microsoft
Hardware vendor
Google
Mac consultants (may or may not be able to help)
Apple
Hardware vendor
Google
Linux consultants (may or may not be able to help)
Distribution paid support (Red Hat, Novell, Canonical)
Hardware vendor (support for many vendors is improving)
Kernel developer
Linux users with the same hardware
Application developers for applications that use that hardware
Bug in operating system Microsoft Apple RedHat
Novell
Canonical
IBM
HP
Sourcelabs
Many other independent developers
Bug in application Application vendor Application vendor Linux consultant
Developer
Application vendors (often more than one can help)
Bug in interaction between applications You’re screwed. Report it to both vendors and hope they will work it out. You’re screwed. Report it to both applications, and get guidance on how to address the issue.
Hire a developer to create a workaround.
Hire somebody to work with each application to integrate a real fix.
Help switching to another application Application vendor (and you may have to pay them dearly) Application vendor (and you may have to pay them dearly) Application vendor, either old or new
Any application that uses the same open format
Any developer with knowledge of the underlying format

The main point of the table above is that in the proprietary world, the harder your problem is to solve, the fewer people can help you solve it. You quickly get down to one place to go, and if it’s in the operating system, it might be expensive or not possible to fix. In the open source world, it’s nearly the opposite case–it can be harder to find the simple quick answer to your question, but the harder and deeper your problem, the more places you can go to get help.

Where do you look for help first? This is the single stumbling block for most otherwise tech-savvy users new to Linux. To learn Windows or Mac you can take a class, talk to neighbors and friends, and find lots of very low-end help that way. For Linux, unless you’re friends with some hard-core geeks, you need to go online to find help. Once you’re there, it really depends on where your problem lies.

For just figuring out how to use a system, go to the forums for your distribution. The Ubuntu forums are a great place to ask general questions. Be specific about what you’re trying to do and you’re more likely to get help. Remember that this level of support is free, and people helping you are volunteering their time and knowledge. While you’re there, see if you can answer somebody else’s question–the more help you give, the more you’ll get in return.

The other fantastic place to go for help, especially for quick questions, is IRC. IRC is a system that provides chat rooms and instant messaging. Most open source projects with any community behind them have a chat room on irc.freenode.net. Install an IRC program like Chatzilla, Konversation, Pidgin, or any number of others, connect to irc.freenode.net, pick a nickname to use, and join the channel for the program or distribution you’re having trouble with. Ask your question nicely, and if you don’t get a response immediately, keep your chat program open for a few hours–not everybody is watching the channel every minute.

What kinds of problems can you solve?
Let’s look at the same types of problems as before, and look at the resolutions:

Type of problem Windows Mac Linux
Very basic usage help or problems Reboot.
Lots of good help available: documentation, classes, seminars, tutorials, books
Some help available: documentation, classes, seminars, tutorials, books Same types of help available, but far less widespread.
In many cases, the software interfaces aren’t as polished, and the help content is more menu- and feature-oriented than task-oriented–they explain the options, without telling you how to do what you’re trying to do.
Hardware problems Obtain driver from the vendor, and install.
Hardware vendors almost universally provide support for Windows.
If it’s supported by Mac, install the driver. If it’s not supported, you’re out of luck. Most external devices are supported on the Mac. Internal devices, you have far less choice than Windows or Linux. More and more devices have manufacturers providing Linux support. Many devices have solid drivers written by the Linux community, without help from manufacturers. A few devices have no Linux support whatsoever. Usually if you can’t get it working in Linux, it’s either brand new, or there’s a legal reason it hasn’t been done yet. Do your homework before you buy, and only buy hardware others have gotten working in Linux.
Bug in operating system Wait for a patch or service pack, cross your fingers and hope they fix it
Get a premium support contract, and pay Microsoft to fix your bug (note: even with the best support package, they may not do this for you)
Wait for a new release of the Operating system Report a bug, wait for the next release
Hire a developer to fix it
Find other people affected by the bug, and pool your resources to fix it
Bug in application Report it to application vendor, wait for them to fix it (or pay them to fix it) Report it to application vendor, wait for them to fix it (or pay them to fix it) Report it to application vendor, wait for them to fix it (or pay them to fix it)
Hire a developer to fix it yourself
Bug in interaction between applications You’re screwed. You’re completely at the mercy of one or both vendors. You’re screwed. Report it to both applications, and get guidance on how to address the issue.
Hire a developer to create a workaround.
Hire somebody to work with each application to integrate a real fix.
Help switching to another application Pay the company for access to your data
Pay a developer to reverse-engineer the data formats and extract it
You may be screwed–Apple has a reputation of making it really difficult to get your data back out of any of its applications Open source applications usually use open data formats. You may have other options that require no changes to your data. Anybody with knowledge can help.

What’s the key thing in this section? Addressing actual problems is within your control, when you’re working with open source. In the proprietary world, you’re entirely at the mercy of a single software vendor. If your problem is in the interaction between two different applications, you’re really stuck — there’s nothing you can do.

But in the open source world, there’s always something you can do. You can hire anybody with the skills to solve your problem, and fix it in the software itself. You don’t need any blessing from any single software vendor.

Open formats are perhaps more valuable than open source software, for most businesses. Because this is such a compelling advantage of open source software, many proprietary programs are beginning to open up their formats to allow other software to read them–their customers are demanding it.

How long will it take to solve your problem?
I’m not going to bother with a table for this one. The answer is nearly always “too long,” regardless of the operating system.

Actually, that’s not quite always the case–it depends on whether somebody has already solved the problem or not, as well as whether the solution is a fix or a workaround.

Many, many problems in Windows are not really fixes, they’re just workarounds. The only real “fix” for a virus-infected machine is the workaround of reinstalling your operating system. The only fix for lots of other minor issues that cause your system to slow down over time is to reboot. These are not fixes, they’re workarounds.

Real fixes take a lot longer, and need acknowledgment that the problem is real. Workarounds are band aids to get you through until there’s a real fix. And there are some real differences between the entire approaches of each operating system around these fixes.

Windows is chock-full of workarounds. Because Microsoft has gone to great lengths to maintain backwards compatibility of just about everything that’s been released for Windows since Windows 95, it’s full of workarounds to keep the old behavior. Rather than fixing behavior that might really be undesirable, they’ve had to patch it with workarounds because too many existing applications turned out to depend on that bad behavior. That, fundamentally, is why Windows is so big, bloated, slow, and painful to work with.

Apple suffers a different problem: changing their closed libraries too quickly for external developers to keep up. Each release, they break lots of things, and don’t always tell 3rd party developers ahead of time. This means the number of third party developers of Apple software is shrinking–they’ve managed to alienate quite a few. So their polish and high quality comes at the price of having a healthy thriving developer community outside the walls of Apple. There’s little transparency in this process, so developers outside Apple are always playing catch-up, and having to work around these changes in behavior.

Linux has its share of problems, too. Linux does not attempt to maintain “binary” compatibility between versions, though it does its best to maintain compatibility in source code. There is endless debate about the “correct” way to fix a problem, and competition between fixes. The challenge of this is that it can be hard for application developers to keep up, especially if they want to keep their source code closed and only ship software in binary form.

But the process is completely, utterly transparent. Anybody can see the progress on any fixes to any part of the system, and can jump in with their own solution at any time. It’s a true meritocracy, with those doing the actual work and providing the best solutions winning out over time.

The whole open source ecosystem is nimble enough to provide real fixes to technical problems, rather than just simple workarounds. If the source of the problem is design, it can take a long time to get the right design in place and resolve all the issues that changing the design causes in other applications. But when a bug gets fixed, it’s really fixed and usually doesn’t appear again.

An example of open source support

Sunday, July 13th, 2008

In my early Linux system administration days, when I was first trying to set up a mail server with spam filtering, I ran across a really puzzling bug in Dspam, the software I was trying to get working. While all the other users of the software were getting great results, with Dspam catching 99%+ of all their spam, it was only catching about 70% of my spam after quite a bit of training.

I posted my results, and confusion, to the Dspam mailing list. The original developer of this software (which has thousands of users), Jonathan Zdziarski, responded that that did not sound right. He asked if he could log into my server and see what was wrong.

I created a test account for him, and logged in to the same screen so I could watch what he was doing. As I watched, he put debugging messages into his code, ran several tests, and within 10 minutes had identified the problem: the 19-digit number he put into the database (MySQL) was different than the 19-digit number he got out. It was a storage error in somebody else’s software causing the problem, a rounding error. He filed a bug in MySQL, and it was fixed within a month or two. But he also had a workaround for me: change the data type to a set of characters instead of an integer. Problem solved.

The unwritten rules of open source support

Sunday, July 13th, 2008

What’s extraordinary about the open source community is that this level of support happens all the time, every day, without charge, in hundreds, thousands of projects out there. People that can get to the bottom of a problem and fix it at the source, not just provide a workaround, are directly reachable and motivated to see their software work as well as possible. They’re not hidden away from the public behind a large corporation, unreachable with layers of clueless support script readers stuffed between you and them. Here are some rules for getting open source support directly from the projects:

  • Before asking anybody, do your homework. Use Google, read the project FAQ, make some attempt to learn the basics without pestering people with questions they’ve already answered hundreds of times. Nine times out of ten, your problem has already been encountered and somebody has figured out a workaround.
  • Limit the scope of your question to the fundamental problem. Get to the point. I’m obviously guilty of being tremendously long-winded at times, but unless your question is right at the top and asked directly, you’ll probably get ignored. Developers are busy, they don’t want to read a novel, but they’re usually happy to answer a question.
  • Provide supporting details after asking your question. Many programs will create a log with lots of information that can help somebody diagnose your problem. Find what looks relevant in the logs. Specify what version of operating system, distribution, application, etc. Specify what you were trying to do, what you expected, and what really happened. But provide this stuff after asking your initial question–people aren’t going to wade through a long email to find your question.
  • Contribute something. The easiest way you can contribute is by answering other people’s questions. The whole thing works because people help each other, and this help goes both ways. If you always ask questions and never answer anybody else’s, or provide any other sort of contribution, you’ll eventually start getting ignored.
  • Always, always, be positive, respectful, and polite when asking your questions. Developers have a lot invested in their project, and insulting it won’t gain you any favors. Developers are under no obligation to help you either–you haven’t paid for it. Common courtesy is valuable. Complements are welcome.
  • Be patient. Sometimes the person who has the answer to your question is away from the computer. Usually you’ll get your problem solved quicker than you would calling some tech support line, but there are times it’s going to take a while. If you don’t get any response in a reasonable period of time (judged by how active the list or forum is, reasonable could be a couple hours or a couple days), there are several likely reasons: You haven’t been specific enough in your question; you’re in the wrong forum (e.g. users when it’s a developer question); nobody else is trying to do what you’re doing (in which case you may need to hire someone with the right skills); the project is dead (it happens sometimes–find another one); or the developers are swamped (give them more time, or come up with a new scenario that sheds light on your problem in a different way).

That list describes how we get open source support at Freelock. Aside from a couple unsupported hardware devices, or issues with proprietary programs, we have yet to get stumped, in over 6 years of extremely heavy Linux and open source use. We’ve never paid a dime for this support, though we have provided help to many others in return.

What’s git, and why do you use it?

Monday, June 30th, 2008

At Freelock, we’re always trying to figure out ways to do things better. Recently I started digging into a developer tool that’s making, as Bryan over at the Linux Action Show would say, my head explode.

For a long time, we’ve managed our custom code projects and business documents in a central repository, called Subversion (also known as svn). Subversion is relatively easy to understand–it’s like having a library of files you can check a copy out of, do some work on it, and then check it back in. Subversion is the librarian that tracks who has copies of what, and when they checked it out. So if Erik checks in changes to a brochure, and then Jill goes to submit changes to the same document, Subversion will say “hey wait a minute, that document has already been changed–you need to make sure you put Erik’s changes in your document before I’ll let you put in your document.”

This is great for managing conflicts between people working on a single team, or for code that is being developed in relative isolation from the rest of the world.

The problem is, we’re doing more than that–we’re taking code from various open source projects and either customizing it or building new applications on top of it. And so when the outside projects get updated, we need to manually update anything we’ve written that depends on that code. There is no longer a single repository where we control our code–there is our code library, plus another one for every project we use.

This makes managing add-ons for projects like Joomla or ZenCart quite challenging, because our add-ons get scattered throughout the filesystem to be able to hook into the right place. And if we have to touch a core file, we’re going to end up needing to re-implement our change with any update to that core file.

There are other issues we run into, managing our code and hosting, all of which take fairly time-consuming, manual intervention. Here’s the list:

  • Since we host and provide security updates for Joomla, Word Press, Zen Cart, Drupal, and others, we need to upgrade dozens of installations any time there’s a new release that has a fix for a security vulnerability. With Joomla this has happened quite a lot, and every Joomla installation needs to be upgraded individually–and tested. And since each installation is slightly different, we can’t manage them easily within a single repository, while updating the underlying code.
  • Templates, modules, components, blocks, themes, plugins, and whatever. Developing these types of add-ons are our bread-and-butter. But code for these often get scattered across an installation, making it quite difficult to manage just our add-ons while we develop them, or roll back to earlier versions if there’s a problem.
  • The Dojo Toolkit, and builds. We’re doing a lot of development with Dojo right now, to add desktop-like functionality such as trees, sortable tables, right-click menus, animations, and lots of other really cool things. However, if you don’t “build” the code after you write it, it’s painfully slow in a web browser. And due to the nature of how Subversion works, you can’t easily store a built Dojo tree if you ever want to change it again. Which means you’d need to build it every place you deploy it. And on some computers, it can take a long time to build–on our demo server, one of our projects currently takes 8 minutes.
  • As we get more directly involved with open source projects like LedgerSMB, we’re finding the need to change core files while we hack away at some particular feature. To do this, you create a branch of the code, work on your feature, and then merge your changes back into the “trunk.” If you don’t have access to save directly to the project repository, doing this gets a lot more complicated.

Git to the rescue. Git solves all of these issues. Read on for a technical discussion of how.
(more…)

Developing a Simple Workflow within SugarCRM

Friday, June 27th, 2008

Packtpub is running a sample from a developer’s guide for customizing SugarCRM. The author describes how to set up hooks for particular modules to build a custom workflow.

Custom workflows are a feature that is limited to the proprietary version of SugarCRM–they have not been available in the open source version. With custom development using techniques illustrated here, you can add your own workflows.

This looks to me like it’s written specifically for versions of SugarCRM before version 5. I haven’t had a chance to find out whether the same basic techniques would apply–SugarCRM 5 changes a lot of things from earlier versions, primarily with email handling and storing customizations in the database rather than scattered around files. The basic approach should work, however…

Developing a Simple Workflow within SugarCRM

Ten fantastic keyboard shortcuts in OpenOffice.org

Friday, June 27th, 2008

Some handy tips for users of OpenOffice.org, looking to get away from the mouse…

Ten fantastic keyboard shortcuts in OpenOffice.org

Top 10 reasons why you should buy Office 2007

Monday, June 16th, 2008
  1. You want to make sure nobody will be able to read your documents in 10 years
  2. You want to help your buddy who works for Microsoft have enough income to buy a private island in the Carribean, because maybe he would invite you to come for a weekend
  3. You feel sorry for the PC on the Mac commercials
  4. Your buddy is buying it for you from the Microsoft company store, so you’re actually saving hundreds of dollars! You can’t get those types of deals on free software.
  5. You hope that the extra emails it takes between you and your customers, partners, and vendors to get formats that they can open will improve your relationship with them
  6. Having the newest software from Microsoft makes you cool
  7. You want to extend Microsoft’s monopoly on the desktop, it’s just easier that way
  8. You have a big technology budget, and can’t think of any better way to spend those dollars
  9. You already spent the money on it, may as well force others to pay their Microsoft tax, too
  10. You’re a big fan of Survivor, and like being dropped into an unfamiliar environment and having to figure out all over again how to do the things you need to survive
  11. (Bonus!) You don’t know a better solution exists

If your reason for purchasing Office 2007 is #11, drop us an email and ask us how open source software can make your business run better.

Managing an Open Source project - LugRadio

Thursday, June 5th, 2008

LugRadio has a very interesting discussion in their current podcast about the role of a community manager, in creating a vibrant community around an open source project. They came to the conclusion that each project needs a leader that people trust to take the project in the right direction, someone to be a diplomat to resolve issues among people in the community and keep everyone rowing in the same direction, and a strong technical lead to solve the hard problems.

This sounds quite similar to the challenges a small business faces. “The E-Myth Revisited,” by Michael Gerber, is essential reading for anyone wanting to start a small business, and some of the same ideas apply to building a successful open source project.

Basically, Gerber says you need to have 3 personalities in your business:

  • The entrepreneur, the person with the vision to drive the business/project forward, always a step ahead working on what’s next
  • The manager, somebody to make sure all the work gets done on schedule, delivered on time, and that everybody is working in the same direction with the same priorities
  • The technician, who actually does the work

And small businesses, like open source projects, are almost always started by technicians, people who just know they can do a better job than anybody else, so they set out to do it themselves. The reason why so many businesses fail is because the founders spend all their time building something without setting enough overall direction or managing their cash flow. Sound familiar?

The key to creating both a successful business and an open source project is balancing out these 3 personalities and making sure all are represented to an appropriate degree.

Ask Freelock: Why Ubuntu?

Thursday, June 5th, 2008

Patrick asks,

Why not OpenSuSE, instead of Ubuntu?

At Freelock, we provide a maintenance service contract to manage Linux servers. For a fixed monthly fee, we provide monitoring, system updates, application updates, and our help recovering anything that goes wrong with an upgrade. We’re looking at adding disaster recovery to the mix, raising the price to cover the cost of backing up all of the data and providing varying service level agreements on how soon we will recover your machine from a total loss. But for our base price, we only support Ubuntu and CentOS, with a preference for Ubuntu. So Patrick asks, why not OpenSuSE? Here’s my reply:

Hi, Patrick,

There are literally hundreds of different distributions of Linux, and 7 or 8 that are very widely deployed in server environments. The reasons Ubuntu is our preferred distribution include:

  • No separate version of operating system–Red Hat and Novell/SuSE keep some of their stuff for their commercial version
  • Commercial company backing it (Canonical, LTD), support contracts available
  • Strong community support, lots of friendly help available
  • “Long Term Support” releases, with a commitment by Canonical to maintain security releases for 5 years on designated versions
  • Superior upgrade path when a version reaches end-of-life
  • Nice balance between cutting-edge versions of new software, while making sure they’re stable
  • Easy package management, well-built packages

OpenSuse has no commercial support available, and no commitment on the part of Novell to provide long term support to their free versions–you have to buy SuSE Enterprise Linux to get that level of stability/support, and that’s not the same software–they bundle older versions in their enterprise distributions that often don’t have features we’re coding on top of…

The upgrade path is another nice feature–we’ve had very good success upgrading Ubuntu boxes in place, without having to install an entirely new system and migrate the data over.

We support CentOS as well, which is a free version of Red Hat Enterprise Linux, because some of the software our clients run are only available for Red Hat, so we have to… CentOS doesn’t have as good an upgrade path as Ubuntu, so we don’t include system upgrades at software end-of-life with that. We have supported SuSE boxes in the past, but I think we’re down to a single one running some legacy software. The main reason we discourage it is to streamline our processes–it’s much easier to administer a bunch of the same operating system, than having every box be a one-off system.

We’ve been doing this long enough to have to upgrade several servers because the OS has reached end-of-life and there are no more security releases available. Of the free distributions, the only ones we can deploy with confidence knowing we won’t have to upgrade for at least 3 or 4 years are Ubuntu, CentOS, and Debian. While there are many other solid distribution choices you could make, none of the others quite stack up to meet our needs as well as Ubuntu and CentOS.

This is a new feature we’re starting: Ask Freelock! Have a question about using open source in business? Drop us a line, ask us a question. We’ll do our best to answer.

The EU crashes Microsoft’s party

Monday, March 3rd, 2008

A couple weeks ago, the EU slapped Microsoft with a $1.35B fine, less than a week after Microsoft had made a big fanfare about their new “open” policies.

Todd over at Napera asks,

Certainly the terms Microsoft has been offering companies since the EU decision in October 2007 are extremely reasonable. Given Microsoft’s new open protocol documentation and their patent pledge for open source developers, what’s not to like?

I haven’t seen any pundits or commentators in the US defending the EU decision. If they are, what are their substantive points?
Napera Networks » The EU crashes Microsoft’s party

Hmm. Let me see if I can shed some light…

First of all, Microsoft wants you to believe that open source developers are all a bunch of hobbyists creating code for no pay. Their recent pledge is to not sue open source developers developing non-commercial systems.

Boy, what a deal that is… Microsoft gets all this open source development for free, right? And they can still charge anybody who dares to compete with them commercially? Great deal–for Microsoft.

The reality is, a great number of open source developers engage in commercial activity. Many successful open source projects are backed by commercial companies. OpenOffice.org, JBoss, SugarCRM, MySQL, PHP, the list goes on. By definition, open source means you can use and redistribute software for any reason, including commercial activity–by excluding commercial entities from patent protection, Microsoft is making a marketing play without making any real concession.

Their real agenda here is to give the illusion of openness so they can get their OOXML format approved as an open standard, without giving up any control over the format. Never mind that they were part of the committee developing the ODF standard and didn’t bother to contribute. Microsoft has no interest in working with other companies to develop an open standard–they want to be proclaimed the standard so they can demand “reasonable royalties” from everyone else, and all the rest of this is just marketing spin to try to put one past the EU, who so far have managed to see through all this bull.

Secondly, Microsoft seems to think the only healthy software marketplace is one that revolves around it. It got where it is by using all sorts of unethical, hardball business practices to drive its competition out of business. This is classic anti-competitive behavior, and is the reason it’s been the target of so many actions.

Microsoft has built a large ecosystem of developers and service providers all gathered around the MS stack. Yet you look at the stack and there’s not all that much vibrant activity, at least not compared to the open source bazaar. Take content management systems as an example. In the Microsoft world, you’ve got Sharepoint. You’ve got a couple of ASP.net open source projects like Dot Net Nuke. And that’s about it.

On the open source side, you’ve got overwhelming choice, and some of them quite great. Instead of one size fits all, you can go shopping for just the features you need, and get it all for a great price–free, if you have the technical ability to make them work. Joomla, Drupal, Plone, MediaWiki, Typo3, Postnuke, Word Press, Serendipity, several hundred different options for you to choose from. Which looks like a more vibrant marketplace, with more competition and more choice?

Ah, but then you ask about standards–isn’t it great that Microsoft makes it so simple for you to do what you need to do? You don’t have to make all those choices. Soviet bakeries were so much better than American supermarkets, too, huh?

Oh, but wait. Who invented http, rss, the world wide web, email, the spreadsheet, the database, the word processor, or anything else we use our computers for? Hint: not Microsoft. And the first few things in that list were created in universities and other open source, collaborative environments.

Finally, to speak directly to the EU’s decision, how does letting Microsoft get away with their monopolistic, anti-competitive behavior help the EU in any way? By protecting their software industry from Microsoft, they’re fostering an environment that can lead to a much more competitive, fertile ground to grow their own software industry.

No other industry (other than possibly the utility companies and the railroads) have had a single company that so dominates the industry like Microsoft dominates software. How can that be a good thing? I know from personal experience a half a dozen companies that Microsoft crushed, and for the most part their technology with them. This mono-culture of software has led to all the trouble with spyware and botnets and through them, spam. I don’t think we’re better off with our Redmond overlords.

I for one was happy to hear about the EU’s decision, glad they were able to stand up against monopolistic practices and do something to actually help their software industry thrive.

New E-Commerce software: Magento

Saturday, January 19th, 2008

Just ran across a new Open Source shopping cart system, Magento. We’ve been using Zen Cart for a while now, and it’s great to see an alternative.

We actually really like Zen Cart. It’s fast, clear, and customizable. From a quick look at the Magento demo and feature list, it looks like they’re starting with Ajax in mind, but it doesn’t look like there’s that much different in the administration area. Will have to keep an eye on this one.

I give up. Trackbacks and Pingbacks now closed.

Saturday, January 19th, 2008

It’s too bad the spammers are out to piss all over the public commons. Since I’ve started writing more regularly here, I’ve been getting inundated with pingbacks and trackbacks, and have to keep marking them as spam, a couple dozen a day. Don’t have time to do this, so I’ve just turned this off… I appreciate any links you’d like to make to here, but please fill out a comment if you’d like to continue the discussion so I’m aware of your post.

I used to use Akismet to filter out comment spam, but spammers now seem to make each post unique enough that that became ineffective–I would still get dozens of comments to moderate every day. So then I switched to the Recaptcha.net system you can see on any of my posts–which has been working great for comments, but it doesn’t attempt to deal with all the automated trackpacks/pingbacks.

So here we are, back to comments only. Please leave one, or drop me an email here if you’d like to discuss anything I’m writing about, and are not just another spammer…

Reliable code: building in robustness

Saturday, January 19th, 2008

Ok. Last post on the quality code series. One of the downsides of getting older is realizing you do have shortcomings. You know how when you’re young, going into a job interview, the toughest question is the one about your weaknesses? We’re all quite blind to our weaknesses, until experience comes up and forces you to realize you’re not perfect. Sometimes this happens early, sometimes late, but it happens to everyone sometime.

My coding weakness, it turns out, is reliability. I’m terrible at handling errors, building test frameworks, doing unit testing. I find all of that stuff quite boring. But it’s essential to building a reliable application.

Reliability and security go hand in hand. In security, you’re looking at the attacks, and making sure your code is secure against them. In reliability, you’re identifying what each chunk of code expects to get, and then define how to handle exceptions, unexpected input. Done correctly, reliable code is secure. But it’s a total pain to do, and it takes a lot longer to get there.

One of the code samples I examined recently was set up in a completely class-driven way, though I would not call it object oriented because none of the classes extended other classes. It was a rather simple, flat collection of objects and helpers and interfaces. It was not powerful. My guess is, it is not fast. It did not look very customizable. But it was certainly clear, and every single method inspected every single parameter, making sure the input was valid. Calls to other objects had extensive error handling built-in — this application looked like it could not fail without notifying the programmer exactly where the failure was, with helpful feedback.

This is tedious work. I save it for the polishing phases of a project, focusing on getting things to work in the first place. But there’s a strong argument to be made for building reliability into each module from the start. It’s a very different style of programming, and takes a lot longer to get there, but the end result will inevitably be more secure, less buggy, and more able to account for every possible scenario–even if it handles a scenario by saying “I can’t do that yet.”

I think there’s a personality difference between these development styles. The artist figures out some innovative way of solving the problem, gets a proof-of-concept working brilliantly quickly, and cranks through code producing a huge amount in a short amount of time. The craftsman takes a slower, methodical approach, crafting each module individually, building unit tests to make sure it works correctly as he goes, and building a system piece by polished piece.

Successful projects need both. The artist/hacker provides vision, drive, and momentum. The craftsman makes sure the system can handle the load, and can prove it’s doing what it’s designed to do.

The 80/20 rule comes into play here. 80% of the features can be hacked together very quickly, in the first 20% of the project. To make the project stand the tests of time, handle everything that might be thrown at it, and act as a foundation for a business or a mission-critical part, you need the craftsman to do the remaining 80% of the work to finish the job and get that final 20% of the functionality complete.

So here’s a checklist for evaluating reliability of a project:

  • Is the program broken up into discrete modules that can be completely tested one at a time?
  • Are there unit tests built for each module, testing the output for normal and exceptional conditions?
  • Is the input to each module validated and properly tested to handle all possible things that may be passed to it?
  • Does the module handle non-normal input, and raise the appropriate errors?
  • Are there regular tests of the software as a whole, and each module, to identify tests that fail, or regressions in the code?

The only way to ensure reliability is through rigorous testing. Some of the newer programming practices rely on test-driven development–first you define what a module does, then you develop a test for it, and then only after all that do you finally develop the module until it passes all the tests.

In a small business environment, this all may be too much overhead. 80% of an application may be enough, and at 20% of the cost, much more inline with the budget. But when you need something to be completely reliable, take a look at the testing framework, how much it covers, and how much of the application passes the tests.

On Vendor Lock-in

Saturday, January 19th, 2008

I was listening to the latest episode of LugRadio the other day, and they had a discussion on vendor lock-in by open source distribution companies. I think they missed the point about vendor lock-in: that it locks users into a particular vendor, usually through some means that makes it hard to switch to a better solution later. So I wrote up a reply to send to them that I’m posting below, slightly edited. There is also an ongoing conversation about the topic at the LugRadio forum, and I see several posters are making the same points that I do here.

Open source business is the antithesis of vendor lock-in. Vendor Lock-in is when a vendor uses some sneaky, underhanded, unadvertised method to make it impossible to recover any of your original investment if you ever decide to go with a different system. Vendor lock-in is accomplished by using all the dirty tactics the proprietary software world has used for ages–closed systems that lock away your data, hidden undocumented features, patents, and sneaky licenses.

What you described on the show was not vendor lock-in. It’s called healthy competition, and it’s how open source software innovates. How is optimizing your client OS to work with your server OS vendor lock-in, if anybody else can see what you’re doing and do the same thing? Furthermore, how is it different than competition between KDE and Gnome, or vi and emacs, or any other of the many long-term competitions in the open source world?

Any distribution that is not looking for ways to improve their users’ experience is on the fast track to irrelevance. Take a look at some recent examples you should’ve used in your discussion:

* Xgl vs Aiglx: Novell went off and created Xgl, while Red Hat essentially recruited a bunch of other projects to do the same thing in a different way. Different distributions became real-life test beds for real innovation, and the better technology won.

* Xen. Novell and Red Hat have a great lead over Ubuntu on management tools for Xen. You could’ve accused either of those companies of trying to provide better experiences for their users, but that’s just good business, not vendor lock-in. Ubuntu may be behind, but they’re able to pick and choose their approach to managing Xen–nothing Red Hat or Novell has done is keeping their technology out of Ubuntu or any other distribution looking for enterprise customers. Neither Red Hat or Novell has achieved any kind of lock-in with enterprise customers–what they’ve achieved is leadership.

* Upstart. Here’s an area Ubuntu pioneered, and others are adopting.

* LTSP, K12LTSP vs Edubuntu.

I could go on and on. So I will. Distributions are always trying to shine at some particular set of features. Users decide which ones are appropriate for their needs. This is a fantastic thing. If Ubuntu weren’t trying to make their servers work particularly well with their desktops, they open an opportunity for another distribution who would. As long as a distribution can stay ahead of the competition technically, they deserve all the success they get–they’re pioneering the way, and the whole open source community benefits.

Okay. Now here is what would be vendor lock-in. If Canonical created some tricky way of making their servers talk to their clients, and then patented it so they could sue anybody else who tried to do the same thing, THAT would be vendor lock-in. If Red Hat embedded some private key on their commercial server that unlocked some turbo-samba supercharger, and encrypted their algorithm so nobody else could see it, and then put the key to unlock that speed in their desktop, THAT would be vendor lock-in.

But any open source company that tried such a tactic would be instantly cut off from the rest of the community–and they would probably have to violate a bunch of GPLd software to do so…

The competition between distributions make all of them better. While we’re all racing each other to see who can innovate faster, we still get the benefits of each other’s code, and Microsoft and Apple are starting to disappear in the dust in our rear view mirrors.

One other point I’d like to make: the earlier an open source project tries some new tactic to improve computing, and commits code to a repository the whole world can see, the better. Prior art is the key to defeating all the frivolous patents companies are taking out. If somebody tries something really inventive to eke out a bit more performance, I want that in a public Subversion revision associated with a date and a free license–it’s the best insurance we’ve got against a broken patent system.

On Patents and Free Software

Saturday, January 19th, 2008

I’ve spoken with a lot of entrepreneurs around Seattle, who have a misconception that using open source might somehow force them to give away their intellectual property. Intellectual Property is a hot topic around here, and entrepreneurs are told regularly how they need to have some to get funded. Yet they often think they can add their patented idea to free software and lock up their core idea. It’s a bit funny how they want to have their cake and eat it too.

I’m talking specifically about patents here. My understanding of the intent of patents is to give the originator of an idea a legal monopoly that allows them to invest large amounts of capital to bring a new innovative product to market, for the benefit of the rest of us. In an industrial age, patents make a lot of sense–building an assembly line takes a lot of capital, and if you have a bunch of competitors, nobody would make the investment to build the infrastructure, if they couldn’t lock up the market and get paid back for their investment.

Now, I won’t go into the social ramifications of this arrangement, but I’d like to make two arguments about patents in the age of software here:

  1. The cost of building a distribution and manufacturing network for a software idea is pretty much nil.
  2. Very few software ideas are non-obvious and innovative, or worthy of patent protection.

On the first point, if you had to build or buy your whole set of tools to run your application–compilers, web servers, operating systems, text editors–then yes, maybe you need some sort of way of protecting your investment in all that infrastructure. But with free software, you get all of this for free and have it deployed today on a $600 computer. Your next dollar spent is in your time getting your application actually written. The individual craftsman working from home after hours can develop software in his spare time that can rival anything coming out of a venture-funded startup or a multi-million dollar corporation with the help of all of this free software. Why does the startup need protection from a solo garage programmer? The only reason I can think of is to keep free-market economics from harming the investors, and profits going into the pockets of the entrenched players.

Patents take time and money to obtain. In the world of free software, programmers are far better served creating their idea and bringing it to market first, rather than wasting time and money on patents. Developing a solid program quickly and accumulating a base of customers for your service is going to be the best way to stay ahead of your competition.

So the big question I have for startups is, why should you get all the benefits of Free software with no financial outlay and ability to bypass all sorts of startup cost, and then keep your invention protected by patent? If patents protect a large capital investment necessary to bring a product to market, but then suddenly there is no large capital investment necessary to do so, why should you still need a patent? You can bring a product to market today with a few hundred dollars and a lot of elbow grease.

Of course, you might still be trying to get fabulously wealthy by locking up your idea so nobody else can use it. Fine. Take out your patent. Buy licenses from all the proprietary vendors to use as a platform for your idea. Don’t use software covered by the GPL, because you would not be able to protect your patent when you distributed your product–the GPL is incompatible with your patents, and you would lose your license to use the GPL software. Pay a whole lot more for startup costs, all to protect your fine idea… and then you’ll run up hard against the second point I’m making here: lots of other people have the same idea as you.

Our patent courts are getting inundated by suits from patent “trolls” who have purchased patents from inventors or researchers, and then sit on those patents purely for the purpose of suing others for profit. The targets of their lawsuits almost always had no awareness of the patent they’re being sued for violating–they came up with the same idea independently. Why on earth would we reward the person who filled out a bunch of paperwork to take out a patent, and punish the person who actually brought it to market so the rest of us could benefit?

Patents are supposed to be innovative, and non-obvious. The fact that many different companies come up with the same ideas independently all the time should indicate that those ideas are obvious to people in the field. Because the cost of bringing these ideas to market have dropped to virtually nothing, software companies do not need patent protection–there is very little capital outlay necessary to protect. Our current patent system punishes innovation, instead of promoting it.

Fortunately for the open source community, there are several things that make us more resistant to the patent threat than proprietary companies. We should assert these points whenever someone in the community is threatened by a patent holder:

  • No big pot of money. Because we don’t need much capital to get started, there’s not really any prize for patent trolls to go after. The patent trolls attack software companies, and their goal is not to drive the company out of business, but to profit off somebody else’s work. If there’s not enough cash in one place to provide that profit, they won’t bother to try. They’ll keep suing Microsoft and Blackberry and all those other venture-backed startups that still think the patent system isn’t broken.
  • Prior art. Here the public process of open source projects is a huge advantage. One of the best ways of invalidating a patent is to prove that there was prior art. What matters for this is the date of publication–was there prior art published before the date of the patent application? If so, and if that can be proven, it can completely invalidate the patent. Well, the Internet is nothing if not a big publishing machine. A public repository with revisions available by date seems to me like a great way of proving when an idea first entered a codebase of a particular project. Back that up with a look in the Wayback machine or a Wikipedia article, blog entries, IRC logs, and we can prove prior art with any discussions that happened before the patent application.

    Those poor, poor proprietary companies… they can’t even talk about things they’re trying to patent until they have their application in, or they might invalidate their own patent. When it comes to validating patents, the first date of publication or patent application wins.

  • The GPL. GPL v2 prevents patent holders from providing patent licenses to some recipients of the software, but not others. GPL v3 makes the rules much more specific, basically making covered software incompatible with patents. If you patent something you’ve extended from GPL v3 software, you’re violating the license and lose the right to use that software. So much for that business model.

Patents were originally designed to make it financially possible to bring innovative products to market so the world could benefit from that innovation. The current patent system, at least for the software world, does the opposite, standing in the way and penalizing innovation instead of promoting it. The Free Software movement is trying to do the same thing patents were created to do: make it possible to bring innovations to the public and protect innovators, in the face of a broken patent system. And while free software has taken away the potential for huge profits, it has also taken away the huge costs.

I was talking with a programmer last week about open source. He kept asking, “but how can I make money programming free software?” He seemed to think he was entitled to develop his idea, control it from start to finish, get venture funding, bring it to market, and everybody would buy it and make him the next Bill Gates. He kept saying that free software was not friendly to the community, because it took away everybody’s ability to make money. He seemed to think that proprietary software companies developing in a closed ecosystem was the key to developing good software, that that was the only way to make money in software, so if you didn’t work with his software community, you wouldn’t make any money.

I asked him where the money came from, and his answer was “the customers.”

Ah, so let me get this straight: customers are going to fund your closed ecosystem of buddies all trying to corner the market on particular ideas, just to keep this group of developers making money. Really? Even when there’s a completely viable alternative that does every bit as much as your system, without vendor lock-in?

Free software is, if nothing else, an advocacy group for users. Customers are the users in this case. Free software is software that users can use for whatever purpose they wish, can give to anybody they want, and change to suit their needs in any way they want–as long as they don’t restrict what other users do with it.

Free software is about community. However, in the free software world, users and customers are part of the community, not merely an external entity funding it all, a sugar daddy. In the free software community, the lines between users and contributors, between customers and vendors, become quite blurry. Doing something at the expense of part of the community, just so you can make a fabulous profit, isn’t going to keep you in business very long.