In software development, a neutral build is a build that reflects the current state of the source code checked into the source code version control system by the developers, but without any developer-specific changes.
A nightly build is a neutral build that takes place automatically. These typically take place when no one is likely to be working in the office so that there are no changes to the source code during the build. The results of the build are inspected by the arriving programmers, who generally place a priority on ensuring the recent changes to the source code have not broken the build process or functionality of the software.
When someone says a developer "broke the build", they are effectively saying that a developer checked in code which might very well have compiled (and hopefully also run properly) in their account, but does not compile (and therefore, cannot be run) in anyone else's account. This is typically due to additional developer-specific changes that were either not checked in, or (in the case of environment variables, etc.) were modifications to systems not under revision control. One of the most common cases is remembering to check in all modified files, but forgetting to add newly created files to the repository. If the other developers check out the new code without being aware of the problem, their work may grind to a halt while they wait for the problem to be fixed (or try to fix it themselves, which can be even more problematic, if multiple developers attempt to fix the issue at the same time). This naturally can result in a significant loss of productivity.
Neutral builds are important for software development processes running at high loads with short schedules; not having them means that any build that needs to be created for the Software Quality Assurance department has to be created using code which may be in the middle of major modifications, and which would best be left out of a build for testing (particularly a build being evaluated for possible release).
Neutral builds can be done on a machine which is also used for active development if enough caution is taken, but it is safer to dedicate a machine to that purpose because an issue in the build process could cause the machine to become unstable.
iPhone 5 (Sep '12 to now)
iOS 7, jailbroken
Nexus 4 (June '13 to July '13)
Android 4.2.2, root
iPhone 4S (Jan '12 to Sep '12)
Nexus One (Jan '10 to Jan '12)
Samsung Omnia SGH-i900 (Dec '09 to Jan '10)
Windows Mobile 6.1
LG KM900 Arena (Apr '09 to Nov '09)
Sony Ericsson W880i (mid '09)
Sony Ericsson W810i (Nov '07 to Apr '09)
Siemens MC60 (? to Nov '07)
Nokia 3410 ('04 to ?)