Slashdot Mirror
Ask Slashdot: How To Work On Source Code Without Having the Source Code?
occamboy writes: Perhaps the ultimate conundrum!
I've taken over a software project in an extremely specialized area that needs remediation in months, so it'll be tough to build an internal team quickly enough. The good news is that there are outside software engineering groups that have exactly the right experience and good reputations. The bad news is that my management is worried about letting source code out of the building. Seems to me that unless I convince the suits otherwise, my options are to:
1) have all contractors work on our premises — a pain for everyone, and they might not want to do it at all
2) have them remote in to virtual desktops running on our premises — much of our software is sub-millisecond-response real-time systems on headless hardware, so they'll need to at least run executables locally, and giving access to executables but not sources seems like it will have challenges. And if the desktop environment goes down, more than a dozen people are frozen waiting for a fix. Also, I'd imagine that if a remote person really wanted the sources, they could video the sources as they scrolls by.
I'll bet there are n better ways to do this, and I'm hoping that there are some smart Slashdotters who'll let me know what they are; please help!
I've taken over a software project in an extremely specialized area that needs remediation in months, so it'll be tough to build an internal team quickly enough. The good news is that there are outside software engineering groups that have exactly the right experience and good reputations. The bad news is that my management is worried about letting source code out of the building. Seems to me that unless I convince the suits otherwise, my options are to:
1) have all contractors work on our premises — a pain for everyone, and they might not want to do it at all
2) have them remote in to virtual desktops running on our premises — much of our software is sub-millisecond-response real-time systems on headless hardware, so they'll need to at least run executables locally, and giving access to executables but not sources seems like it will have challenges. And if the desktop environment goes down, more than a dozen people are frozen waiting for a fix. Also, I'd imagine that if a remote person really wanted the sources, they could video the sources as they scrolls by.
I'll bet there are n better ways to do this, and I'm hoping that there are some smart Slashdotters who'll let me know what they are; please help!
An NDA works and makes for Target to sue if the code gets out.
one option is allowing them to remote in from designated remote locations to virtual desktop implementations, safe rooms/clean rooms, where cell phones, etc. are not allowed. although there is still the concern of using screen capture software, so provide the computer equipment too, so you can lock down admin rights, software, dlp tools, proxy redirects, and all of the other goodness that can be used to limit the risk. This is one solution used in corporate america
I'll bill you at triple my usual rate to pretend to have fixed your code, and you continue to pretend I could have done so without seeing your code.
If you quadruple my rate, I won't even admit to ever have done so.
I think it sounds perfectly equitable.
More seriously, that is what contracts are for. If you can't write a contract and hire people you can trust, you can't accomplish this task. At the end of the day, they'll see your code, and it will enter their brain.
As has been pointed out elsewhere, this is what NDAs with big penalties are for.
Lost at C:>. Found at C.
I mostly agree, except you forgot one thing ... but it will cost you.
Lost at C:>. Found at C.
" so it'll be tough to build an internal team quickly enough "
This smells of failure. Contractors aren't going to get up to speed any faster than internal resources (sans technology specifics like expertise in a language). Our management tried the same thing: hire contractors for a short term (less than 3 months), hurry up scenario. Except it took a month to interview and get the contractors on site. Much of the 3 months of contractors time was spent to get their environments setup, work with IT to configure permissions and the contractors themselves to learn the complex product enough to contribute. Not to mention the loss of focus of the internal team assisting the the contractors.
I would spend more effort coming up with a realistic plan that has a chance at success rather than trying to meet a date that is not going to be met. Build a plan that includes a mix of internal an external resources. I would include time to hire contractors (remembering that background checks take time) plus all of the other activities that will consume time away from producing the finished product.
I've always said English was my second language. Had Romeo and Juliet been written in C, I might have understood it.
Right. As a consultant I will tell you when your requirements are stupid and costly. If you still insist on me working inefficiently it's your dime. I'll happily take more of your money to do it the wrong way and I will make sure my recommendations are clear in the documentation.
You cannot physically enforce security of code sources you are allowing people to see - unless you are going to have them work entirely naked, under constant physical observation, with full body cavity searches every time they enter or leave the workroom.
Hire someone trustworthy, pay them well, and have them work on-site. That is the path to success. Anything else is almost guaranteed to create the situation you're trying to avoid; paranoia breeds dissent and distrust breeds subterfuge.
If you pay them enough, contractors will do the work on-site. It's not a pain, it's SOP.
You cannot simultaneously keep something secret and share it.
This question really doesn't make sense... How do you have a highly-valuable source code repository and simultaneously require external developers to modify/maintain it? How was the code developed initially? Did you have contractors develop it initially, and then have some kind of falling out? Did you have a mass walkout of your staff?
Maybe the cost to have people work on-site is worth it, maybe not. Management said they wanted to keep the code on-site, and management wants to manage costs. Management can decide whether working on-site is important enough to them that they want to spend the additional money, after you tell them how much it will cost them.
So estimate the costs for each option, then let management decide - do they want to spend three times as much to have people on-site, given that there is little to no benefit? Are they happy with remote desktop, given the costs? Let management decide their own priorities.
I don't know your situation. I assume it's not the military-espionage sector but something more akin to HFT or something esoteric in the manufacturing segment.
The raw truth is that it's very, very hard to prevent data exfiltration by a competent software developer who has adequate tools/access for his job. At the same time, it's very, very easy to hamstring a competent software developer and thereby torpedo their time-efficiency. If you're really worried, start with the "edges"--thing like NDA's, copyright/patent agreements, and background/credit checks--stuff that doesn't interfere with day-to-day work. Anything beyond that (change management, device restrictions, copyright headers in source code, etc.) should be more about avoiding sloppiness than about avoiding malice.
The other raw truth is that management frequently believes their software to be more valuable than it actually is. Frequently, the software that it cost you a fortune to build would be nigh worthless to a competitor because integration, customization, and data conversion would make it extremely unattractive compared to improving their own in-house product or buying a commercial product where the vendor is used to making customizations. (Much better in some cases to give your software away [if not open source it]: there are probably a lot of missed opportunities for companies to make their toolset the de facto standard for an industry, reaping money or market influence in the process.) Ask your management to imagine receiving an offer for an illicit copy of their competitor's code. Would they be willing to risk it? My guess is that they'll say "no", and you might want to start job hunting if they say "yes".
Finally, of your two proposals, only onsite work sounds viable. Standing up a fussy/novel telecommuting scheme is sure to frustrate developers [perhaps challenging them to deliberately thwart the system when they wouldn't have given it a thought otherwise]. Moreover, if anything goes wrong [which is very likely], it's your headache and your fault. Don't even mention option (2)... it's just a creative way to get yourself fired. Provide management with option (1) only: if contractors refuse to work onsite, management can think a little bit harder about what their real needs are... updates to the product or [illusionary] control of the source code.
-1, Too Many Layers Of Abstraction