Job satisfaction and open source

having colleagues or management mistreat, misrepresent, or simply misunderstand an elegant and powerful idea is tremendously demotivating.
Written by Paul Murphy, Contributor
Do you know what makes an engineer happiest? An efficient, elegant, solution to an engineering problem. And the most elegant solutions of all, of course, are the ones that reduce complexity while solving multiple problems at once.

This seems to be a basic human thing: watch babies for a while and you'll notice that they smile when solving what must be, for them, very difficult problems - like how to roll over or get mommy's attention.

On the hardware side of computing the biggest technical challenges facing current designers come down to balancing processing power against input power and heat generation. Thus both of the solutions we're now seeing enter the market, Sun's CMT/SPARC and IBM's cell, represent attempts to address these issues in more or less elegant ways.

Both solutions ultimately rely on a simple proposition: to reduce input power while maintaining processing power, "just" reduce the total distance you need to push data internally. Thus IBM's cell hardware combines a grid on a chip, reducing the distance between machines in a traditional grid to the distances between components in a microprocessor -i.e. from feet to nanometers, with a control protocol intended, like Sun's similar openGRID framework, to reduce internal data transfers.

Engineering solutions, however, are not business solutions. - thus an engineer can produce something amazing, only to have business management either refuse to bring it to market because they think it doesn't meet a customer need or, worse, demand that it be tied to some fundamentally inimicable product line. This is part of what happened, for example, to DEC's Alpha CPU in the nineties or, more recently, with BMW's use of embedded NT in otherwise more or less serious high end cars.

That same kind of thing happens, although on a smaller scale, every day in every major organization: a great idea, something that filled its originator with the joy of discovery, gets misunderstood, rejected, mangled, or otherwise mishandled or misapplied by others in the organization.

For most engineers and software people it's the ideas and solutions that count, not the public accolades that come with acceptance - but, for almost everybody, having colleagues or management mistreat, misrepresent, or simply misunderstand an elegant and powerful idea is tremendously demotivating.

So how can IT managers reward good ideas while avoiding the demotivating consequences that come from an organisational structure in which the swine get to pick the pearls?

The right answer is to change the swine: for every new idea, choose or create an audience likely to appreciate it.

In a very few cases that means radically changing the business. That's what Sun is doing, for example, as they line up the entire company behind the CMT/SPARC idea -educating the marketplace to understand how power and heat drive an engineering solution that's elegant and efficient.

In most cases, however, cool isn't enough and major business change isn't a real possibility - so how do you get past the reality that good technical ideas, however exciting, don't wag large scale business, academic, or government organizations? Easy, sidestep the whole demotivation thing by helping your people take good ideas they can actually make work, but which aren't seen as of direct competitive value to your organization, into the open source world.

The open source world is huge and diverse. If the ideas you push out are any good, there will be an interested and appreciative audience.

The costs are small, and there are business benefits - for example, ideas exposed to others often come back in genuinely useful form. Most importantly, however, making open source contribution a regular part of your way of doing business will motivate people to come to work every morning, to do your recruitment for you, and eventually to become increasingly responsive to the business and user issues driving your own decision making.

Editorial standards