As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm thinking about adding some kind of copy protection to one of my tools.
Do you have any experience with that?
Have you developed your own protection techniques or did you buy 3rd party software?
Do you think it is a viable method to increase sales? (In a private and/or corporate environment)
What do you do to prevent hassling your paying customers? In most cases it's the paying customers who suffer from a bad copy protection, and I don't want this to happen to my customers. (Even if that means accepting some freeloaders)
I'm especially interested in techniques which allow a trial or freeware version of your software for private use but limit the usefulness in a corporate environment.
Related Question: How do you protect your software from illegal distribution
Related Question: Protect .NET code from reverse engineering.
Related Question: Prevent the circumvention of copy protection.
Whatever technique you use, your software will be copied. The actual aim of copy protection is to prevent honest customers from being tempted to be unfair.
The minimum copy protection technique is enough. The maximum is not worth the time spent.
Moreover, I've heard that some developers provide user support to any user who asks, customer or not. The idea is that happy users may become faithful customers.
On desktop apps I've been using a Clarion Template (3rdParty, http://www.capesoft.com/accessories/secwinsp.htm).
With web apps, pretty much just been using the simple fact that the User has to log in, and tracking the activity. If they have an account, it means they've paid.
Desktop is a lot harder to track. As has been said, very easy to crack. Very much a case of:
Make it annoying for the Hackers, but as unobtrusive as possible for the Users
"The hardware is the dongle"
That was what we always said at my old job, and to some extent, it's also true at my present one. Basically, we sold physical hardware to run our software, which we gave away for free. This probably isn't feasible for all businesses, but it's a nice feeling to know you don't have to worry about piracy, because people are invested in the hardware, not the software.
As mouviciel mentioned, nothing is perfect. Aim to gently encourage users who might buy your product to buy it, and forget about the people who never will.
Some general tips:
Don't bother implementing your own protection, unless you have experience doing so. This is an area where paying someone who's specialty is providing some type of licensing/protection is probably worthwhile (just keep in mind it won't be perfect).
Choose a license key system that is difficult to keygen. Again, picking a pre-built licensing system will likely suffice. Creating your own from scratch will likely not.
Take the time to properly integrate whatever licensing system you choose. If you just "protect/wrap" your executable(s), the protection will quickly be removed. Most licensing/protection products offer easy integration tools/macros that make automated cracking much more difficult.
For corporate software, the best thing you can do is make it easy for administrators to ensure they are within the license boundaries (# of instances/installs, etc.). Provide a central place for them to verify this, and gently remind them if they go slightly over, before you take any more drastic actions. In a large network environment, software licensing can get very complex for the IT dept. Make their job easier and they'll thank you.
"The technical support is the dongle"
This doesn't apply to all applications, but for complex applications with higher price and lower sell volume, providing excellent support to your customers is the best way to be sure all your users are paying.
I know this post was submitted quite some time ago, but everyone always seems so negative when this subject is discussed. For obvious reasons I prefer not to say where I work but we use CodeMeter by Wibu-Systems US. We chose this as hackers didn't manage to hack this during a hacker competition.
Regarding all the questions you ask, it is really flexible and they offer a free SDK, which is how we tested before we purchased.
For some products we (have to) use hardware dongles. Although they give a prety good copy protection, they are a real hassle for our customers.
All other software is protected by a software key. And yes you can copy those. But we have very good experience that customers don't do that.
Without a key a program works normal, only you can't calculate the model and some print functions are disabled.
You do need to employ copy-protection for your software, but as others have said, make it as hassle-free as possible for your customers. Your aim should be to keep honest customers honest, and not make them go through hoops before they can finally use your software.
I would also advice against spending your time on coming up with your own licensing scheme, instead spend that time focusing on your actual product.
Consider using CryptoLicensing - it provides licensing, copy-protection, activations, machine-locking, trials, and other features.
DISCLAIMER: I work for LogicNP Software, the developer of CryptoLicensing.
Good software doesn't need a protection. Your software will ever be copied, no mather what protection you choose.
So the best way to avoid illegal copies would be to make your software user-friendly, so that your customers are happy and satisfied with your product.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
A medical practice has approached us about using Filemaker as a fully-fledged EMR system with a HEAVY emphasis on using iPads to enter patient records, photos, digital signatures etc which can obviously be accessed on desktops as well. Ultimately they would like such a system to replace their current EMR and takeover all billing operations, patient scheduling and so forth. They only use Macs in their practice.
We have very little experience with Filemaker but found this discussing the Pros and Cons of it however it seems that Filemaker has come a long way since 2009 when that question was asked...
So overall I'm just trying to work out if Filemaker is suitable for such an application or what would be the pros and cons of using a combination of FMP12 and FM Go.
(Sorry if I've done anything wrong - first question...)
Thanks!
As a FileMaker Developer myself, I would say go for it. I agree with Mikhail - You WILL see results faster than any other platform. You can make changes yourself easily and live or you can get a FileMaker developer - just like you would need to get a developer for any application.
With an off-the-shelf application, they tend to be quite inflexible, however I am sure there are systems out there that allow some customisation.
FileMaker is a very capable product. We have written many applications for vertical markets, such as law firms and even a Harley Street plastic surgeon who gathers patient data on an iPad and even sketches the suggested surgery on a picture of the patient.
For those who think FileMaker is a baby, have a look at http://www.businessmancrm.com - this is a full ERP system used all over the world. This is not an advert, but a demonstration of what is possible with FileMaker.
Dollar for dollar, FileMaker will win hands down... and when it comes to time frames, there is no contest. We are open minded - We constantly look for other products to develop applications for ourselves and customers and we have not found anything more viable just yet.
Pros:
Extremely quick environment
Cross platform
Integrate other SQL data sources into application
ODBC Support
Remote Access
Can be run from a USB stick if needed!
Thousands of developers around the world
Large community
FileMaker Inc. have made a profit every single quarter since existence, therefore are stable and do have the backing of Apple!
Reasonable Cost
Make changes yourself
Easy to backup, supports incremental backup
Easy to secure and encrypt data on a network
Supports terminal server
FMGo is free
Cons
High level language (not low level with layout object control) - However does support plugins
Requires FileMaker client (unless a web application/interface is built in PHP or using IWP - Instant Web Publishing)
Proprietary Database (however can easily link into MySQL, MSSQL and Oracle)
Honestly, not worth it.
It's a very clunky front-end for a database.
If you do decide to pick it up your basically stuck with paying a Filemaker developer for the rest of its existence.
One of my clients at the moment has had it for the last ~6+? years after only being with them for the last 8 months i'm trying very hard to push them away from it and onto a newer system.
I can suggest looking at Mastercare EMR, Profile and MMEX.
FileMaker is perfectly capable of it, of course, and I expect you'll be getting first results much faster than with any other approach, especially with the iPad. There's quite a few EMRs out there written in FileMaker. There are downsides, of course; it was always targeted to end users so it ended up fairly inconventional from a common programmer's point of view. Many programmers dislike this. Being end-user it suffers from many simplifications (well, not exactly suffers, actually; this makes development faster as there's fewer choices), but people always want something special so there's a huge number of workarounds to overcome these simplifications. These workarounds vary from relatively harmless to very hairy ones.
For example, to sign documents on iPad you need to add a webviewer control pointed to a generated HTML page via the "data:" protocol. The page is going to have a JavaScript that captures user's touches, paints them on a canvas, and serializes this into a string. Later a script will capture the string, store it in a FileMaker field, and change the generated HTML to use this string so the JavaScript can redraw the signature. This one is relatively simple and since the functionality cannot be obtained in any other way, it's in wide use; there's even a commercial module for around $300. A complex app may consists of dozens of such workarounds; anyone who is not a FileMaker developer won't be able to understand why you need a webviewer to capture a signature or why you use a strange contraption of invisible tabs to display what looks like a simple pop-up list. I.e. it's not like you read a book and work from there; be ready to read quite a few blogs and frequent forums and mailing lists.
That said, it's a good product nonetheless with unique capabilities (that iPhone/iPad client, for one); paired with a good developer it can be very powerful.
Having developed an EMR system at a recent position for 3 years, I can tell you from experience that the requirements for a true EMR system may quickly outgrow the scope of what is easy to do in FileMaker. A few really big, important EMR features come to mind immediately:
Insurance Eligibility verification: is there going to be a way to hit all of the major payers' web services or a third party aggregator to verify insurance eligibility from the iPad?
Insurance Card OCR: sure you can snap a photo of an insurance card, but now you have back office staff typing that information in from an image. We implemented OCR of insurance cards in our EMR and it was a huge cost and time saver.
Security / Privacy concerns: HIPAA compliance is a big deal, and is FileMaker suitably transparent to be compliant? Is there any way to audit who looks at a record? How is the data transferred across the wire?
E-prescribing: All modern EMR's support electronic prescriptions, which carries a complex set of rules and implementation details along with it, I would want to be certain FileMaker could be integrated with an e-prescribing gateway before proceeding.
My main concern with using any off the shelf, cross platform tool to approach a problem as big and complex as an EMR would be getting painted into a corner down the road, having invested a bunch of time and money into a solution that may leave you unable to implement a feature or requirement, whereas paying the up front price of developing a native iOS app (and web apps and whatever else you need to integrate with) would eliminate that possibility, but obviously cost more.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
My company is trying to pass a policy forbidding distribution of any application (even free) in any appstore for all developers.
Their reasoning is that "outside work activities create a conflict of interest". They don't want that "you use your spare time to work on your app, and once it takes off you quit your job" (quoting the Head of Development).
A few developers (myself included) have already said it was an abusive, pointless and most of all counter-productive policy (developers will actually be demotivated to work here under such control and to be denied of the freedom to distribute their project).
Personally, I think it is actually in the interest of the company to promote side projects (even commercial activities, if there is no conflict).
I'm also curious, is that common practice?
Needless to say, this is horribly, horribly stupid on so many levels... It may be worth trying to find out whether it's even legal in your jurisdiction.
Anyway and apart from that, if you can, find colleagues who feel the same, and take a stand against it. Try to explain to the management that this is a stupid decision for the company as well. Don't sign anything: A policy like that would probably have to be amended to your work contract to be binding. Chances are, the risk of losing good employees over this outweighs the security they think they get from it.
If there's really nothing that can be done, and you are very unhappy with this (I would be), consider looking for a new job.
As an afterthought, if the practice of limiting your employees' rights to this extent is clearly illegal in your jurisdiction, it could be that simply making them aware of this might stop this without any further trouble.
All companies for which I have worked allowed outside work provided:
no company resources were used (this includes time)
the product of that effort did not directly conflict with the company's interest
the product was not based off of work or specific knowledge gained while working for the company
Typically, companies have a clause in your employment agreement that states that you will inform them when you begin work on outside projects and inform them of the nature so they can approve/deny. In such cases, you want to get that approval in writing.
In your case, this is a pretty difficult situation if this was part of your employment agreement. Even if it isn't, they can fire you for it if your employment is at-will and they find out. Unfortunately, in your situation, you seem to have one of four options:
Convince management that they are being unreasonable.
Fly under the radar and hope you don't get caught.
Find a new job.
Quit and just work on the apps full-time.
If your job is to put out apps in an appstore, though, there's really no way to argue that your outside development of apps for the same appstore isn't a conflict of interest in some respect. If I had to guess, I'd say that either this is the case or you're working for a development manager that doesn't understand the mindset of developers and how they like to tinker and learn outside of work.
While this example sounds a little draconian, it is not uncommon for companies to have some kind of policy regarding outside work. However, this is typically to protect the company from your mistakes rather than to protect them from your departure. If they're that concerned about employees leaving, they should go out of their way to make it the sort of place you would want to stay.
EDIT: I just found this today on a completely unrelated blog, but it totally rings true to this discussion. It's about 11 minutes long, but very entertaining and makes you think too. http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=player_embedded The TL;DR (TL;DW?): Once you get outside the realm of purely physical tasks, organizations that assume you are motivated by money, hands-on direction, etc. will not accomplish their goals nearly as easily as those that assume you are motivated by desires for autonomy (self-direction, self-management), mastery (getting better at doing something) and contribution to something bigger than yourself.
I believe there was a similar pointless rule when I was under the corporate yoke. I think these rules are pointless, backward and wrong. Instead of keeping their developers management pushes them to look for new managment, well, at least the passionate and talented ones.
Unless your employment contract says otherwise, what you develop in your own time belongs to you.
If they are in the business of writing apps for the appstore, then they might have a non-compete argument against you.
If they allow other types of development projects, it is difficult to see the argument as valid.
Depends on the app and the company.
If you're working for an Android app developer, I'd see why they might not like it. 8)
If it competes directly with what your company produces I can see why they'd prohibit it.
I would consult a lawyer to see just how binding such an agreement would be if you were forced to sign it.
If it's really that odious, your only recourse is to find another employer.
Check your local labor laws. In California, this kind of thing is blatantly illegal.
The policy enumerated by Shaun is reasonable, and something very similar has been in place at most of my previous employers. The one place that tried something like this was quickly pointed at the statute by knowledgable developers, and the "policy" quietly went away.
The answer is in your contract of employment.
But if your job is as a computer programmer, you're almost guaranteed to have something in your employment contract stating that any software you write either in work or outside of work is owned by the company.
If you get written permission from HR and your manager, then if you were to make millions from you out of hours projects, then it would be more difficult for your employer to just take ALL those millions off of you.
I dont know what to say. About 3 days ago I released a script to the public. Today I realised, after searching on google that someone had already nulled (removed my protection) and pirated the script.
How do I stop users from pirating the script? It is written in PHP.
Please help or suggest some solutions.
Thank you for your time.
UPDATE By releasing to the public means that I have started selling it to users.
UPDATE My program is priced at only $49. Very reasonable for the functionality it offers. I do not understand how I should stop pirates from pirating my code. The replies which most people have given are rather sarcastic. I was hoping for some good advice. I know there is no silver-bullet. But some techniques which you have used in your PHP programs.
The only real way to prevent piracy is to not give the user the program at all! What I mean by this is have the logic you want to protect remain server side and offer a client interface.
There are a few companies that offer protection services, but these are expensive and can sometimes still be overcome.
If you're worried about this happening again, try obfuscating your code. Here is a free program to do just that on PHP code.
I'm not trying to be sarcastic here: forget about them. Here's my rationale:
You can spend tons of time trying to
prevent pirates from pirating your
stuff, or you can spend the same
amount of time giving your paying
users more functionality.
Extreme copy protection does not give your paying users anything but more
hoops to jump through to use your
application - which might lead them
to get frustrated.
Pirates will pirate your applications
no matter how much time you spend
trying to stop them.
Budget a certain
amount of time to put in basic copy
protection - just enough to keep the
honest people honest.
Most importantly: Don't irritate your paying customers.
They are the ones you need to make
happy.
There's not much you can do.
Be flattered your work was deemed worth the effort!
How do I stop users from pirating the
script?
Do not release sensible source code to the public...
[EDIT] After a few downvotes, I decided to comment on my answer:
Any code that is released public has a chance of being hacked. This is the number one reason why Javascript is not secure. No matter how much you will obfuscate it, compress it or translate it to some random japanese dialect, it is still source code that the user has access to. Hence it should not contain any sensible information such as passwords or such. All sensible data should be stored in the server side where it is kept hidden from the user.
If you are releasing a php framework containing both the server and client code; then you have no way of fully protecting yourself. PHP is, like Javascript, an interpreted language. You may translate it, compress it, or obfuscate it as much as you want, (and it's probably the best thing you can do) you will never fully protect it when released to the public.
Again... If there was a magic way to prevent code from being broken, it would have been known for a long time. No-cd patches / cracks for new games/softwares now are almost released the same day as the softwares themselves. It is, as noted by Paul, a form of flattery for you, even though I understand how sorry you may feel.
There are a few instances where programmers ended up with bullet-proof protection, but it usually involved high-end engineering.
With PHP, you're mostly out of luck. It's an interpreted language, which means that you are essentially forced to give away the source code. Sure, there are obfuscators (tools that "scramble" the source code to make it near impossible to read for humans), but they can be circumvented as well.
There are product like Zend Guard which seem to offer a better level of protection, but from my understanding, your customers need Zend Guard installed as well, which is almost never the case.
There are several methods of handling this:
Offer your product as a service. This means finding appropriate hosting in the cloud, etc. This removes access to your code base, thus preventing direct piracy. Someone can still reverse engineer your stuff, but I'll touch on that later.
Add a unique identifier to each version of the script sold. This can be done automatically, and is great to do with obfuscated code (another, complementing method). This will give you the ability to track whoever pirated your code. If you can track them, you can sue them (or worse).
Pursue legal action. You'll need to know who leaked the code in the first place for this. Their PayPal information or even an IP address should be enough. You go to your lawyer, ask him to get a court order telling PayPal/ISP to release the identity of the thief, and then start tracking them down. If they're located overseas, your only real option is to freeze/appropriate funds from PayPal/credit card. Banks will be sympathetic only if they have a branch in your country (which can be targeted for legal action).
Ignore it, and simply build your business model around the support that you offer.
The sad fact is that information cannot be secured completely. There is no way to prevent a team of Indian programmers from reverse engineering your program. So you just have to be better than them, and constantly improve your product (this is "A Good Thing (TM)", so do it anyways)
Also keep in mind that DRM and other solutions are often controversial, and will reduce your sales (especially among early-adopters). On a personal level, I would suggest viewing this as a compliment. After all, your script was useful enough that someone bothered to pirate it within a week!
PHP is easily decoded, so for people who really want to know, it's easy to find out the source code. However, there are certain obfuscator programs such as this one that'll make your PHP script almost unreadable for those trying to decode it.
What kind of protection did you think you had added to a PHP script, anyway? You should add a line of the form:
if ($pirated)
exit();
and then make it mandatory (in the licence agreement) that users set the $pirated variable accordingly.
Forget trying to prevent it
Go the way of CakePHP (see sidebar on front page) and many other open source projects and ask for donations.
People actually do it!
Contact the pirate and let h{im,er} know that you will be forced to take legal action against them if they do not abide by the license.
I agree with #Michael.
Try ionCube or Zend Guard. They are both commercial offerings, but you say that you are selling your software so it might be worth it. Although nothing is foolproof and can be reverse engineered with enough effort and technical skill, these solutions are probably good enough for the average PHP script vendor.
I agree with Samoz's suggestion to keep the logic server side, however this can often be hard to do. The best strategy is to make the user want to buy it by offering updates automatically to registered users, as well as installation, advice and good support. You are never going to sway people hell bent on pirating, however your goal should be to persuade those who are undecided as to whether to pirate or purchase the script.
Any obfuscation/decryption technique for PHP can be cracked
Jumping in very late to this conversation, but saw this question featured. Nobody mentioned contacting a lawyer and pursuing litigation. You likely saw the script on a server - hosted by a known hosting company - you can probably get a DMCA takedown to have the script removed. If you really press the case, you may be able to sue for damages.
Found this link to assist in going this route:
http://www.keytlaw.com/Copyrights/cheese.htm
You could always pirate it yourself to the internet and hope that any nuller will think "its already been grabbed" so don't bother. But pirate a real buggy version. When users come to you looking for help you'll know they have a pirate version if they question you about specific bugs you purposely added and you can approach them accordingly
If your script won't consume a lot of bandwidth, you could keep your "logic" server-side, as samoz suggested, but if your users won't use it responsively ( a crawler, for example ), this could be trouble.
On the other side, you could become a ninja ...
Attach a copyright notice to it. Some companies will actually care that they're using software properly.
Actually I think it's easier to protect PHP scripts than desktop software, because with latter you never know who is running the cracked copy.
In case of PHP on the other hand, if people run your software on public web servers, you can easily find them and take them down. Just get a lawyer and turn them in to the police. They could also be breaking DMCA laws if they remove your protection so that gives you even more ammunition.
Technical way to protect your code is obfuscation. It basically makes your code unreadable like binaries in compiled languages (like Java). Of course reverse engineering is possible, but needs more work.
In general it's hard to prevent users from stealing code when the program is written in a scripting language and distributed in plain text. I've found that http://feedafever.com/ did a really nice job of being able to sell PHP code but still give the code to users.
But the solution to your problem is very dependent on the domain of your program. Does this script run on the users machine with no internet connection? Or could this be a hosted service?
I'd also suggest looking at some of your favorite software, and seeing how they convinced you to pay for it initially. The issue I find isn't always "how can I prevent my users from stealing my software" but sometimes more "how do I convince my users that it's in their best interests to pay me". Software piracy often comes when your product is overpriced (Ask your friends what they would pay for a software package like the one you are selling, I've found that I have historically overpriced my software by 20%).
Anyway, I hope this helps. I'm glad that you are trying to create software that is useful to users and also not incredibly crippled. I personally of the mind that all software that isn't shrink wrapped or SAAS should be free, but I totally understand that we all need to eat.
The trick is not to try to prevent the piracy (in the long term, this is a losing battle), but to make the legitimate version of your product more accessible and/or more functional than the pirate versions.
"Making it more functional" generally means providing involves additional features or services to registered users, which cannot be replicated for free by the pirates. This may be printed materials (a users manual, a gift voucher, etc), services such as telephone support or help setting the product up, or online extras within the software.
I'll point out that companies such as RedHat are able to make significant amounts of money selling open source software. The software itself is freely available -- you can download it and use it for free without paying RedHat a penny. But people still pay them for it. Why? Because of the extra services they offer.
"Making it more accessible" means making it easier to get your legitimate software than a pirate copy. If someone visits Google looking for your software and the first result is a pirate download site, they'll take the pirate copy. If the first result is your home page, they're more likely to buy it. This is especially important for low-cost software: pirated software may be 'free', but usually it takes more effort to get. If that effort is outweighed by the low cost and lack of effort of simply buying it legitimately, then you've won the battle.
I saw anti-piracy working once only. Quantel EditBox systems (a post-processing video solution), Hardware+Software+Internet solution against Piracy. Workstation only works after checking if the bank received the monthly rent. If not, workstation was locked. Funny days when this happens... (Funny days for me, no work at all... No funny day for the hacker.)
Well, PHP is far away from hardware solutions... so I guess your only real choice is a server side protected against a tiny unsafe client pushing content, as pointed in some answer yet.
piracy != copyright infringement
There are known routes to litigate copyright infringers.
Does it really matter enough to hire a legal team?
Obfuscation do add something. It will not be fun to try to modify your code at least even if they can take the first version of it. In best case they will try to find some open source project that does something similar. Guess this would give you an fast fix at least for your problem?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm currently a developer at my first job right out of college. I work for a large company, and the trend I notice with them is that they tend to go with more expensive, closed source software about 99% of the time, while there are perfectly good open source alternatives that are available, most of which are vastly superior to their closed-source counterparts. For example, we use this absolutely awful source control software that cost a ton of money, while there are quite a few open source and/or free options that in my experience, albiet limited, are much better and offer basically the exact same functionality.
I guess my question is: How would an experienced developer approach management about using more free software?
It appears there is another question very similar to this that did not show up when I made this one: How can I convince IT that F/OSS software isn't evil?
EDIT: Just come clarification. I'm not necessarily trying to change the company's procedure, I'm looking for advice on how to approach management about the subject.
Start using it in small utilities and things which are throwaway and don't need management buyin. This can prove the worth of an open source solution and put a crack in
the door for using it in other
projects.
Present articles from trade magazines showing that other people are using the open source solution.
Go with products which have commercial support options, such as MySQL, which enterprises seem to have an easier time swallowing.
Pick your battles carefully. Wait until they are suffering. If they are happy with what they have, they will not switch, no matter how much cheaper or superior the alternative is. You need to catch them while they're trying to think of ways to save money, or while they're disgusted with the problems of the current system.
Be very careful with what you refer to as free. There is a very large corpus of products that would be perfectly valid for a student to use without paying that an enterprise would have to pay for. Also never forget Total Cost of Ownership (TCO). A lot of relatively expensive software is expensive because you get things like configuration and help support for them whereas that may not be the case for free software.
I think you are not asking the right question. To me, the challenge is to have my Big Corp to buy the BEST softwares for me, be it free softwares or not.
Paying for Windows or paying for Linux is not important (what is 100 $ for a Big Corp ?).
But having things done better is really important.
I think that your request to your boss should not be : "Hey, it's free and it's as good as XYZ, why are we using XYZ ?"
Why you boss would risk something trying the product you told when XYZ seems to be ok ?
It would be much more better to ask : "Hey, here is what I cannot do with XYZ : (your list). With my product, I would be able to do that and much more so fast than I would have a lot of spare time to test our own software !".
Small money is usually not a show stopper. Being able to work faster in order to do much more testing (or any other things that could help your boss have a better image) is definitely an excellent argument !
Best wishes,
Sylvain.
I work in a big company that has recently moved into being more enthusiastic about open source solutions. There have been a few big hurdles:
Customer won't support it - we're defense contractors. We do almost nothing without customer say-so. As the customer's opinions have changed we've been able to change our architectures and tool usage. That said, there are still scenarios were open source is unacceptable and we don't use it.
No tech support = scary - in several cases, it's been possible to make the point that open source may not have a single point of company tech support, but it does have huge communities that will support questios for free, and that there are consultants available as needed for the really hard stuff. Plus many, many releases of new versions for bug fixes. And, several competing expensive products have not been able to service tech support needs. Being able to point to specific internal examples with long. well documented, histories of support problems, has been key.
Fear of security issues - we had to develop a process for scrutinizing and controlling every peice of open source introduced. We've managed to find criteria for what we deem risky, versus what we deem relatively benign based on info-sec policy.
Fear of lawsuit - Being large, and profitable, we fear lawsuits, we're great targets. We now have a process for the legal team to scrutinize every open source license. This has proved to be a win - since the legal team now has briefings on every major version of the typical open source licenses, and they can quickly review most stuff.
Version control - fear that if those wacky developers can just download anything they like the world will self destruct. OK, well, practically speaking, the concept of "how do we know what's in a given product" - being able to show a FOSS version control process that is managed internally has been important.
It was definitely a slow process - small projects proved profitable and customers started encouraging it in proposals. That made it useful for executive management. It's helped that those that support it have been williing to put in some extra time to making the business case in terms of efficiency/cost savings, and have been willing to negotiate repeatedly with various parts of the corporate infrastructure.
Making open source work has taken the effort of IT, the info security folks, the legal team, the procurement team, and technical management. Knowing that before you talk to your manager is probably a key to success.
There's also some political savy - for a first project, don't encroach on any sacred cows - ie, those projects that may not be successful, but are high profile and owned by someone with lots of political power. Instead, choose some wacky new thing that isn't available right now and prove the cost savings in a way that is unlikely to provoke a defensive reaction.
When you try to introduce open source software to a big company (or even a small one, in many cases), the biggest counter-argument you're going to hear is "There's no tech support." Companies tend to be wary of using software that's supported by the community, because there's no guarantee (or in some cases, service agreement) that questions about the software will be answered within a reasonable time frame, or at all. In many cases, you can find a company that will provide support for the open-source package you want to use (for example, Red Hat does this for its Linux distribution, even though the contents of the distribution is mainly open source). Showing management a business entity that can support the software will often go a long way.
The other counter-argument to using open source software that I've heard the most often is "Open source software is buggy." This is a tough one; this opinion is pretty ingrained in some corporate cultures. Two possible responses are "The open-source community fixes bugs quickly" and "Since we have the source code, our engineers can fix bugs"--but that's often not what managers want to hear.
So, in essence, it depends on the company, their attitudes, and how much they trust you to make business-critical recommendations. I've used all of the arguments above with different levels of success in different companies.
Of course, in these economic times, the "free" part may go a long way. :-)
"Free software" doesn't necessarily mean your company is going to get software for free. Many successful open-source projects are also offered with licenses and services that cost real money and are geared to organizations that want or need to be assured of good support. MySQL is an example
The reason for a lot of big companies using closed software is that they can call support and the vendor will issue a hotfix, patch or cumulative update
Changing a large company's habits are often like turning an Oil tanker around... it takes a long time and uses a lot of energy.
If the company were in the process of evaluating the purchase of new software for a specific task, Then I would make sure to write a concise opinion memo about why my choice is better.
If the software is something I would use personally and not a server product that multiple developers are forced to use, then I would just ask my manager to use it.
If the software is in place, does the job (even if I don't like the way it does it), i'd learn as much as I can about it to give it as much chance of work for me, or at least make my life easier. If it still sucks really bad, I probably wouldn't try to change it until it was time for the company to pay for an upgrade.
If the software works but is just annoying... I'd do as above, learning all there is to know about it just to make my life easier and then deal with it.
You're probably right that the system you'd recommend is better than the one currently in place. But like some other posters said, choose your battles, especially when this is your first job out in the real world. You may become expendable quickly.
It's not really so much a matter of what's better, even if your way IS better, it's a matter of the culture and the way things are done and the cost of switching. Even if, hypothetically, their system can be magically transported to your OSS system, with no loss of data, dates, records, or anything, you're still going to have people who say "I liked the old way better."
Remember: Experience is what you get when you don't get what you want. I know it may sound glamorous to be "the new guy who recommended a great new versioning system that everybody loved", but you also could just as easily become "that hotshot who insisted on a new versioning system that everybody hated." It's a much smarter career move to just play by the rules at least for a little while until you have some clout and can make some recommendations. In the meantime you may even learn why the old system is preferred, or learn to like it more the more you use it.
I know what you mean. It took us years to convince our managers that everything would be okay if we moved away from using Interbase (a commercial Relational DB) to it's opensource counterpart Firebird. Mostly it was fear of no support that blocked the move. I think the factors which changed their mind were:
tests showing better performance
that there are companies that provide and charge for supporting the OS alternative
constant pushing of the argument by passionate developers
I think cost savings would have played a part if our company were paying for the site licenses but in fact our customers were.
I look at this question like this. I work with the .NET framework. I could ask my employer to migrate to PHP. This is a disadvantage to me, as well as my company, for many reasons. Let's start with the obvious.
1.) I know PHP, but can do much more, and a lot faster, with .NET.
2.) Paying for a service, usually ensures a better experience. The Visual Studio IDE is second to NONE when developing an application.
3.) I can develop an application much faster in VS than hard-coding PHP.
4.) This is the most important one. If I work with a big company, I want my programmers to develop my app faster, and I expect it to run faster. PHP (an example Open Source language) is fast, and reliable, but if I can spend the money, I'll deploy ASP.NET.
Basically, big business, or even small business, wants to spend their money, as long as it's for a good reason. Your best bet is to say, 'Hey, if you want to deploy ASP.NET (or whatever), send me for some training. Then I'll be able to develop OUR application to my best ability'.
not to sound totally cynical, but:
an experienced developer probably would not approach management about something like this, unless he/she was already an expert with the open source package. Companies like to have a phone number to call and someone to blame when things don't work. Free open source packages do not provide this kind of 'accountability' (yes we know it's a joke, but management doesn't)
it is unlikely that management is going to listen to someone fresh out of college about any major purchasing or technology decision. You have to learn the business and earn everyone's respect first. [sorry!]
Same problem everywhere. Once an organization gets beyond a certain size (e.g., the Dunbar number) it starts to show a certain woodenheaded quality that will confound you. Lots of history, people, agendas that you aren't aware of. And getting everyone to agree on your solution is difficult.
Best to start locally. See if you can persuade your manager or PM to use SVN or CVS or GIT locally for a project and then get it to diffuse.
But that situation is true where I work as well. I use SVN locally for myself, but a commercial product for integrating with others.
Companies will use whatever will ultimately make them the most money. That means whatever software will make their employees more productive. If there is a particular piece of open source software you think they should use then when the time comes to purchase the software to do job X then as long as you can prove it will make the employees more productive and they are able to get reliable support just a phone call away as with commercial software then they will use it.
Big companies need to hire support staff for stuff like that. When they purchase software from a company, they are guaranteed support with the contract. Open source projects can die off a lot easier, whereas a large software vendor can be held responsible for much greater periods of time.
Every company has a culture, and fighting the culture can be something of an uphill battle. But if you're willing to try:
you'll likely have more luck getting BSD and BSD-like projects approved (MIT license, Apache, Boost, etc.); and it doesn't matter if most of the arguments against GPL and LGPL are mainly FUD
you should refer to the projects as "royalty-free"
you should make sure things are approved by somebody that can approve them (your direct manager) because putting the company in a bind -- especially when you're new -- (even if the "bind" is only in their head) is not conducive to long-term employment
you can probably go a long way by simply asking what the procedure is to choose a library or tool
From a configuration management perspective, having developers add free software stuff willy nilly whenever they feel like is a serious PITA to manage.
I've worked at companies where you were allowed to do it whenever you wanted and others where you could never do it.
There's definitely a balance to be found but if you're in a larger company with multiple projects, you do have to keep in mind that each time you add a new 'tool' it complicates the build process.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does your work environment use Harvest SCM? I've used this now at two different locations and find it appalling. In one situation I wrote a conversion script so I could use CVS locally and then daily import changes to the Harvest system while I was sleeping. The corp was fanatic about using Harvest, despite 80% of the programmers crying for something different. It was needlessly complicated, slow and heavy. It is now a job requirement for me that Harvest is not in use where I work.
Has anyone else used Harvest before? What's your experience? As bad as mine? Did you employ other, different workarounds? Why is this product still purchased today?
I had the benefit of using Harvest at a bank and you'll never find a more wretched hive of scum and villainy, backwards triple-forking undocumented check-in gauntlets that require 15 steps to make one simple change. Nevermind that they weren't even using branching. This is an evil tool don't let it get you in its clutches.
Chances are, your company has some sort of contract with CA - are you using a lot of other CA software in-house?
Edit: Guess so!
OK I'm going to answer this in a couple of episodes because its late here and Harvest is a big topic.
Firstly CA Harvest (which is what version 7 of the product is called, version 5 is CCC which I cant recall the expansion, version 12 is called CA SCM) is a lot more than just a SCM tool - in the same way ClearCase is a lot more than an SCM tool. SVN, CVS, git, hg are all base-standard SCM and little more.
What you get with Harvest is SCM + Policy. It gives you a place to store and version your code and wrap it all in a policy of how that code matures though your organization from dev to prod. Do you have a policy in your organization that a Lead Developer needs to sign off on the code before its released to QA ? Harvest allows you define the signoff as a policy, and enforces it - you cant migrate the code from the "Dev" state to the "QA" state until one of the people in the project designated as a Lead Dev does exactly that. Do you have a policy that any SQL code needs signoff by a DBA before it progresses ? Harvest allows you to define that policy, and enforces it - so you might need both Lead Dev and DBA signoff before code migrates.
Harvest is by no means a tool for most software organizations - it is typically used in the finance industry, or in business' where a very strong regulatory framework governs what they can do. Banks need to comply with Sarbannes-Oxley, which has very strong auditing requirements. Harvest provides the ability to define all kinds of controls and process around how changes to the Banks assets move through their lifecycle. I know large public transport organizations that are responsible for the safety and punctuality of millions of people every day, that need the tightly defined control mechanisms that a tool like Harvest provides. I also have seen Harvest used in environments where 1000's of developers use it everyday - yes, I'm not exaggerating, literally 1000's of devs in one organization, writing code for a worldwide retailer, pushing IT solutions out their door everyday to the stores around the world.
Harvest is not perfect, thought version 12 is much better. It has too many "that's just stupid"-moments, it does per-file versioning ala CVS, and CVS-like branching and directory versioning (or lack thereof), with all the fun we've come to know and fear. Once you know it and accept it though, its isn't inherently slower than any other SCM I've used. It just has a bigger job to do than just version your code.
Another big win, and its even bigger with version 12, is its integration with other CA tool (and ability to integrate with non-CA tools, but not many at the moment) - defect tracking with Quality Centre, trouble ticketing with Unicentre Service Desk, software deployment to the desktop with SDM. You can define bridges between these apps that result in a lot tighter integration of these concerns, with the usually positive effects on accuracy and timeliness.
If your dealing with getting software out to a worldwide enterprise, with thousands of desktops and servers, mainfame/midrange/middleware systems, iron-clad change control processes, complexity, regulations, contracts, auditors, just a whole bunch of complexity, Harvest is just one tool in a whole suite of tools your going to need. If you just want a simple SCM for a team of 10 devs supporting a few hundred customers, its not a great way to go.
I'll try to add something about how Harvest actually works next time - repositories, projects, views, packages, forms, processes etc. That might help explain why some organizations use it, and why its not for everyone.
I used Harvest during a short gig in the banking industry a few years ago. I agree that it was practically unusable, but the people in charge of QA seemed to love it.
I worked for a company that had two choices; ClearCase or Harvest. Subversion hadn't ever been considered, and the reason was that ClearCase (IBM) and Harvest (CA) both had longstanding mainframe contracts already.
We've used Harvest for about ten years (2000-2010) and even though we are now looking at replacing it I believe it has served us very well.
Harvest (let's stick with that name even though it's no longer it's official name), was the first major tool we implemented to support us in R&D and at the time none uf us knew much about the many aspects of application lifecycle (versioning of code, branching, automated testing, regression testing, quality assurance, deployment to numerous runtime environments and production, rollback, ememrgency fixes, maintenance updates etc.); today we know a lot more and our development processes serve us very well (not that there is not room for many improvements).
We do not have a very hierarchical organisation (we don't have a lot of inspectors that need to approve changes) but it's very helpful to have support for "checkpoints" - points in the development process where something need to happen (e.g. functional testing or integration testing).
The drawback (for us) with Harvest in regards to usability has been "what a programmer need to do to change x lines of code". Today (out there) there are a lot of easier and more efficient ways than Harvest to get write access to source code files, make your updates and then return the files again / move them to another aspect of the development process (testing,deployment etc.). Another drawback is the price tag; it's expensive.
Gain we've had with Harvest:
It support workflow and therefore we've been able to have a single system to manage code versioning, workflow and process automation. If possible it's easier to maintain and improve a single system than many.
In addition to providing cmd line access to internal processes (making it possible to script special solutions when so required by your processes) Harvest also is easily configured by graphic interface.
It has the concept of "Package" which makes it easy to attach plenty of meta data to code changes and to handle the changes independently of other changes (versioning on file level rather than change sets containing the complete code mass). This is helpful to handle indpendent emergency and maintenance changes.
If a developer is only a programmer and only think on the coding aspect of software development then I imagen he/she would might get very frustrated with Harvest.
If a developer is a developer and understand that software development is a lot more than coding and that the coding is only the very begining of a the lifecycle of software then I belive he would see a lot of benefits with Harvest.
I have been using HARVEST for the last 4 years and i love it. The kind of support it gives you to control the code movement is really fantastic. We use HARVEST to deploy applications on to Websphere. It also do an amazing work in deploying the plugins into the web server along with the application. When you want to have a process in place for moving the code in a big enterprise environment, i don't think any other tool can even come closer to HARVEST.