The biggest SoftwareLies:

	* ''Of course'' we will give you a copy of the SourceCode.

	* ''Of course'' the third party vendor we bought that from will fix the microcode.

	* Beta test site? No, ''of course'' you're not a beta test site.

	* ''Of course'' it will work, be feature complete, on budget, on time.

	* ''Of course'' you'll get technical support.

	* ''Of course'' if you document everything, your software will be perfect, the world will be perfect, you'll cure cancer...

	* ''Of course'' we know what we're doing.

	* ''Of course'' this system will be of value to you.

	* ''Of course'' we'll give you an easy upgrade path.

	* ''Of course'' it is 100% compatible.

	* Write once, run everywhere.

	* ''Of course'' we are open source. (Translation: "You open up, we take your source.")

	* There are no problems.

	* You are the first customer reporting this problem.

	* ''Of course'' we will fix all these issues before delivery.

	* Installation, administration, and maintenance of this product are easy.  It's self-administering and self-healing.

	* ''Of course'' it is fully compliant with all applicable standards.

	* Yes, I know, no, it's not a bug, it's ''supposed'' to do that. Honestly. We wrote it that way.

----

Most of these statements are usually lies. But I was taken aback by the first statement, which is usually true. Giving source is easy. If the contract says that the developers will give a tar file from which you can build the application, why would anyone expect it to be a lie? Am I missing something?

''I agree that it is generally not a lie - I didn't understand that either. But distributing source is not always easy:''
	* ''The build process may rely on a highly customized configuration or not-generally-available tools, making the source files useless to anyone other than the developer. Documenting the build process, or making the build process "bulletproof" so that it will work on other machines, may be expensive.''
	* ''The source may include intellectual property licensed from another vendor, which the developer is not allowed to redistribute to the customer.''
	* ''The source may contain trade secrets that the developer does not want to share.''
	* ''The source may contain features that apply to multiple customers, and it would not be appropriate for one customer to see what other customers are doing.''
	* ''It may be difficult to identify the exact versions of all the sources that were used to build a particular version of the software.''
	* ''The process of gathering all the sources can be expensive.''
	* ''The source may be so ugly that the developer is ashamed to let anyone else see it.''
''So, while distributing source may be required and expected, it's not easy and so the developer may try to avoid doing it, or may do a half-assed job of it.''

Once upon a time, a sister company to the one I was in was clearly intending to take our source, split off, and compete with us. (We had enough documentation on this to win the lawsuit that ultimately occurred.) We were required to send them the source. So we converted all the names to Annnnn, stripped all the comments, and most of the carriage returns. So there's another angle on "of course you can have the source code".

''A company called Gimpel Lint did this - you got compilable source, with totally cryptic identifiers, etc. No sane way to modify it, but they didn't need to deal with your particular build environment.''

-----
Some more ways to not give you the source:

	* The source code comes with pre-built intermediate and executable binary files. Unfortunately, nobody notices that for one or two binary files there's no corresponding source code. Guess where the core logic of the program lies? This happens with a few Linux device drivers - the source code is actually a Windows NT .lib file loader, which loads a hacked-up Windows NT device driver distributed with the source code.
	* The "source code" is the output of a compiler of a different programming language. This happened with a Modula-3 compiler I once had the pleasure of using - lots of machine-generated C code, generated from the Modula-3 source code that the vendor was not distributing. I could not collect more than 10 lines of such code without encountering system-specific integer constants.
	* The source code is so non-portable that it does not compile (or sometimes even ''run'') on a nearly identical copy of the developer's machine, much less a customer's arbitrary choice of system.
	* The vendor might not ''have'' the source code any more. Occurs in single-developer situations where there's none of the usual IT niceties such as revision control, data backups, etc., or disgruntled employees and sabotage.
----
CategorySoftwarePolitics CategoryBusiness