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.
Perform solid background checks and pay the employees enough that you can trust them.
You have to be able to trust your employees. Onsite requirements will not aid in this.
Note: Also... I am also misunderstanding why you can not have them remote into "local" boxes onsite, and run/execute the code from there. That code should execute in exactly the same manner as a local system running the code.... the remote contractor screens might take a little time to update.... but largely should be identical to physically being onsite.
Speaking as a contractor, I'll work on site if you insist. You're the boss. Provide me with equipment and coffee, and I'll suck it up.
We're whores. We want your money. We don't care if your demands are stupid, as long as we can meet them.
You don't give them any source code. You create interfaces (in the Object Oriented Programming sense) and "dummy" implementation version of what your executables do. You provide these to the subcontractors.
This way, they can work on the new source code remotely, without accessing the existing proprietary stuff.
You can do the onsite thing, but you are right in that you will limit the groups which may be interested, and also you may need to pay more as the group may include the cost of hotel stays, food, etc in their quote for doing the work. So you can limit your potential personnel and it can cost more.
If you do the remote thing, they don't have to log into virtual desktops, they can log into real hardware just as well if performance is an issue.
Also, "I need you to fix my source code but you can't see it" ... that's kind of a paradox.
And regarding your source code, set up a NDA. If the group you contract with is a quality group with a good reputation, this shouldn't be a problem. Actually I hate to break it to your management, but unless you are doing an air gap/search of employees entering a special lab where they have no means of getting the code off (floppies, USB keys, etc), your source code has likely left the building one way or another, for good or ill.
You can also tell your management that if they want to do this all internally, etc that the timeline needs to be extended. They are giving you legitimately contradictory constraints. Not that this is uncommon (constraints conflict all the time), but you need to know where the flexbility is.
Yea, but you better have the NDA's in place, even if they are working locally. Not that an NDA will keep them from dropping your source onto a USB thumb drive and taking it home....
Do what the Suits want, as much as you don't like it... They sign your paycheck.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
If the company has fulltime employees who have never worked with contractors, bringing in a team of contractors will make them feel insecure that the contractors might replace them. This often becomes a hostile work environment, especially if the contractors are being paid more. Fulltime employees who haven't been in the job market for 8+ years are most likely to have issues.
If the job can be divided into independent chunks, define an interface and subcontract each chunk to a different subcontractor.
Contribute to civilization: ari.aynrand.org/donate
" 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.
Once you open source it, you don't have to worry about the source code getting out anymore...
Post a job ad, with a caveat in the description that developers can't see the code they are supposed to work on. Report back when you don't get any results. Have some conversations with recruiters and candidates, and document the WTF reactions while you're at it. It may also be worth getting different quotes from the team you wanted to hire: one at a rate with reasonable accommodations that allow them to do their jobs, and another where they will have to deal with endless BS because management doesn't trust anyone. The truth of the matter is that someone really, really wants to target your company, they will. An employee could steal something. You could be hacked. A very determined assailant, given enough time and resources, will get to you. There are tradeoffs made to account for this possibility, while allowing enough latitude for people to do their jobs. It's the same with this group of contractors. If they really, really wanted to steal from you, then they could, and no amount of legal procedure would stop them. If they have built up a good reputation, then they probably won't do this. At the end of the day, this gets down to managing the fear level of your superiors, and it may mean letting something go undone until they come around to letting go a little bit.
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.
Your boss needs to understand that whether they access source at home or at work, they'll have access to source. You can't put those worms back in the can. Traditionally, a condition of employment is to not put the company's intellectual property at risk. This is true regardless of the work arrangement.
That said, there is precedent for having developers work from a citrix farm. And yes, there are reliability challenges. Whether this is practical depends on how good your IT is.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
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.
Why exactly are their own personal systems better for testing than the exact same hardware remote accessed via RDP? It isn't as if the video lag is a relevant factor in benchmarking sub-millisecond response software. Personally, I'd lean toward ssh access to a jumphost myself using key based authentication so you can revoke keys. Then they can just port forward whatever and run most things locally including graphical applications and desktops if that is what is wanted for some reason.
As for the source code not being allowed to leave if there is a way to get in and work with the code there is always going to be a way to get it out. Have them sign an NDA (which you'd want regardless) and tell them the code is not allowed to leave the environment. Working with vi, emacs, gcc etc on a local host isn't much different than working using a remote terminal, the same for x-forwarding a graphical ide it looks and feels much the same as it does on the remote system but when you go to save you get the remote filesystem rather than the local one. If some reason you really need windows (can't imagine why but whatever) you can do pretty much the same thing with rdp. If they execute the binary it is executing on the box they rdp into and talking to these headless servers, not running on their local hosts they are just seeing the results on their local host.
Just take reasonable precautions, both in terms is digital security, legal security, and policy and tell management you've done so and that the source code will not be permitted to leave. At some point you are going to have to accept imperfect ability to enforce, this would be true with the workers onsite as well. No matter how locked down you are there is a way around it even if you pat down employees when they enter and leave. And honestly, most people who break the rules wouldn't actually be doing it for nefarious reasons anyway they'd just be working around your restrictions to suit their personal preferred workflow.
Pirate here.
You seem to be confusing "no one loses anything if someone makes a copy" with "no one loses anything if the internals of this program are made public".
These are two very different beasts.
The first sentence refers to a business model based on selling copies. The second sentence refers to trade secrets. If the code implement some secret method giving the company a competitive advantage, making it public might make the company lose this advantage. If the code contains some obvious security flaws (e.g hardcoded passwords), making it public might decrease/increase the security of systems running this code. I think this is what we're dealing with here (is the software refered to in TFA meant to be sold as off-the-shelf software?)
I'll suggest using AWS Workspaces for the desktops - no infrastructure to maintain, and if it goes down, a thousand Amazon engineers will jump on the case. You can also arrange for a VPN tunnel into your datacenter if access to central resources is needed. Suits like VPN tunnels.
Regarding source code, with AWS at least you control the desktops and can wipe them if needed, but the devs will still see the source. Perhaps a strategic division of labour would prevent any one developer from seeing the entire body of source code?
- The Kessel run is for nerf herders. I can circumnavigate the entire Central Finite Curve in a lot less than 12 parse
Why don't you open another office space closer to your team. They might not come to work at your place, but they might go to another place where you could still control the environment. Then hire security personnel to watch them work if you want !
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
node.js doesn't block so it's faster than c. And since it's javascript, you can find programmers anywhere. Like that homeless guy holding a "callback(){ return food; }" sign. Underneath the stench is a 10x webscale javascript ninja that can rewrite your code in es6 javascript.
Copyright (c) 1990 - 2014 Dice. All rights reserved. Use of this comment is subject to certain Terms and Conditions.
And 99% of all source code out there uses standard algorithms, the key is that for some unique solutions it's the combination of the algorithms that's the unique thing.
The 1% are those top secret encryption algorithms and their encryption cracking algorithms that various military outfits works on, but they would hardly ask such a question at Slashdot. If the person asking the question works for such an agency then it's time to get a new job.
However the data processed by the code is another issue.
Reasons for why a company has a strict limit on their code access is usually because either they have stolen the code - even from a GPL project or they don't want to look like fools with huge security holes in their solution.
In either case you don't want to hire consultants to manage that, you want to have full-time employees that you have control over. The hiring of consultants on the conditions that the poster provides seems to me to be a warning flag.
Another reason for unusually strict rules on the code and use of consultants is that they want to have the job done free by having a clause stating breach of contract if anything happens - even if it's not the fault of the consultant.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
You forgot the other bonus that you know the work won't be sent overseas where intellectual property is harder to defend. If you contract out with a company and give them remote access, who's to say that the work wouldn't be done in China where all knowledge is "public". At least by controlling the work environment, you minimize the impact. Provide the consultants with hardware you control (and lock down the USB ports) and restrict them to only certain areas of the network. If possible, even limit them to only portions of the code that they need to access and not the entire project/repository. If a developer can only see a single module but not the "wiring" and can only run builds created and deployed by a build server, you've kept as much secret sauce in the vault as you can. NDA and Lawyers protect the rest......so invest well.
Besides an NDA and security policy, you can ship them all encrypted laptops. Disable the USB connectors and external data connectors (physically, with epoxy) except maybe a single encrypted keyboard/mouse device like a logitech unified transceiver glued into one port, and only allow vpn into your systems to run executables. Also install gps tracking software in case of loss.
If you have them work on site, that's not cheap. It sounds like you're in the HST business, and that means probably based in NYC, and that means floorspace is a premium. On site work would cost a minimum of $50-100k/yr per contractor.... those contractors would much rather get an extra $45k per year and work from their own office on a $5k super laptop + keyboard + dual monitors, saving you a ton of money per person and making them happy. Have them pay for their own network, and do remote backups every night.