There have been several times during the application development phase where my clients have decided to back out on payments or abandon projects all together. During this time, they usually have a working copy of the application that I have worked on for the past few months. When this occurs, what is the right thing to do?

Is it acceptable to lock the user out of their program simply because they missed a payment or chose not to continue with the mutual agreement of the software? If it is not acceptable to lock out the user, is it acceptable to disable certain features since they did not follow through with their end of the agreement?

I think these problems fall under the category of software politics. These are the same politics that involve problems such as “Should software be free?” “Should all code be free?” “Is the commercialization of software beneficial to the industry?”. Usually, I avoid software politics except when it comes to crediting the software authors, which I do not have a hard time supporting.

I believe that the problem at hand, although it is indeed a software politics problem, it is also a problem of a voided agreement. The purchaser of the software agreed to follow through with payments or whatever else may be at stake. Thus, since they did not follow through, the software developer (being the owner of the software) has the right to do whatever they want to the software to deny or allow access.

Thus, I believe that it is perfectly acceptable to lock the client out of the software entirely. In fact, that is exactly the process that I have followed. Usually I implement this by reading an online text file that contains a boolean allowing or denying any user access. This text file is usually read when the program starts up.

Of course, this is a little inconvenient, as it requires the user to have internet access in order to actually access the meat of the program. This is something that I don’t really endorse, especially when it  comes to the gaming industry.

But I digress. In order to avoid this problem, I think that it is only right to still allow the user into the program if they don’t have internet access. Thus, the lockout check may be avoided by simply flipping the switch on the internet connection.

But there is a caveat to all of this: updates. When the user does not have an internet connection when launching the program, the program cannot check for updates. Thus, this small workaround leaves the user running an older version of their software. Although this may not be a problem, the user will have to deal with bugs that exist due to older versions of the code and a lack of features that come along with the newer versions.

Since I feel that locking the user out from their own software is justified, I think that I will publish a .NET library to do just this pretty soon. Since a separate .NET library would require an extra GET request from the internet, I think that it would be best to integrate this lockout library and the update library (update.net currently) in order to make a single, streamlined call to get information from the internet.

So, be on the lookout for that!