[greaterweb]

"If you take your car to the shop and can't pay for the work to be done, they put a mechanic's lien on it, and impound the car until the work is paid for. This is no different from that method, which is totally legal."

There is a big difference, actually. There is pretty standard protocol and work agreements for automotive repair. This developer may have exposed himself to a level of risk based on his own contracts and work arrangement. Why was the site up in the first place if he was not paid in full?

"Similarly, I've met software developers who set timebombs in custom software they write for companies, with an easy to install patch that gets released when that company pays it's bill."

Wow, this is just scary. The work relationship is doomed if the developer doesn't trust the customer or vice versa. If you are in the business of making money through software development, be skilled not only in developing but in assembling contracts and project plans that protect your interests.

[mgkimsal]

"There is pretty standard protocol and work agreements for automotive repair. "

We don't know the specifics of the agreement in question, but there's a general overarching 'protocol' in the services economy - I do work for you and you pay me. If you don't pay me, and your 'protocol' is to ignore my invoices... you reap what you sow.

[duaneb]

> This developer may have exposed himself to a level of risk based on his own contracts and work arrangement. Why was the site up in the first place if he was not paid in full?

I mean, I'm a small fish compared to this guy, but I always have the site up and running before hand. Most of the time, I just outright buy the domain and transfer domain rights. This is exactly the kind of thing I do when the contract is violated- that is, when I deliver on my end, and there is a functional site, but they didn't pay.

What I'm saying is, I think you're assuming too much about the nature of how this guy does business. Money isn't about trust, it's about contracts; trust is just what gets the contract signed.

[greaterweb]

I was a small fish as well for many years, 5 as a freelancer and 5 as a small business owner. We all have to take those risks initially when getting started, "I can build you a site that looks like this for this much money!" But we concede those risks when we do so.

In all of my years I have only taken 2 sites down for non-payment. That was the extent of it though, no payment, no site. I personally would never feel comfortable using a clients domain as my own platform to state my side of the story, it's just not appropriate in my opinion.

I want to support fellow designer and developers but in this case I just can't blindly do so without hearing both sides on this or a bit more detail from the developer. The developer has posted little more than invoices were unpaid and he's shutting down the studio like P-Diddy. For all we know through his own initiative he exceeded the agreed scope of work and wants to be paid for it.

Maybe more information can be surfaced and we can rally behind this guy. Until then I've got to stay neutral and look at things objectively.

[duaneb]

> I personally would never feel comfortable using a clients domain as my own platform to state my side of the story, it's just not appropriate in my opinion.

I would agree about this-I just throw up a site that looks OK with the company's contact information on it, or just take it down entirely.

[dhimes]

This developer did expose himself to a real risk, and one he probably didn't even think of: that little site, which is essentially a text message, is driving my Chrome instance crazy. WTF did he code into it? Would I hire him?

[ultramundane8]

So let's say that the customer always pays on time and the developer did build this sort of time bomb. (And let's assume no technical knowledge on the part of the customer. Therefore, the time bomb is never discovered.)

Are you saying that the relationship was negatively affected?

I would claim that the developer could mistrust the customer without elsewhere mistreating them.

[jessaustin]

Intentionally increasing the attack surface of the product you deliver is not ethical. It's unlikely any developer in the situation you describe has tested the time bomb functionality well enough to exclude the possibility that an attacker could exploit it, either before or after the payment date or the cancellation patch. An aspect of the Hippocratic Oath applies here.

The case described in TFA seems better, since the developer retained possession of legitimate control mechanisms, and used those in technically legitimate ways. (That is, updating the content and functionality served at a URL is a legitimate activity that occurs regularly.) In effect he's more of an unpaid service provider than an unpaid IT contractor in this case. No one would expect their phone to keep working without paying the phone bill, and until he turns over control of the site he should be expected to use that control. It's not like he's using a backdoor here.

[npsimons]

There are way, way, way too many ways for this to go wrong. What if you are indisposed (in the hospital, dead, etc) when it comes time to apply the patch? What if an attacker finds the security hole and exploits it before you apply the patch? And don't tell me this isn't a security hole (eg, a backdoor), because it could easily be or become one. Knowingly delivering compromised software is flat out unethical and borders on vigilantism and/or fraud. I don't condone one party failing to hold up their end of the deal when the other party has, and I don't think that "defacing" a website that someone doesn't legally own (they haven't paid for it) is wrong, but putting time bombs in software should never be done.

[koenigdavidmj]

This seems much the same as a DRM mechanism on a single-player game that requires a live network connection to phone home to the server. In either case, you have software refusing to function unless its creator gives approval. The only difference is that this is known to the player of the game.

[ultramundane8]

My post was a little more geared towards disputing that the work relationship is doomed if the customer and developer can't trust each other.

I had no intention of endorsing a time bomb approach, but just continued on that theme theoretically.

I thought I had expressed that through the sequence of my statements (assuming a possible case then showing that it is at odds with the trust assertion), but will try to be clearer in the future.

I definitely think there are some good replies to the actual practice of installing a time bomb, especially from pragmatism.

[greaterweb]

My point is such that a "time bomb" of sorts would not be necessitated if the developer makes sufficient efforts to protect him/herself with good business practices.

That same client who pays on time and upholds his end of the agreement is left at risk through no fault of his own. Just doesn't seem fair in my opinion.

Will a dispute happen even with well authored contracts and business plans? Absolutely, but properly scoping the work, delivering to a schedule and keeping open communication with the client will greatly minimize that risk.

[codegeek]

"let's assume no technical knowledge on the part of the customer. Therefore, the time bomb is never discovered"

That is a big assumption to make. Just because the customer is not technical does not necessarily mean that time bomb could not be discovered at some point in future. Probability might be low but you can never be 100% sure.

[Dylan16807]

>Wow, this is just scary.

It depends on how it's implemented. There's nothing wrong with the shareware model, surely?