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.
You have a requirement, this solves it. It sounds like a done deal to me.
Plus, your bosses will be happier I expect. They can see the people working on the code and not assume it's being 'zapped off' somewhere.
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.
Though the source could be stolen, it would prevent accidental leakage of the source.
Seems a reasonable compromise.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
If there are proprietary techniques that must be safeguarded, the developers will need to understand said techniques in order to work on the code. So either way the idea itself is going to be known outside the premises.
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.
This is not only pretty much exactly what SSH is for, but I thought everyone who studied computers in any academic setting at all was required to go through such a thing at least once.
If they are writing code, they will have access to the source code. Does it matter if it's on premises, by remote access, VPN or otherwise? Once you let them in the door and give them an account and/or computer they have access to steal the code.
Better to use the legal route and ensure their contract includes NDA.
Where this can get tricky is when you cross international borders. But if it's all in one country, it makes no difference if they are on site or not.
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.
Well, well, where are the pirates to now say "no one loses anything if someone makes a copy"? Then I would respond that they lose the potential value of the code. Then the pirates respond "no one knows if the company would have made money with the code, it's all speculation".
Tell your management having people work locally A) makes it harder to find people to work on the project and B) provides no technical barrier to people copying the source code. Even people working in the building can find all sorts of creative ways to smuggle out code if they want to. I mean, unless the computer isn't networked, has no functioning USB/CD access and you are strip searching people as they leave the building, then there is no point in having them work locally.
Tell management to have everyone sign a contract that includes an NDA. That way they have less incentive to steal the code since getting caught means going to court. It will be much easier and faster, plus it means you can hire the right people for the job rather than just people from the local talent pool.
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.
Answers are already here. We do lots of contract work...when I need them to work here, they work here. I'm paying them and they have to work with my constraints. Remote virtual environment is OK, if you have a well configured environment that doesn't allow data to flow to the client machine.
But an NDA is essential, as is clearly documenting that you own any source code created for project.
That will keep them from seeing anything.
Is this the NodeJS version of the term "blocked"?
What about:
* Contractors work in a locked room on their site (or a mutually leased site near their office).
* Dedicated network that only talks to your network (e.g. a VPN'ed extension of your corporate network).
* All work done on machines you purchased. Machines cannot be removed from this site.
* Agreement no other machines will be connected to this network (you can even lock things down by MAC if you're not trusting on this).
This is functionally equivalent to them working on your site - all work is done on your owned machines in a fixed location from which they are not removed, no ability for anyone to transfer source code outside your network except via your (hopefully locked down) network that wouldn't apply equally if they worked on-site, code is not copied to any machine you don't own. There aren't a lot of attacks on this setup that wouldn't equally apply if the contractors were on-site (e.g. "plug in a thumb drive and copy the code.")
The only slight differences are how easy direct supervision would be, and I suppose in theory a risk if the network was compromised.
That said, having worked on the other side of this multiple times, the long pole of the tent is ALWAYS getting the hardware, network, configuration - those folks are generally overworked in most corporate environments, so this can be weeks before you get started...
Like you can win a lawsuit in India or China. Ha ha ha.
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
Set up an automated build machine task to sign the code on every commit. Then every time someone wants to check out the code, make sure it gets sent to them in an encrypted way (in other words, use git). Tell the managers that the code signatures will allow you to cryptographically verify the code.
The reality is, if an employee wants to steal your code, you will not be able to stop them.
"First they came for the slanderers and i said nothing."
If they refuse, you are not paying them enough.
Do #2. I worked for years with a "primary" desktop with a beefy configuration doing all my compiles; I maybe sat at my desk and used the monitor once a week. Most of the time I just RPC'ed into it from whatever building I was in or from home. Connectivity was an issue on maybe 0.5% of the days, and then it was only temporary (after all, if the company's Internet is down, it won't stay that way for long). After doing that for a while I couldn't imagine being tied to a chair in front of a specific machine for development (shudder).
" 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.
it still doesn't prevent someone from copying source code. We use that method here at Microsoft, and people still wholesale copy source code to their home boxes. With all of the slow Internet connections around there, remote desktop is painful to use. We do it out of necessity.
First off, you are being incredibly paranoid to have this concern and clearly don't understand software development. If it's such a small amount of code that someone can steal it by simply glancing at it then you're hiring the wrong people for such a precision piece if software, especially if you don't even trust them to work on it. Not to burst your bubble, but I can tell you without even seeing it that it's not that good, otherwise people like you wouldn't be overseeing the work. It's just not the way it's done. Software development is an iterative process.
My recommendation would be to seek psychological counseling or figure out how to write your own damn code so that the world will never know it existed in the first place...
Work onsite.
NDAs as detailed above.
Break your work down into the various elements that may need worked on:
1) networking
2) data validation
3) application processing
4) user interface
After all, why would the network guy need to see the user interface routines (that's what APIs / function call parameters are for).
Your content versioning system should also help seperate out such access.
Have someone in-house perform the build activities if you really do not trust everyone, or setup a special build account that can take instructions to perform a build so that X engineer can perform their own localised build. There are ways to read file content but not view them, if you really must.
Unless you are doing something really funky like using a single file for all of your code, then the seperation of duties should help limit your exposure.
If you are really paranoid, have them work in a secure room that doesn't have Internet access and where personal electronics are forbidden. No laptops, no USB drives, no smart phones, nothing that could be used to copy code.
And regardless of the code security issues, managing remote contractors is slow and difficult. If time is a consideration, they must work in your office where questions can be asked and answered quickly... no need to schedule a teleconference on Outlook 3 days from now.
Whether you bring in consultants in-house to assist a new internal team, or you build the internal team from scratch, that will pay off far better for your business than mucking around with consultants and/or contractors in the long term.
Keep your internal team strong and capable of maintaining your products, or fail.
Every time we've had consultants come in and muck around with our code, all sorts of new security holes, bugs, and issues pop up, some that don't rear their head for over a year.
Do the right thing and hire quality people on the inside, even if you need consultants in the short term.
As long as the documentation is up-to par the rest of the system can be a black box as far as I'm concerned, just tell me what the inputs/outputs are and what process needs to be implemented between them... /most of the time I rather NOT see other people's code
It's simpler than You imagine: If You don't want anyone having a piece of your source code, just DIY.
PPL I think we should check on some users from ./ before it become some sort of silly merchandising bbs driven by G$$g_l_£.
So it sounds like you have an unrealistic short deadline, and a situation where code must stay in.
Sounds like a job for a VDI type environment for sure - and definitely folks must come into the office as well.
And the folks who come in shouldn't get a desk - they should be (with you and the rest working on this) in a single large conference room that gets relabeled as the "war room."
This gives the temps who work on it some bragging rights in their resume when they leave, focuses attention, and allows open collaboration to get things done fast. Just gotta make sure you get quality devs that can function in an interactive environment without talking their heads off.
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.
And no ventilation access in the ceiling that's just the right size for a pint-size movie star to dangle through.
systemd is Roko's Basilisk.
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?
The sooner you realize the work you do and are trying to get others to help you with is not contributing to the betterment of humanity the sooner you can find a job that does.
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.
VOTE UP!
No idea who voted you down, but I agree 100%.
This article is obviously BS and the poster either fake, or an idiot.
Slashdot is not just dieing...it's dead.
Right off, you have a premise where you know that management isn't very serious. You need to accept mediocre performance and quality. This does not mean failure. You can still do a perfectly acceptable job (plenty of computer programs were written inside of offices); just don't expect your software to be in the same league as what come out of more serious or "competitive" companies.
Once you accept that, then this..
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.
Better lock them in and don't let them leave.
Hey, Tom Cruise isn't that short.
Lost at C:>. Found at C.
What part of "..and good reputations" does your boss not understand ?
My first step would be to start networking for a new job. This place is going to be 'managed' into the ground in 18 months.
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
Impossible job ad = open door for a H1B to take the real job at a low pay rate.
Split your team in 2 and have the first half working on Odd # line of code and the other halt working on Even # line of code
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.
> as they scrolls by
Arrr, be ye a pirate?
You have a POLICY to make, not a one-of decision. Maintenance will be on-going. It's a people problem.
I would have a be-nice-to-good-people policy. Make them feel wanted and respected. That's down to your management. Then if you hire-in an outside company use an NDA (of course) and make it clear this is an ongoing relationship.
Ben Affleck starred in a 2003 movie, "Paycheck". http://www.imdb.com/title/tt0338337/
After each engineering contract, the hiring company would chemically erase his memories.
If they don't want to do it, then either you need to find someone who is willing to work on-site, or else you need to pay them enough money that they are willing to do so.
If a person lives too far away from where they work for a daily commute to be viable, then they either need to move closer to work or else find a job closer to home, IMO.
(Yeah, I'm a sympathetic bastard, aren't I?)
File under 'M' for 'Manic ranting'
Run. Hide. Failure is the only option.
Make sure the people are trustworthy, have them sign an NDA and that is it. How do you think really security-critical software gets external reviews? Also, even work on premises would let them steal the important parts of the code if they were so inclined, it is not that hard.
One thing you can do for trustworthiness is look for people and small (!) consultancies that already work with stuff of comparable sensitivity and difficulty.
Oh, and pay really well. Nothing makes contractors care less than being treated like cheap monkeys.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
What strain are you smoking?
Usually contracts have an intellectual property clause. Any contract is based on trust.
Get two sets of quotes. One for offsite, and one for onsite.
If offsite is not trusted, then onsite is always a possibility, but at a higher cost.
Push the quotes back up the food chain. Let someone else make the decision.
If offsite is a no-go, you may need your budgets increasing for on site.
If intellectual property is a real concern, recruit two teams of freelance staff, working on different halves, and keep them apart. Use internal staff for systems integration and testing.
Is that a Zen koan, like "What is the sound of one hand clapping?" Grasshopper, when you can answer the question "How to work on source code without having the source code?", then, and only then, you will be a true master!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
The only option to achieve that through process not physical security is to write everything sufficiently modularly that every module is untrusted and interfaces through documented APIs. This can actually be a good requirement since it should make updating any one feature relatively easy. I know of at least one large fortune 500 company that is rewriting everything on the assumption that the network is publicly accessible. This has the nice side effect that you can actually make it publicly accessible to mobile employees.
If every developer is assigned a specific module to write that does a very narrow set of goals then all they need to do is take in data of format XYZ and output data of format UVW. At some point you'll need someone in house for architecting what modules you need developed and an integrator to handle the bits you seem to be paranoid about exposing to developers but it would limit the potential exposure to any one developer going AWOL.
The downside of course is that depending on the task it can get very difficult to break up a large project into discreet chunks/interfaces.
So here's what you are confronted with:
No matter how you set up and protect your environments, source code will inevitably be available to the coders you hire. To a crafty and intelligent programmer, even if you are compartmentalizing that access. you can assert a 'need' to get to know other key areas of the system which will invariably allow you to depict and visualize an overall architecture, which can then be leveraged to get to know other areas that may present a 'black box'.
What you have is a matter of trust. No matter HOW much you protect yourself, any exposure you provide presents a threat, which speaking from personal experience, is a rocky road of paranoia I just do not advocate.
So here's my advice:
First - Hire according to culture and ethics. H1Bs, while less expensive, provide a cultural influence in their work that ripples throughout your organization. Think about it this way: The logic and reason that they bring with them which developed their culture and values is being asserted within the code they create and the products they create for your organization. This effects the mindset of those leveraging the product because the actual implementation of the rules you request in the software will always be different based on the cultural and ethical influences of those doing the development. Hire according to (a) who your target market is and (b) the culture you like to model your own company after. Put simply: Corruption will occur in your software endeavors when the corporate culture is in misalignment with the developer's culture.
Second - show a preference for full timers - people who are vested in your success - rather than consultants - who are vested in the project's success (which can come at the detriment of related projects).
Third. Create an NDA ONLY for consultants. For full timers, you gotta show trust and have this NDA relationship be implied.
Fourth. Try to isolate your core systems before introducing others into the mix. Sure, you might have a finite staff to work with and sure, this might take a few years to achieve, but DO NOT relent to corporate and stakeholder pressure to 'hurry up and produce' - DO IT RIGHT and isolate the core systems you consider proprietary and are not ready to share.
AS You isolate your systems. Objectify. Don't use reverse engineerable code such as .Net, it takes me 2 seconds to use .net reflector to produce a workable version of an assembly and then modify it to suit my own needs. DONT do this with mission critical code! Period end of story. Maybe even leverage old school code that isn't interpreted such as COM assemblies. This FORCES you down a path of placing features and fluff in externalized layers where leveraging .net or java or other interpreted languages and becomes more amenable.
Finally. Find an advocate. if you're not n bed with the CEO or President, then hire a prostitute. No, just kidding (kinda)... Really though - if you're in a sizable organization, then make friends with the C and SVP level staff so they can go to bat for you and act as your defense when you're retooling your environment.
WHY? They can mitigate the risk of pressure exerted by the stake holders and other short term profiteers, and help you focus on creating a sustainable framework not just for your future, but for theirs should they decide to hold your organization and/or company for the long term.
If you're a mere manager or project manager. Quit thinking like one. YOU have the power to say no to your directors and to go direct to the CIO. Sure. you might get your butt handed to you. but people have a tendency to respect those who believe in themselves. Even if they're wrong.
As for virtualization versus working in the office.
Quit thinking so in the box. In a situation like yours you HAVE got to come up with different options rather than acting with obedience to the orders you're given.
Good luck.
You don't trust me with your source, but you do trust me to modify it... interesting!
Anyway, I'd never work for any company that forces me to work with one hand tied behind my back. I'll work for one of the 99 other offers I got instead.
Just plonk all the source up on there and away you go (before the contractors do).
Years ago (before pastebin) we once found / caught out a contractor who posted up almost a complete testing server's contents, including passwords - as he was looking for help solving some coding issue he ran into. Many of the contractors have degree-mill level skills (read: zero) and no clue about NDAs.
Good contractors will never do this, but you get what you pay for.
Offer more money so that the programmers are willing to work on site. This just sounds like a case of the el-cheapo effect.
Lock them in a room, with access to the relevant (air gapped) systems only, until they're done, then flood the chamber with Nitrogen. They won't feel a thing.
API specifications? If the suits won't let those leave the building then yeah, it's all got to be on site like others are saying. Sounds like a nice little train wreck you've got going.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Having worked for several years in software development - it is understood in a lot of cases that option 1 is non-negotiable.
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.
Open an office close to each of the developers. You control the environment, the developer is close to home. Everybody's a winner.
Typically, when threatened with being laid off, fulltime employees will announced their intention to draw six months of unemployment benefits to take a vacation and then find a new job. My roommate did that following the dot com bust. He couldn't get back into the industry and took a cashier job with Walmart in 2002. He's still working there today.
After the dotbomb... the sit on your ass cubicle warmer jobs never came back.
These are all the people that were hired without any training, but an interest in the subject, because the companies were so desperate to "scale" that they pulled them out of the educational system early to demonstrate to the VCs that they were "staffing up". They are basically cubicle warmers, if they never made the transition to "apprenticed geeks coming up the old fashioned way". Most companies don't want such people, even if they've previously made the transition, since in many cases, experience does nothing for your ability to work on a team, the way a formal education would.
First, it stops you from security auditing the code,
second it stops you from doing code reviews,
third, if the company goes under you wont have any source at all.
fourth, if they're found to use GPL code, then you're screwed legally there too.
At best you might let them keep copyright.
Working on premise won't help either. These people will still have to leave the building once in a while. There goes your code.
So the code is so big and complicated, that nobody could hire a group of cheap indian / chinese programmer to write something better in 6 months ? Must be a huge package, like MS Office.
Small programs like Photoshop could be 80% written by a couple of people in 6 months. Look at RC equipment, communication protocols are reverse engineered, and people are using arduinos as converters within a couple months. My FlySky i6 / TGY-i6 6-channel transmitter had its firmware hacked within a few months, now it does 10 channels, with the iA6B 6-channel receiver. And it has virtual switches etc. This is not new firmware, it is just reverse engineering, and changing. I have a $7 logic analyzer, so I also look at protocols on the wire/pins of chips.
Software is overrated in value. The value lies in the product, the marketing, the customers. OK, without software you would not have the other. But the software alone is worthless.
Look at my $7 logic analyzer. It s a Saleae Logic clone. Runs with the original software. And with many free 3rd party apps. People by SL to support them, and to get them to further develop the software. Or to be legit. But anybody could bundle some of the Open Source software with a clone, and sell for $50 instead of $150 like SL. But they would not have a chance. They don't have the name. If you get a clone, why not get the cheapest ?
Apparently the MPAA are experts at sharing digital assets, but not allowing you to copy them....
If you do the virtual desktop correctly, they have basically the same delays as being there in person, the screen refresh and human ability to notice and interpret. They will be able to record the screen/session so could technically still copy the code but it would require a lot of work, but a NDA should help.
The locked down desktop should provide them all the access they need. You can decide if you want to allow them to print or not.
Just image that they are using Xwindows and exporting their displays back to their own computers.
If someone looks at the source code and then leaves the building, the source code is technically outside the building. If a halfway competent person looks at the source code, they'll know what parts are interesting and which ones are not, and only memorize the juicy interesting stuff.
Here comes my observation from my 15 years as a software developer:
1. I do not want your code! If I want to copy your softwares logic, give me the manual for your product.
2. I would never ever work in an environment where I was forced to remote login to touch the code.
Why would I want your code? What would that give me? I _write_ software for a living.
The real problem here is not technical, it is a management problem. They are defining how you achieve the objective when they should be giving you the objective and delegating the how to you. That is the problem you need to address with them.
This. A manager told me once that these kind of things are very easy. Just look at it as if you offer a menu. You have a starter, a soup, main course, desert, coffee and wine during the meal.
You tell them the cost and then thye decide if they want the whole meal, drop the starter, or the soup or the wine or whatever.
The hard part is to stick to your price. Do not be tempted to give the whole menu for the price of the menu without the soup. So you need to have good knowledge of the pricing and be able to defend those prices.
Be prepared for all the questions. e.g. but what if we use cheaper hardware? That should already be part of the menu.
If you are smart about it, you have three prices. The cheap one where everything will fail, the perfect one that is WAY too high and the one that you want to sell to management, because you know it will be the best because you did your investigationand you have the experience they hired you for.
I have been in meetings where the CEO said basically: Seems very clear you know what you are doing, so do whatever you think needs to be done. That did not mean a free for all, it ment that the decision was well thought out and all (as in the huge majority of them) questions were thought of.
So yes, let them decide and help them make that decision and when they choose to have no maincourse, make it clear that they will go hungry at the end and that ordering extra food later wil take longer and cost more as the chef is already gone home.
Don't fight for your country, if your country does not fight for you.
This won't help or change anything, but I have to chip in with this thought.
1. Treat your employees like human beings and pay them well so they don't have the incentive to steal from you
2. Hire people you trust. If you don't trust your employees, fire them and hire ones you trust. If you don't trust anyone: write your code yourself.
But most importantly : think about why you cannot trust your employees.
I worked at environments where security guards (more like bodyguard types) were looking over your shoulder all the time. I also worked in banking where
This is not a way to spend 8+ hours a day.
More to the topic:
Develop APIs with a trusted in-house team. Have your contractors work with those APIs ... Might or might not work in your case/code/environment/project.
Put the code into a .DLL or similar share-able code source, document it, and let them work off of that. Use the GNU/BSD/Mozilla/whatever license to protect it.
The "expensive" but quick to implement citrix workspace. It even has the ability to run a Linux environment. The hardware to run this software is quite expensive, as well as a learning curve on the management of citrix workspace software.
The cheaper KVM on Linux route. You still need robust hardware. As long as you don't need a 3D graphicly accelerated environment, it should work fine for remote work.
For both instances disable USB mass storage device connections. They could still cut and past steal the code, but it would be quite a pain to do so.
You should resign from the project to save your own skin.
....or change jobs. It is somewhat of a defeat to throw the towel in, but if management is intent to set you up to failure you need to move when they do not move. I am sure you find a contractor to do the work on premise if the price is right. Still will need an NDA and good corporate legal.
Also, I'd imagine that if a remote person really wanted the sources, they could video the sources as they scrolls by.
Go back to India.
a misplaced sense of security. The building is not securing the source code. You should first focus your efforts on convincing why physical security of the building is not what is protecting the source. I ponder what extraordinary circumstances you might be working under, already. Are there not non-compete contracts in place with current employees?
Regarding hiring outside help, perhaps, there is another issue: assuming your company is in the US, is the code possibly subject to International Traffic in Arms Regulations (ITAR)? If there is a hint of a possibility, then you need to look into this as it will restrict who can be hired to work on the code, as well as the physical location.
I know of one company that was so distrustful of its employees (or, more likely trying to hide something) that only the founders were allowed direct access to the version control system for the flagship product. They had in place a ridiculous check-out, check-in procedure that slowed development, needless to say. It smelled pretty strongly that the source had been ripped off from the founders previous employer and that they worried that access to version control history would reveal that. No surprise that culture there was stifling and the guy I knew that worked there did not stay long.