Engineering laws

• Zawinski's law of software envelopment: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."

• An updated version of Zawinski's law: "Every mobile app attempts to expand until it includes chat. Those applications which do not are replaced by ones which can."

• Sturgeon's law: "Ninety percent of everything is crap."

• Atwood's law: "any application that can be written in JavaScript, will eventually be written in JavaScript."

• Linus's law: "given enough eyeballs, all bugs are shallow"; or more formally: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone."

• (Gabor Szarnyas) My conjecture: When using an open-source software project, you soon encounter a problem that will have an elegant, out-of-the-box solution in one of the project's future releases. This is usually promised in the roadmap of the projects or just mentioned casually on the issue ticket that you found.

  I recommend to read Chapter 3, Section 2.2 of the How to be a programmer book, "How to Manage Third-Party Software Risks":

  A project often depends on software produced by organizations that it does not control. There are great risks associated with third party software that must be recognized by everyone involved. Never, ever, rest any hopes on vapor. Vapor is any alleged software that has been promised but is not yet available. This is the surest way to go out of business. It is unwise to be merely skeptical of a software company's promise to release a certain product with a certain feature at a certain date; it is far wiser to ignore it completely and forget you ever heard it. Never let it be written down in any documents used by your company.