User:Duffy/FundamentalTheoremOfDevelopingFLOSS

(Image used under a Creative Commons Attribution-NonCommercial 2.5 License, credit: Randall Munroe, XKCD #1172)

(This is a work-in-progress. Corrections, insights, ideas are most welcome!)

1. Axiom of Previous Perfection: As soon as you release a major revamp of a piece of FLOSS software, the previous version will immediately become infalliable and perfect in every way to your user base.
   • Fan clubs for the previous version of your software may suddenly appear.
   • Any bugs or issues with the previous version of your software will be forgiven when the new major revamp is released, no matter how vehemently the very same users forgiving the bugs/issues argued about them previously.
   • Major change in your software may result in a fork to keep the candle burning on the previous version. These forks will likely die off due to lack of interest / time in maintaining them on the part of the forkers; they will definitely die by the time you've released your next major version / change.
2. Axiom of Assuming the Worst: In the absence of information, users assume the worst. You'll want to try to give them a heads up on major changes as best you can, with open and accessible communication.
   • However, when you provide information, most users will not read it, and will instead behave as if there is an absence of information.
3. Axiom of Ignoring the Source: While the entire point of free & open source software is that the source code is available, the vast majority of people using the software will not read the source.
   • Having the source means that there is absolutely no limit to what you can choose to do with the software. However, it's easier to whine in online forums, complaining that the developer has 'limited your freedom' or 'removed your choice' rather than actually exercising the freedom & choice you will always have to modify the source.
   • Those few who actually do read the source will complain that it is not written in the language of their choice.
     • These folks will not, however, fork the code and rewrite it in the language of their choice.
   • Those few who actually do read the source will often not pay attention to or read the license of your code.
4. Axiom of the UNIX Way: You will be told that all free & open source software must be developed "the UNIX way," but nobody's quite sure what exactly that means.
   • If you've made changes to the software that are unpopular, you will be told that you've violated this principle.
5. Axiom of Change and Choice: Think twice before ever adding a feature to a piece of FLOSS software. Only add a feature if there is no other way and you are absolutely, 100% sure that feature is in scope and needed.
   • If you ever need to remove that feature, you will experience a lifetime of pain from your userbase in the form of epithets about how Linux is about choice and removing features is not allowed.
   • For every possible feature and/or configuration switch, there exists a user who will demand it and insist that it's critical.
     • Nobody, however, will step up to test every possible combination of configuration settings.
6. Axiom of Laziness: Many eyes do make bugs shallow (hooray!), though many eyes don't fix or report bugs. It's easier to complain on twitter.
   • If you politely ask folks complaining about a bug or other issue on social media to file a bug, roughly 99% won't. Some will take the opportunity to yell at you for causing the problem.
7. Axiom of Security vs Usability: Always make clear the security story behind usability changes your make that may be interpreted as lowering security. Otherwise, 'you can't do that, it hurts security' will be the rallying cry for blocking your usability improvements.
8. Axiom of the Easy Way Out: The easy way out of making a decision when you're not sure of the right answer is to add another option - resist this urge. You'll need to keep that option forever and ever (see Principle of Change and Choice.)
9. Axiom of Mysterious Rejection: If you're not a core developer on the project, your contributions will be rejected for reasons you don't understand.
   • Treat this as a learning opportunity to discover why so that you may improve. Or, the committer might simply be a jerk ;)
10. Axiom of Tool Induction: According to some user there is always another tool you should have used instead of the one used.
11. Axiom of Celebrity: If any 'famous linux person' dislikes the change for any reason, then this will used as 'proof' that it is fundamentally flawed and evil, even if the aforementioned famous person's expertise is completely unrelated to the piece of software / feature in question.
12. Axiom of Universality: Every user believes their use case represents the majority view.
    • When a user says "Users want..." this means "I want..."
    • When a user says "We should..." this means "You should..."
13. Axiom of Resistance: For every possible change, there is at least one person who will complain loudly about it.
    • This includes changes that seem obviously correct, changes you haven't made yet, and changes you don't even plan on making.
14. pjones' Axiom: If they're complaining you haven't done it, it's a bug; if they're complaining you're going to do it, it's a feature.
15. Axiom of Health: The longer you spent time reading mailing list, forum, and blog discussions about FLOSS technical decisions, the more your blood pressure will increase. Please discuss with your doctor.