After doing one thing for over eight years, one would usually expect to have a certain level of competence in that activity. One would even expect to say: "I know know how to do X."

However, when it comes to developing sustainable relationships with small organizations involving technology and the Internet, I realize that I just don't know how to do it.

And - I don't think I'm alone. In fact, I've worked and continue to work closely with dozens of very smart people, and we just can't seem to figure it out.

Here's the scenario:

A small group (less than 10 paid staff, often no paid staff) has a web site or online database. Perhaps the relationship starts with me building that web site or database. In either event, they periodically need changes made. No database or web site is ever finished. As long as the organization is growing and changing, so is there database and web site.

The problem is that these changes come in dribbles. Six months go by with no changes. Then, a 10 minute change is need. Or a thirty minute change is needed. Often, these changes come with a huge urgency. Something is not working that is needed immediately.

Sometimes the organization can pay for the changes and expect to, sometimes the organization can't pay for the changes and expect them for free. Sometimes the changes reveal a bug in the first implementation. Sometimes organizations understand that bug fixes are a normal part of any technology deployment, other times organizations think the bugs are like a product defect and fixing them for free is the responsibility of the developer.

The problem is that the relationship becomes one based on exchange: the organization needs X changed. The developer will deliver X at a price of $Y.

There are a number of bigger political problems with the exchange model, which we could discuss for hours, and I think that's a good discussion.

For now, however, I want to only address the impracticality of that model. Developers, like all humans on this planet, need a steady income in order to live. Even when the organizations are available and willing to pay for all changes, this model is a really hard one to live on. The pay is too unpredictable and too little. The only way to survive on this model is to over commit and over promise.

There are some solutions to this problem, but they all have draw backs:

• Charge more money for hourly work. This only solves the "too little" problem - it doesn't solve the random problem. And, most small organizations can't afford to pay more
• Only work with large organizations. Yes, this works. Just not for small organizations
• Collectivize the work. May First Technology Collective did this for 6 years and had a lot of success. However, we eventually closed because we could not afford to support the small organizations. We either needed to be subsidized (for a while we had bartered space and relied on a lot of foundation contracts) or we had to tip the scale in favor of much larger organizations. The difference between an individual making $60/hour and an organization paying staff salaries and health insurance making $60/hr is enormous.
• Scheduled support. This might be the closest to a working model. Pick a time interval - 4 hours once a month, 2 hours ever two months. Schedule the days that the time will be worked in advance. One week before the day start communicating about what changes will be made. On the day in question, do the work. This has serious drawbacks for the organization in question: often changes need to be made right away and this model doesn't account for it. On the other hand, it does allow the developer to schedule themselves in a way that can guarantee their time.

What other models are there?