I was the dev lead for a medium size company where we depended on a software platform by a solo dev. We made up 60%+ of his revenue. We insisted as part of the contract that he put his code in escrow and that we had the right to a copy of the code under certain conditions.
But no, I wouldn’t as a person
who hypothetically made buying decisions. It’s the “IBM problem” that non dominant companies face. “No one ever got fired for buying IBM”.
On the other hand, I would never become dependent on a solo developer or a small business for a critical part of my business.
I’ve been on both sides of the issue. I worked for a struggling startup that got one large customer who was 80% of our revenue. They insisted on the code being put in escrow and released to them under certain conditions.
When the company was sold for scraps, they exercised that clause and hired me as a contractor to help them transition.
On the other side, I was the dev lead at a company who was looking at using the software of a solo developer as a critical component to our business. I suggested the same clauses be a stipulation to us signing the contract. We were going to be 80% of his business.
I once was the dev lead working for a mid size non tech company. The company found the perfect product to meet their needs. It was built by an Indy developer. If we signed the contract with him, we would represent 60% of his revenue.
The director of IT and CTO were reticent to base their entire data capture system that was going to be rolled out to thousands of field workers to him.
I suggested that they only sign the contract if the developer was willing to put their entire codebase in escrow and agree that we had a non exclusive right to the code under license.
Everyone agreed and the lawyers talked and made it happen.
I led a quarterly validation of the code in escrow. He would come onsite and I would watch him download the code from the escrow company and build it from scratch and deploy it and I would do a smoke test.
From a B2B side. I’ve been on both sides of a startup.
On one side we were a small company with a large company as a customer who demanded that our code be put in escrow in the case we went out of business. The company did, but the customer hired me as a contractor because I was one of a few people in the world who knew how to develop on the proprietary platform. Even better, I was one of only three people in the world who knew how to modify the C++/MFC platform itself.
On the other side, I was the dev lead for a company and our business consisted of 60-70% of the vendors revenue. We had them put the code in escrow as part of our contract.
My company had a significant product based on an early stage startup's product -- before we signed a license with them, we negotiated a code escrow agreement with the company. And it was good that we did because about a year later they got acquired by a company that didn't want to continue selling the product we used, but we got the source code so were able to maintain the product. We picked up a couple of the developers that were working on that product too.
Interesting...at the places I've worked (as an employee), it was considered a dealbreaker if a contractor wanted to own the source code they produced. We passed up some really, really good contractors because they wanted to own the product.
But what is an "investor" in this case? Can someone buy a 1% equity and then walk away with your source code potentially worth significantly more than that? That isn't rational.
If they /buy/ the company they get access to the source code naturally but why would an investor? An investor is just staking capital for the chance that the company's venture will do well. SOME might be investing for the chance that the IP is worth a lot, and in that specific circumstance it might be rational to give them limited access to the IP (so they can verify claims).
However I'd never let an investor walk off site with the code or email them a copy of it to do with as they will. I would let them sit in a room and read through the code or even have people on their behalf do the same. I'd also do a code-review style thing where we talk through it together so they better understand the IP/project. Naturally this would all come with appropriate non-compete/NDA.
As to root access? HELL NO, that's insane. I don't even think programmers should have root on production servers let alone fucking investors. The only people who should have root are your system engineers (for maintenance) and your deployment lead (so they can pull from the master and deploy to prod' after it has hit test).
And if that unknown small company goes out of business, then what?
I've been on both sides of that equation - the vendor and the client. When I was working for the vendor, the only way that we were able to secure our biggest deal was to put our entire software stack in escrow -both the proprietary development platform and the system we built for them on top of it. *
As the client, part of the contract was that they had to put their code in escrow.
In both cases, the client was large enough to negotiate those terms. What if you aren't large enough to force those terms?
* That worked out well for me. When the company I worked for went belly up, the client that enforced those terms hired me to complete their system since they had the right to the source code and I was the only person on the planet that was available that knew how both the C based development platform and their implementation worked well enough to complete it.
Some places yes. It's a little different, at least it has been in all my contracts. The company you work for has the rights to buy the software from you, at a reasonable price. If they don't want it, you free to do whatever. They can't just take it.
I had colleagues would worked on a project in their space time, their price was reasonable wanting only compensation for the hours spend working on. The company didn't want it, but they also could not sell it, because if was so heavily tied into our systems and work flows that they couldn't reasonably sell it anywhere else.
One of those developers then started working on another project, one that was so fare away from what we did that there was no way the company would want it and turned that project into a very successful business.
In reality what happens is that people will work on something, quit, and the spend a few months on polishing and then release their project or sell it. Very few companies will want to spend time going after a former employee building some side business far removed from their core business.
Imagine you're a company looking for software as a cloud service. Suppose the best software for the purpose only does 70% of what you want. So you contact the company who runs that cloud service and pay them to develop the additional features and specific business logic you need. Then you contract with them to manage private servers with your build on them. At no point have you seen or purchased source code - not even for the 30% new features that were written on your behalf. Those are entwined with, and only work as a result of, the other 70%. You're basically using a black box that's maintained by another company, and trusting in that company's competence and goodwill. That's essentially what the situation was here. If you sold your company and touted your special build of the software as a feature, and passed the contract along to the buyer, that would be fine. But if you misrepresented the situation and said you owned 100% of the code and were selling that along with the right to distribute it, that would be fraud.
Of course, you could have gone the more expensive route and hired your own team of coders to write the whole thing from scratch, under whatever license you wanted, and then you would own the source. But if a company needs document software or meeting software in the cloud, how many pay to reinvent the wheel and roll their own?
If you are a company dependent on a startup you can often get the source code in escrow if the startup would to fold or be acquired. I have had this work out multiple times in the past.
One place I worked at did contract with a startup and whose product I was involved in integration, and that vendor later failed. We had a source code escrow clause in the contract. That's a lot like using an open source product whose upstream dies, but you're still using, and now you get to be the upstream if you really want to.
Source code escrow is an option, at least for proprietary software products.
You're absolutely right, but this is well covered ground when dealing with smaller software vendors in a B2B environment. Source code escrow (http://en.wikipedia.org/wiki/Source_code_escrow) is something we would often do when I worked for a company that sold ERP software. The basics of the idea are to give good answers to all the questions you put at the top of your post about what happens if the worst happens. A source escrow agreement makes it so that if the company you're buying the software from disappears, you at least have access to the source and will have a shot at not being completely screwed.
Thing is, though, that the source code license isn't really the thing that you're betting on. It's your relationship with the vendor. Your business can be screwed a lot by a business long before the escrow agreement kicks in, and long before they fold.
Being heavily dependent on a software company, at least in ERP type business software, is a lot like marriage. You definitely want to pick the right one, and it's all about the relationship. If the marriage goes bad, it can make your life hellish, even if you do have a pre-nup.
True. It absolutely depends on the specific contract each of them signed. If the contract were to say "Not satisfied? Full refund!" or anything like that, they technically are not under contract to NOT use the code.
They would literally have legal basis, in that case, to run a startup from the very code they refused to pay for. Albeit unethical, it would be legal.
Either way, the contract would clear this up. It's still bad press. With $2M in funding, just pay the dev and move on with a stable image of doing the right thing even if it isn't legally required to do so.
Putting the code in escrow with a third party like Iron Mountain doesn’t give you access to the code unless the company folds or the product is discontinued.
I’ve been on the other side at another company where we were forced to put our own code in escrow by a large customer. I suggested we do the same for this vendor to our director he had the lawyers do everything else.
In fact when I was on the other side, our company did go out of business (got acquired for scraps), the escrow conditions were triggered, I was laid off as soon as we got acquired and went to work for the customer as a decently paid contractor.
I definitely know cases of businesses and start ups - either offering to buy out or employ another party, asking for access to code and other secret information, requiring NDAs, and then making off.
I would personally never share more than some small snippets of code. Throw those snippets on a different repo and that’s it.
If they demand to see more of the code base, ask them specifically what they’d like. If they want the entire project, I wouldn’t proceed any further.
I'm in this exact situation right now where I worked as a developer for a small company. I did a side project, and they demanded I hand over the project so they benefit from it. I refused, and we are deep in a costly legal battle. But it is a matter of principal that I won't let those a*holes benefit from something I did at home, on my equipment, without any of their IP, and unrelated to the work I did. I can tell you I've learnt a valuable lesson and will never sign an generic software development employment contract like that again.
But no, I wouldn’t as a person who hypothetically made buying decisions. It’s the “IBM problem” that non dominant companies face. “No one ever got fired for buying IBM”.
reply