Consulting agreements tend to solve the wrong problem
Software consulting contracts routinely dedicate hundreds of words to one concern: making sure every possible artifact of the engagement belongs to the client. A typical clause defines “Work Product” as any invention, discovery, design, process, software program, or know-how that relates to the client’s business, results from the contractor’s services, or arises from use of the client’s premises or property. Several sub-clauses deep, the message is unmistakable: any original thought during the contract period is the client’s property, whether or not it is embodied in code.
That framing creates an uncomfortable incentive. A consultant who might otherwise dive into a hard problem must instead weigh whether a novel idea is worth having, since anything invented under the contract may never be used again in any other context. The contract effectively taxes thinking.
Open-source work raises the stakes
When the engagement touches an open-source project, the risk is not merely personal. Code and design work produced under a conventional work-product clause belong to the client. The consultant must trust the client to release that work under the project’s license. If the client does not, the code cannot be contributed without legal exposure. Every hour spent solving the client’s problem becomes potentially toxic, withheld from the project, its users, and the consultant’s future employers.
This is also bad for the client. The more these agreements penalize creative engagement, the more incentive the consultant has to stay disengaged: ignore the client’s ideas, avoid thinking about solutions, and log hours without ever producing anything reusable.
A plainer agreement, centered on communication
One consultant’s response is to replace the standard boilerplate with an informal, human-readable contract. The goal is not legal precision but mutual comprehension: what each party will do, when it happens, and what happens to the results. The proposed terms below illustrate the approach.
Schedule and scope
The agreement names the specific engineer and the client, defines typical availability (weekdays from 10:00 to 18:00 Pacific) and leaves room for negotiation. The client may request features, research, documentation, or other improvements. Work may happen outside business hours, but only with approval from the client’s contact. Significant tasks come with time estimates, and the consultant maintains a daily log of hours and accomplishments.
The contract covers up to 80 hours of work. Either side may terminate early for any reason, with an expectation that the consultant will reach a reasonable stopping point and continue supporting the client through the project’s public channels.
Open and closed ownership
Work suitable for the whole community is integrated into the project’s codebase, published, and licensed under EPL. The client may be acknowledged publicly. Features that conflict with the project’s design goals can be refused, but the consultant commits to proposing an alternative, such as a separate library or standalone program, and helping build it.
Separately, the client can request closed-source deliverables: documentation, software, or other works that are explicitly not part of the open-source project. Those works are delivered to the client, which takes responsibility for maintenance. The consultant assigns full ownership with reproduction, distribution, sublicensing, and transfer rights. The open-source route is framed as the easier maintenance path, since community fixes and improvements flow back to the client as well.
Ideas stay with the author
All of the project’s ideas are public, so discussing them creates no confidentiality risk. The consultant may sign an NDA and will not disclose proprietary client information. But proprietary information can still inform improvements to the open-source project, as long as the code does not reveal it. If the client needs to push two million events and performance improves to handle that, the improvement is released without the client’s data or scale being disclosed.
The distinguishing term is that inventions and ideas conceived during the contract do not become the client’s property. A stream-reorganization insight that improves performance after the engagement ends remains usable. The contract gives the client access to the resulting code, but not a veto over the consultant’s future work.
Warranty and payment
There is expressly no warranty of correctness, safety, or performance. The consultant commits to testing during the engagement so defects surface while fixes are still under contract. Invoicing occurs every 30 days or at termination, with a stated hourly rate and a 30-day payment window after invoice receipt.
Contracts as guidance, not just rights
Conventional agreements tend to be long on defined terms and short on operational guidance. They cover dispute resolution but often omit basic relationship details such as expected working hours or what happens when a feature request does not fit the product’s direction. The informal alternative is shorter, makes those expectations explicit, and uses examples to justify terms. The hypothesis is that parties who understand the intent behind an agreement are less likely to litigate its technicalities.
