Feudal Lords and anarchic allies – the new models for software collaboration

Cultural chasm

Outside of smart contracts in the financial sector, which autocomplete transactions according to precisely defined data points, there seems to still be a cultural chasm between the two groups.

That chasm is most obvious when considering how often developers are reluctant to put time into their own working contracts, both with customers and with each other in collaborations. It’s not that developers don’t do contracts, but there is a tendency to think the contract can never really reflect the reality of development work.

Aside from a flash of interest in the clause that deals with ownership of foreground intellectual property, focus is commonly just on the technical specification. Even then, there’s often a sense that the specification should only ever be high level, that it will probably change over time as the client rethinks its requirements and, really, everyone should just get cracking.

This instinct was arguably a driver behind the rise of agile methodology, but it’s also had two distinct impacts on the contract models which are now prevalent in the tech sector.

Terms and conditions

When delivering services to large customers, developers will usually be asked to sign a framework agreement. It’s the basic set of contract terms and conditions which apply each time a specific project is undertaken, usually with a separate Scope of Work or Work Order signed at that time with the technical specification and fee rates for the project.

That’s all very sensible, but what’s interesting is how incredibly one-sided and pro-customer these framework agreements have become.

In many cases, the agreement will back up every single developer obligation with wide-ranging indemnities plus obligations to make reimbursements of monies received. That comes in addition to the usual warranties which can themselves give rise to liability for damages.

Contrary to appearances, however, the purpose of the agreement is not to enable the customer to hammer the developer. Rather, the purpose is to take the relationship outside of contract law and give the customer the power to reward the developer without being obliged to do so. Or, to put it another way, it’s designed to ensure the developer will do everything they can to work with the customer and not point to a contract clause which says they have no obligation to do so.

The relationship effectively becomes one of feudal lord and vassal. It may seem like a backward step, but it actually plays off the confidence many developers have that they will be able to fix problems as they go along – as well as the resignation developers feel that most of the problems will be caused by the customer.

As many developers have found in the real world, regardless of contract rights, they’re going to have to bend over backwards to keep the customer happy and still argue hard about how much they should be paid at the end of the project.

Opposite approach

The very opposite approach is popular among developers when they work together. There’s rarely a framework agreement or much in the way of structure. There is a preference for a mix of long-term and ad-hoc arrangements, underpinned by a common instinct for fairness and equitable treatment and a belief (rarely shared by lawyers) that everyone will easily agree on how to value and own any commercially viable output.

So, with confidence and a desire to get cracking, developers might at best agree a general statement of principles, but will avoid being tied down with what they perceive as misleading “precision”.

This lack of contractual detail has the same objective as the feudal framework agreement: to sidestep the need for formal legal proceedings to regulate the relationship. The difference is, rather than giving the final say to one party, the onus is on all parties to agree to the resolution and it is only the parties’ determination to take that approach that ever allows it to succeed.

Is either approach better in any way? The truth is, if the output of the relationship is broadly useful, the people involved generally resolve any disagreement between themselves and everyone moves on to the next project. In that regard, the developers are right.

But there are times when something goes catastrophically wrong, or where a key decision-maker changes and one party changes tack to the dismay of everyone else. It’s at those moments the lawyers tut and try not to say, “I told you so”.