Thursday, November 26, 2009

Freeware and Motivation

You have probably seen a good open source project getting abandoned (CamStudio, NDoc and many more) by developers due to poor motivation to continue. I have been thinking whether there is a way to sustain the motivation, and have explored the examples of both open source and proprietary software projects on the subject.

The findings of my research are easy to understand, but difficult to accept:
  • Developers need external motivation to keep the project running after the "magic" of the initial idea is gone.
  • Users only contribute when they have a clear incentive to do so.
Keeping this in mind, I have decided to create a brief outline of the main factors that can help any open source project to stay alive.

Developers' Motivation to Contribute
At the start of the project, I as a developer was motivated by the mere idea that Flat File Checker can optimise the way organisations exchange data, improve the quality of data and spare the data people from mundane and tedious manual work. As the project moved ahead, it brought about loads of little tasks that I was happy to solve as they came. I have extended my knowledge in various areas of application design and data quality, and this alone was quite exciting.

Today, as the development phase has essentially passed, my motivation has become much more prosaic. Now I have to face a different set of goals such as marketing and promotion, and recruiting new users is not something I like to do, so obviously just running the project for fun does not make sense to me anymore. What would be the alternative source of motivation? In theory, a developer expects two main benefits from his work: recognition (of his efforts, intelligence etc.) and revenues. In my case, these two would be: feedback from users (so I know that I don't waste my time) and earnings sufficient to cover project expenses including my precious time. 

Users' Motivation to Contribute
The user's motivation to use the application is quite straightforward: it depends on the application's ability to efficiently solve the given task. However, when it comes to motivation to contribute, there is none even when the user is happy with the application.

Get Your User Involved
It seems that an open source project is unlikely to progress when the user community does not support it. Without users contributing to the project, developers feel frustrated about their apparently meaningless work. As a result, either the project is dropped, or developers start charging.

Since neither of these options appeals to me, I kept trying to figure out how to motivate users to provide feedback or to make donations to keep the project going. The next section of the post lists the conclusions I came up with; I also include a diagram that helps illustrate my thoughts.


H1: User is more likely to spent more money if he can save time by doing it.
Vendors request users to register every year and this is a good artificial way to make user to spend time.

H2: User is more likely to spent more money if he will get a better product for it.
This is a microeconomics rule for most of the products.

H3: User is more likely to spend time on the project if he will get a better product for it.
H3 is the same as H2 if we can find the price of user's time.

H4: User is more likely to spend time on the project if his effort is recognised.
This is a behaviour dogma that is used in many social web projects (digg, facebook, etc.).

H5(A): Developer's perceived recognition depends on how much time users spend on the project.
That is my personal opinion which can be tested.

H5(B): Developer's motivation depends on his perceived recognition.
H5 is similar to H4 but applied to developer.

H6: Developer is more likely to work on the project if he gets money for it.
Conclusion derived from motivation theories but can be tested.

A priory statement that defines user contribution to the project:
A1: User needs to spend time or donate to make a contribution. Therefore, user's contribution consists of time and money spent on the project. 

Here is the diagram that represents set of hypothesises that were discussed above:

So what I want from a user boils down to contribution that will motivate me to continue working on the project. And to motivate users to spend their time or money (see A1) on the project I need to give them better version of the product and recognition for their contribution. Simple market exchange is healthy for both developers and users. So if user does not get involved then he does not get the best available version and his name will not be on an "I saved the world today" list.

Definition of Variables
User contribution - is measured in points that will be credited for any activity beneficial to the project, such as: donation, submission of a bug, feature request, link from blog, etc.
I think that the points based system is the most appropriate, though a bit complicated. The problem is to define how exactly points should be credited. As an old book wrongly says - "People only do for what they are paid for" (If no book says such things, at least some book says about money and motivation).

Let's see a theoretical example of how contribution can be calculated in points:
  • $1 donation - 1 point.
  • Submitted bug - 5-20 points (on
  • Feature request - 10 points (on
  • Links from relevant web page or blog - 10-100 points (to project's website page; rated by Website Grader)
  • Business case- 50-100 points (submitted on the Forum)
    • Name of the organisation
    • Description of how software is used and what problems it solves
  • Allow to use organisation name and logo on "Users" page - 50-150 points
  • Join the project - 10-200 points
    • Programmer;
    • Technical writer;
    • Translator.
Note: All this points are subject to conditions. For example if feature request is absolutely irrelevant, then points for it will not be granted. Also where credited points are given as range, it is developers right to decide the final number of points that will be credited to the user for specific action. I will need to spend some time to finalise my estimates of each action before this "point based system" will appear on the main page of the website.

Donation - Money spent in $

Product's Quality - Release delay in months.
This is an open project and I don't want to produce cripple-ware versions with limited functions and make users to pay for "pro" versions. So the only option I see is delays in release times. Users who got involved or donated to the project will get new releases first without any delays, while other users will get releases with a delay. Though this model is not exactly what open source is about, I think it is fair.

So application release delay depends on how much points you have:
Fairware* "price" structure
Release delay
User Contribution
* Modified version of open source software, in which user's contribution towards the project gives him access to the most recent versions.

So if user did not contribute to the project his version of software will be maximum 6 months out of date. I think this is a fair play and would like to hear what other people think?

Developer's Motivation - Can be measured through developer's performance, which can be in its turn measured by the number of lines of code written within a period. Though this is a primitive measure (often I would rather "bonus" myself for reducing the number of code lines) it is easy to understand and to measure.

this was just a though and I am sure that I am not going to implement all that. Managing such system within one open source project will impossible and pointless as all this is based on hypothesis.

However, I have decided to make new releases available only to the smaller group of users who are ready to register to download the application. Moreover, license for these latest releases is slightly different from basic GNU Licence and requires commercial users of application to contribute.

This article was an attempt to define fair-ware instead of donation-ware, which is a concept that does not work to well in the real world (list of examples includes all communist countries). It would be nice if SourceForge and other software hosting providers had such functionality to support developers and award users who make contributions.

Tuesday, November 24, 2009

API Documentation

This week I was working hard to produce API documentation for application's core DLL - FlatFileLibrary.dll. It takes quite a while to feel in all the gaps in the comments but I am nearly there.

On-line API documentation is now available, which will help if you are using the code in your project.

This documentation is still not complete but it is evolving rapidly. As Flat File Checker is at its Beta stage of development, names of classes and their members can change.  Everybody is invited to review the code and the documentation. You can leave your comments or questions on this post or send me an email.

This documentation was created with Sandcastle that is why it looks so good.

Saturday, November 14, 2009

Version 0.6.7 is released

New in 0.6.7 release:

  • Data rule based on VB Expression:

  • Validation of fixed position files. Field position in the line can be defined in the Field Details form:

Sunday, November 8, 2009

Version 0.6.6 is released

New in v.0.6.6 release:

  • Validation of files without headers;
  • Field index in Field details form;

  • Default folder for file set is shown in File Definition form: