However, the truth is that open source is also about loving or caring about people. Today, I want to feature a Firefox extension that I have been using for a while now. I even recommend it to others: FireFTP. This is a great little tool that works from any Firefox browser, and gives you the ability to upload and download files from other servers using FTP.

The tool is free, but you are invited to donate funds to keep the project going. Half of all proceeds go towards helping various orphanages in Sarajevo, Bosnia & Herzegovina and in Vukovar, Croatia. Isn’t that something?

The writer of the software also encourages users of his software to volunteer in their own community. He is definitely using open source to make the world a better place for people.

To start using the FireFTP Firefox extension today, goto the Firefox addon site.

But, where is the Internet going? What kind of a world are we creating as we write code?

This article, by Tim O’Reilly, is a must read for anyone who wants to understand the latest trends.

This is the playing field, as Tim sees it. This is the ground companies are fighting to occupy. This is what their strategies address, and what their tactics are about.

Happy reading.

Today, I am launching a new look, based on a dependable template from Elegant Themes. What it lacks in bells and whistles, it makes up for by being clean, efficient, easy to manage and html compliance.

Last week, I turned fifty. Wow! I wrote my first line of code in 1977, and I have owned a personal computer since 1982. I still love programming, and I am still excited about new things. So, I am going to blog some more. If I play it right, my career is going to change course this year.

I face the following challenges:

1. I am aging – I rarely work with programmers my own age.
2. Consulting with government clients is not as challenging as I would like.
3. My work has stopped being fun.
4. I see no chance to achieve anything worthwhile doing what I am doing.

It is no secret that I identify with Don Quixote – I even named my bike Rocinante, after his horse. So, it’s time to find an adventure. Let us go, Sancho. My enemies are not as imaginary as they seem.

First, I am going to reorganize and purge some of content, and create some new categories.

Everything will be fine, they seem to believe, as long as I have a record of the tasks that have to be performed and an understanding of how these tasks depend on each other. Nothing could be further from the truth. The GANT chart is just the beginning.

A GANT chart is a comforting tool because everybody understands it. A project manager can quickly show where the project is stalling, and show the impact of the stall on the deadlines.  A work breakdown is NOT a plan.

The following analogy may make this clear. If I gave you a grocery list,  and I asked you to buy me some food, you might have trouble completing the task. You may not even know where you can buy the food I need.

When you return with canned peas, I might have to explain that I really needed frozen peas. I might wave my recipe in your face and fault you for getting the wrong type of peas. As a frustrated project manager,  I might never realize that I never shared my recipe with you before sending you out.

In the simple example I give above, the list tells a project manager what he has to plan, but it is not a plan. Many project managers stop when they have their list. They have something to say for themselves if the people they report to ask them how things are going. That is all that matters. This approach is insuffient.

Two and half years ago, I worked on a project with a tight deadline. My manager took care of ordering food for members of the team who worked late. She organized rides for people who depended on public transportation. She never started by asking us how things were going, but she asked us what we needed.

She understood that overtime was necessary, and she agressively removed any barriers that would have made it hard or unpleasant for us to work late. She motivated us to work hard by staying behind with us, and she even brought us coffee. Thanks Lan!

She provided input when asked, but otherwise she stayed out of the way and waited for her scheduled updates. She asked for estimates, and held us to them. She always said thank you. She gave us the credit even though she deserved a fair share of it herself.

If a requirement was unclear, she led the charge to get us the answers we needed. She never left us hanging. Microsoft Project was used to communicate and track our progress, but she planned based on the chart. The chart was not the plan.

When we were going to deploy a new database, she asked the following questions:

1. Do you have access to the server?
2. Do you have the passwords?
3. Is there an approval or a review phase before the database can be deployed?
4. Who are you dealing with in the database group?
5. What are the risks associated with this deployment?
6. How can we be proactive to avoid these risks?

Tasks on a todo list tell what you have to plan, but the list itself is not a plan. Planning and preparing start with the task list.  It should be clear that is does not end withthe work plan. Here is another project management resource you may find useful.

To protect the guilty, I will mention no names, but I will state the following.

1. Do not just assign deadlines. Ask developers to plan and map out the work and provide estimates.
2. A todo list is NOT a proper plan.
3. Manage people not lists.
4. Build a team, and the software will build itself.
5. Screenshots are not requirements.
6. Developers need to understand the requirements and the business to do a good job.
7. Quality is not an accident, and it is not the work on any one person.
8. The fish rots from the head.

I want to speak to the first point today.

A team will rarely meet a deadline that was set by a project manager who has not asked the team for an estimate. For one thing, the date is meaningless because, at best, it represents some managers best guess. As a group, developers do not respect uninformed opinion, and that is how they regard dates that are picked out of the air.

It is difficult to motivate developers to meet these dates if you disregard their expertise. When developers are treated as replaceable cogs, you can see the lack of faith and commitment on the faces of each developer at every status meeting. Nobody speaks up.

Members of the team share neither speak about enthusiasm nor doubt. They come in, do their work, and go home. Apathy rules the day. As I have heard one person say, “Government cheques don’t bounce. That’s all that matters.”

Basically, developers need to buy-in to the deadline. When I provide an estimate, it is a matter of pride to accomplish the work in the time I have forecast. I have not excuse and I know it.

Many of the managers I have dealt with in my recent government work have not wanted to even ask the question. They believe that developers, especially consultants, will pad the estimates. Therefore, they provide a due date, and assume an adversarial stance from the word go. The work often takes longer because they micromanage or change the project plan to make up for lost time.

In my next few entries, I want to reflect on project management on some of my recent projects. For useful information, and real insight into project management, visit the Project Management Hut.

While you wait, here is some interesting and extremely useful information about Nginx, a beautiful little web server I am falling in love with. I use it to run my Django based site, using FastCGI. If you are getting ready to setup Nginx, this is a great source of information. Nginx (prounced engine X) is fast – give it a try, if you are curious.

I will probably say more about Nginx in months to come.

If you like what Java has to offer in terms of class libraries, but you like the Python language and its idioms, then Jython is the best of both worlds.

To prepare for my next installments on Jython, Django and DB4O, read about introspection in Python.

What Is Vendor Lock-in?

One of the worst things that could happen to you as a supplier of goods and services is for the customer to leave you for one of your competitors. You can prevent this by providing a service nobody else provides, by offering unrivaled quality or service, or by charging a price that is hard for others to match. You can also combine these methods of keeping a customer, and you can raise customer awareness by marketing and advertising your offering.

Another tactic is to find ways to prevent or discourage your client from switching even if he or she wants to. In other words, you can try to lock the client in. You can do this with service contracts that contain cancellation fees. Sometimes, a client locks him or herself by committing to a platform or product by writing code.

If I build my business on an in-house software solution that uses an Oracle database, I may do the work such that it is difficult and costly to switch to a different database product. If Oracle changes their terms of service, or raises the cost in some way, it may be cheaper for me to pay this cost or accept the service changes than it would be to change the application so that it works with a different database product. In this case, I have locked myself in.

If my needs are such that I can depend on the MySQL database, I am free to run my database on Linux, Windows, or some other operating system. My choice of MySQL does not lock me into using the Windows OS. However, if I want to use SQL Server, I will also need to buy a Windows license. Another way to lock you in is to provide products that depend on each other and to force clients to use one if they want to use the other.

Another way to lock you in has been to provide a software product that uses proprietary file formats or closed APIs. This makes it hard to switch to a new product without converting you old files, or rewriting your code. It is in your best interests to support open file formats, and open APIs.

For more information about vendor lock-in see:

• The Linux Information Project.
• Norwegian minister: closed formats, vendor lockin are unacceptable
• The Advantage of Adopting Open Source Software

Oppose Vendor Lock-in

Some people may argue that some of the practices I have described here are wrong or immoral. I won’t argue that. If you are willing to allow yourself to get locked in, then I suppose I will have to admit that the practices I describe are smart – I wouldn’t say the same thing about you.

As a consumer, you should want to preserve your ability to switch to a competing product. If something better than comes along, you want to be able to consider lowering your cost or improving the quality or performance of the software you use. In software, innovation is encouraged by openness and by collaboration more than it is by monopoly practices.

Defenestration is about putting you in the drivers seat. It is about encouraging innovation, choice and competition.

Reducing my reliance on closed and proprietary source products is not something I did in one swoop. I did it in stages. But, I did embrace the reasons for moving to open source very quickly. I will list some here, and then address a few of them. Some may appeal to you, and other will not. The range of opinion is wide – some people will go as far a saying close source is evil. I am not trying to convince you, but I hope I do justice to the reasons others give. I have my own opinions, which I will share in due course.

• Open source is often free.
• Managing licenses is a time consuming and difficult exercise.
• Open source avoids vendor lock-in.
• Open source is more innovative.
• Open Source is more reliable, or more secure.
• Closed source is evil.

Open Source is often free. This is true, and it is a factor for me. However, all software environments require maintenance. Users need to be trained. Files and information must be able to flow from closed sources systems to open source systems and back. The cost of the the software is more than the cost of acquisition. Free is not the be all and end all, but it can be a important.

Managing licenses is a time consuming and difficult exercise. This is true, and I find that it is an important consideration. Remember, it is often illegal to install multiple copies of the same package on different computers. Even if you have a volume license, you have to keep track of how many licenses are being used on how many computers.

However, I am using Open Office as opposed to Microsoft Office. I can hire as many employees as I want and install the software without the time and expense and managing licenses. Using Open Office, I can create files that can be used and edited by people who are using Microsoft Office. Open Office is considered a very good replacement for Microsoft Office, and any other proprietary office suite.

Open Source Avoids Vendor Lock-in. Nobody controls my use of the Apache Web Server. If I want to hire somebody to alter or extend its functionality, I can do that. If I want to include Apache in a product that I develop, market and sell, I can do that without paying royalties to the owner. My use of open source software is limited by a variety of software licenses.

Anybody can hang out a shingle and offer services that include installing and supporting the Apache web server, and other open source products. In the case of proprietary products, you can never get away from the fact that the product and the company that owns it are one.

The issue of vendor locki-n deserves an entry all to itself. I will pick up there in my next installment. Later, I will address some of the other reasons to use open source.

Over the next little while, I am going to write about how you can reduce your dependence on closed source, proprietary software. I call this series Defenestration 101. I learned the word “defenestration” in high school. Defenestration is the act of throwing someone out a window, but it can also describe a rapid expulsion of a person from a group or organization.

I encountered the word again a few years ago when it was used to describe the process of getting rid of Windows servers and moving to Linux or Unix base servers. Apart from anything else, I was amused by the recursive humor of throwing Windows® out of a window.

All humor aside, it is possible to run a business without using Microsoft’s closed source, proprietary software. In series of blog entries, I am hoping to explain how I handled this change in my home and business, and explain why one would want to.

First, let me start by saying nice things about Microsoft. Twenty years ago, I built my career on Microsoft products. Back then, Microsoft published great books on the products I used and they maintained a BBS where I could download code samples and white papers. I bought Quick Basic and Quick C, and started to write programs at work, helping my employer use computers in new ways.

I was helped decision makers select software packages – basically, I cut my teeth on Microsoft products. However, by the mid to late ninties, the price of Microsoft products started to rise. One client put a project on hold because he had to upgrade to NT. In time, I could see that Microsoft was eating up a large part of the budgets that used to be available to pay me.

I also saw opportunities. There were more developers, more projects, more books, and more magazines. Selling clients on using computers was not longer a challenge – every business had computers. I had a chance to travel, and to dig into some challenging projects. For a while, I ran a company called Workflow Automation Group in Vancouver, and I can not say anything bad about that time.

Even today, there are many good reason to use Microsoft solutions. However, the world has changed, and there are alternatives. Count me as one of the many who have chosen to embrace these alternatives. This week I will explain why.

I will try to be pragmatic rather than idiological. In all probability, your business is not software. The problems you are trying to solve are not technilogical. For you, technology is a means not an end. I get that.