The smallest Linux computer in the world

IT is getting smaller, faster and cheaper all the time. The effects on enterprise IT will be profound.

The smallest Linux computer in the world is the Picotux, and it is really tiny. It is 35mm x 19mm x 19mm, and weighs just 19 grams.

The Picotux has been around for a couple of years. Its main use is in automation, to network-enable other devices, not as a general-purpose computer.

The Picotux is a super example of how processors, storage and networks are getting smaller, faster and cheaper all the time.

This trend will continue. New developments, such as quantum computing, offer unimaginable leaps forward.

Let's fast-forward a few years, and imagine a device:

• The size of a mobile phone.
• Enough processing power, storage and connectivity to run your entire organisation.
• Automatically replicates itself to another similar device elsewhere, for resilience.
• Negligible price.

What difference would this make to how you run your IT?

This is an important question because if we can not answer it we may have no part in the future. Even if our imaginary device never actually comes about, it represents the direction we are heading in and we need to understand our response.

This is a difficult question because our perceptions of IT are so bound by the restrictions of yesterday, when IT was so expensive and so cumbersome that it had to be centralised.

This is not just about hardware. IT management and design have assumed a centralised and technologically constrained model. When we talk about enterprise architecture, project portfolio management, IT security, and nearly any other aspect of IT management, we assume that there is a central organisation that has control over IT. Designing IT as a series of architectural layers - application server, database, data storage, network - is deeply rooted in restrictions of technology.

Enterprise IT will not disappear. An organisation's IT - the storage, processing and communication of information - is too valuable an asset to be ignored, or left to the vagaries of end-user spreadsheets.

But we do need to think what system architectures and management structures will make sense in our future unconstrained world, and start moving towards these.

I think the key to this is structure. Just because you will be able run everything on a single device, it does not mean that you should. Some structure makes sense because it helps us understand and manage. But what principles should we use to divide IT into chunks, and what rules should we have about the relationships between chunks?

My personal view is that system will become:

• Self contained - no externally visible architectural layers such as databases or storage.
• Independent - no assumptions about other systems other than well-defined message passing.
• Aligned - clearly owned within the organisational structure, where the information, processing and communication of the systems reflects the responsibilities of the part of the organisation that owns the systems. (Which may involve restructuring the organisation to exploit the efficiencies that IT can bring.)

I may well be wrong. You may well have a different view. But the one thing certain about the future is that it is coming. We need to prepare ourselves for it, or risk being left behind.

© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Shift risk management forward

We can reduce risks by shifting our management of risk to earlier in the system life cycle

As a generalisation, project staff take too many risks and support staff take too few.

Designers take too many risks. They use the latest tools and the latest design approaches. They write their own frameworks and components because standard ones are "not good enough". They use advanced features and extensions to get the best out of the technology. But new, unusual or unique designs are hard to support.

Project managers take too many risks. Their view of risk is limited to project delivery: being late, over budget, too few "resources", that sort of thing. In the name of risk, they cut back on testing and documentation because of delivery dates. They are not concerned with the long-term risks of the solution. But if they are not managing long-term risks, who is?

Support staff take too few risks. They do not upgrade to the latest operating systems. They tack on new bits of program and data, rather than re-engineering the whole. If new technologies come along, they use wrappers and compatibility layers. They make as few changes as possible, just in case the system breaks. "If it ain't broke, don't fix it" is their motto. But without re-engineering and upgrading, systems soon age and die.

I understand both. Project staff are judged on their ability to deliver on time and to budget, to meet requirements, and to use modern and fashionable technology. They are rarely judged on the long-term consequences of their decisions.

Support staff are judged on their ability to keep systems running without problems. They accept gradual decline and early obsolescence, rather than proactive maintenance that could keep systems running for longer.

Although it is understandable, it is not good. We need to shift our awareness of risk to earlier in the system life cycle.

Part of this is about changing our definition of risk, seeing not just project delivery risk but whole solution life cycle risk. Project managers in particular need to worry less about delivery and more about what they deliver.

You can rebalance risk by involving support staff in projects, or getting project staff to work in support. There may be some friction between the different viewpoints, but this is a good thing. Working through the arguments helps build much better systems.

You can assess projects for whole life cycle risks. The ISO 9126 standard contains a useful breakdown of quality that includes long-term risk factors like maintainability, as does the system governance system review. This type of assessment encourages risk reduction practices, such as using only well-established conventional technology and building comprehensive test packs.

If we make projects more risk aware we reduce risks during support. Systems are more conventional, easier to understand, easier to change. It is no longer too risky to upgrade, or to re-engineer the solution. Proactive maintenance makes sense. Systems can be kept in good condition for longer.

Shifting risk management is a challenge, but one that we must rise to if we want to deliver systems that meet their full potential.

© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Open source hypocrisy

I use free and open source software all the time, but I have not open sourced my own products. Am I an open source hypocrite?

Open source software is brilliant.

• It is free.
• You can keep up-to-date for free.
• It is flexible, for example you can ship it for free as part of other products.
• It is viable, with lots of free support and the option of maintaining the code yourself if you really have to.

My company develops some software products, all based on free and open source software, but we charge a license fee. Are we just cynical freeloaders?

I worry about this from both the moral and commercial viewpoint. But I think that what we do is justified on both counts. Here's why.

Many open source contributors are truly altruistic, and I really admire them for that. For many others, contributing to open source is part of a paid job. It could be that they work for a company that provides services around the software, has a commercial interest in influencing its direction, or has commercial reasons to compete with paid-for software. It could be that they are researchers or academics with salaries or grants. I also admire these contributors for their skill and dedication, and I am sure they work many unpaid hours too. But I don't have a regular salary, and I think that risking my own money on uncertain return is not less moral than being paid a regular salary.

Although it's not a very clear distinction, most major open source software is "tool" rather than "product". There are open source tools for writing, for graphics and for audio, but we would not consider that the books, artwork and music that people produce using them should always be free. The software I produce is part of a broader service, a framework for the long-term management of IT systems, and comes bundled with consultancy materials. Although I use free tools to produce it, my software is very much part of a broader product.

Open source works well for software with a large user base. It does not work well for niche products. I could not go to a potential customer and say that we get unpaid volunteers to develop and support our product. It is much more credible to ask for our (very modest) license fees in return for defined development and support.

From my point of view and that of our customers, we simply could not do what we do as open source. The choice is "proprietary software" versus "no software", not "proprietary software" versus "open source". Of course this could change. As interest in system governance grows, there may be competitive need and practical opportunity to move to an open source model. But it is still a new subject, so we have neither the need nor the opportunity.

It is not for me to judge whether I am a hypocrite. But from my point of view, I do understand why some software is open source, and some is proprietary, and I don't lose sleep over it.

© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Inkscape and The Gimp

Inkscape and The Gimp are full-featured open source graphics programs. Even if you are not a professional artist or designer, they have plenty of features that you will find useful.

I am one of the world's "graphically challenged" people. I got 12% in the one and only art exam I ever took. But even I need to use graphics occasionally. I'm a great fan of free and open source software, and so I thought I would share my experience of two of the leading open source graphics packages.

The GNU Image Manipulation Program, Gimp, is a picture and photo editor. It is a long-established product, and has been around for over ten years. It provides the "simple" features that novices like me use - crop, resize and rotate. But it also provides literally hundreds of features for more advanced users. (I counted almost 500 menu options!)

Gimp is an alternative to paid-for photo editing software, such as Adobe Photoshop and Corel Paint Shop Pro.

Inkscape is a drawing tool, for diagrams, pictures and illustrations. It is an alternative to software such as Adobe Illustrator and Corel Draw. Inkscape has been around for three or four years, though it is based on earlier open source drawing tools. It has strong support for scalable vector graphics (SVG), an open standard for graphics.

If, like me, you are only an occasional user, why should you be interested in these tools?

If you work in IT, it's always useful to know about good free and open source software. I am not qualified to recommend whether these tools meet the needs of professional artists and designers, but they are certainly worth considering because they are well established, fully featured, and free.

For more occasional users, these tools could be ideal. Where I used to work, many people who wrote content for the intranet were given a copy of Paint Shop Pro, so that they could prepare web-friendly images. For these occasional, non-expert users, Gimp could provide a much more cost-effective option, and avoid the bureaucracy of software license purchasing.

Even non-artists need to use graphics. For many tasks, the common office tools and Windows "free" tools fall short of the mark. I used to mess around drawing diagrams in Microsoft Powerpoint, export them as bitmaps, then trim the file in Windows Paint, just to get simple diagrams that I could reuse.

Some of the more advanced features of these tools are really effective. I have been using Inkscape to convert photos or pictures into drawings, or "raster to vector conversion". This is a really useful way of getting good quality graphics that will enlarge or print well from lower quality images or scans, for example to reuse paper-based diagrams. The only difficult thing about it was finding it, cunningly hidden as Trace Bitmap on the Path menu.

These products do not do away with the need for professional artists and designers. But because they are freely available and packed with features, they can turn incompetent amateurs like me into competent amateurs, which is a great step forward. And they are great fun too, so go and have a play.

© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.

Inkscape and The Gimp

Inkscape and The Gimp are full-featured open source graphics programs. Even if you are not a professional artist or designer, they have plenty of features that you will find useful.

I am one of the world's "graphically challenged" people. I got 12% in the one and only art exam I ever took. But even I need to use graphics occasionally. I'm a great fan of free and open source software, and so I thought I would share my experience of two of the leading open source graphics packages.

The GNU Image Manipulation Program, Gimp, is a picture and photo editor. It is a long-established product, and has been around for over ten years. It provides the "simple" features that novices like me use - crop, resize and rotate. But it also provides literally hundreds of features for more advanced users. (I counted almost 500 menu options!)

Gimp is an alternative to paid-for photo editing software, such as Adobe Photoshop and Corel Paint Shop Pro.

Inkscape is a drawing tool, for diagrams, pictures and illustrations. It is an alternative to software such as Adobe Illustrator and Corel Draw. Inkscape has been around for three or four years, though it is based on earlier open source drawing tools. It has strong support for scalable vector graphics (SVG), an open standard for graphics.

If, like me, you are only an occasional user, why should you be interested in these tools?

If you work in IT, it's always useful to know about good free and open source software. I am not qualified to recommend whether these tools meet the needs of professional artists and designers, but they are certainly worth considering because they are well established, fully featured, and free.

For more occasional users, these tools could be ideal. Where I used to work, many people who wrote content for the intranet were given a copy of Paint Shop Pro, so that they could prepare web-friendly images. For these occasional, non-expert users, Gimp could provide a much more cost-effective option, and avoid the bureaucracy of software license purchasing.

Even non-artists need to use graphics. For many tasks, the common office tools and Windows "free" tools fall short of the mark. I used to mess around drawing diagrams in Microsoft Powerpoint, export them as bitmaps, then trim the file in Windows Paint, just to get simple diagrams that I could reuse.

Some of the more advanced features of these tools are really effective. I have been using Inkscape to convert photos or pictures into drawings, or "raster to vector conversion". This is a really useful way of getting good quality graphics that will enlarge or print well from lower quality images or scans, for example to reuse paper-based diagrams. The only difficult thing about it was finding it, cunningly hidden as Trace Bitmap on the Path menu.

These products do not do away with the need for professional artists and designers. But because they are freely available and packed with features, they can turn incompetent amateurs like me into competent amateurs, which is a great step forward. And they are great fun too, so go and have a play.

© Copyright 2007 Minimal IT Ltd. See the Minimal IT website for the original newsletter and copyright information.