Development Philosophy

Contributing to Software (Libre) Projects can sometimes be daunting for two reasons. Firstly, there is the fact that Free Software is publicly accessible, and it is often a big psychological step to move from a private world where no-one will see or be able to "criticise" or even praise what you are doing. Secondly, a high-profile project can end up with hundreds of thousands of users, and the responsibility can be considered enormous.

This however is not an excuse for not following good development practices! Far from it: it is even more important to work with others, and to erase all considerations, whether good or bad, of "ego". Pride has a positive place in seeing the end results - achieving the goal - through to fruition; pride does not have a place in claiming ownership and being used to prevent and prohibit others from benefitting from or helping with what you are working on.

Neither does fear have a place. "I'm afraid of what others might think so I am not going to release this code until it is completed" is quite possibly the worst cardinal sin of all! It means that nobody else can contribute or help; it means that if you get hit by a bus everyone who was depending on your work has to start again;

With that in mind, here are some development guidelines that we aim for in all the Rhombus Tech Initiative work, whether it be hardware, software or documentation.

  • Little-ego-driven thinking have no place in this project! Little-ego is, in zen and buddhist philosophy, the bit of our mind that applies "worries" to our thinking (there is a rather waffly description here, but there is an even better example here). In essence: if you find yourself considering holding back from a commit, or if you are considering working only in private, and not with others, or to only release code or a hardware design "when it is ready", please don't!

  • Look up, and follow, the concept of "egoless programming", as applied right across the board. As a general rule, use phrases such as "the code" not "your code"; "the image" not "your image", or "the image which fred made", rather than "fred's image".

  • If you are using phrases such as "your code" then it means that we now have to be careful when pointing out any flaws in your work, because people who use the phrase "your code" typically confuse criticism of "the code" with criticism of the person, without even realising it. This is the real underlying reason why most Free Software Projects have a policy of requesting that everyone be "polite" to each other. However, "polite" doesn't nearly go far enough, as it becomes difficult (like "walking on eggshells" difficult) to tell someone that they are making a mistake if they confuse "self" with "code". If on the other hand, everyone is confident enough in themselves to recognise that criticism of code is not criticism of the person, then the most amazing spark-ridden bun-fights over strategic design can take place, and nobody feels even remotely offended.

  • Everything is to be documented on the wiki, even if it means using the wiki for note-taking. Discussion takes place on the mailing list or the IRC channel, but it should always be to point back to a suitable wiki page.

  • Everything reasonable is to be published, even during its development. Code, documentation, hardware designs: everything. The reason is simple: if you quit, others can take over. If you didn't publish it, your efforts are completely wasted: others must now duplicate it.

  • Decide the goal, then get something working first that is reasonably close, and then modify it to move closer towards the goal, in incremental steps.

  • When a goal is met, be happy that the goal has been met, and celebrate it if you feel so inclined, but then move on to the next goal. Even if that goal is not to contribute further to the aims of Rhombus Tech but to some other project.

  • Achieving the goal is paramount: everything else is secondary. It might not be "fun" to have to throw away years of work; it might not be "fun" to be told "that's the wrong coding decision". You may have different expectations of what the goal is, but if you believe that the goal is "To get results but also to make yourself look good in the eyes of users or other Free Software Developers", you are in for a bit of a culture shock (even on other Free Software Projects, not just this one).

  • Look after yourself, and enjoy contributing, even though the above may look daunting! If you believe in God, then you know that it all belongs to God anyway; if you do not believe in God, then you owe it to yourself to set the priority of enjoying what you are doing (first), and to enjoy contributing to this project (second).

Abridged Discussion on arm-netbooks mailing list

A discussion took place in May 2012 and it was suggested to create a Design Philosophy page. Here is an abridged version of what was posted:

example: consider - using the 2.6.36 kernel initially, and the version of u-boot that is known to work, and downloading pre-existing armhf debian packages known to be working, proving that it all works.... AND THEN AND ONLY THEN trying the 3.0 or 3.3 kernel, and THEN AND ONLY THEN trying a new version of u-boot, and THEN AND ONLY THEN trying some alternative package compilations, tricks, combinations and so on.

in other words, start from a known easy-to-achieve but above-all absolute paramount and ultra-high-priority working system, regardless of whether it is the required actual ultimate goal, and then change one and ONLY one component or item at a time.

and - most importantly - RELEASE IT! make it publicly available! preferably as you're actually going along, rather than "oh i'll release it when it's ready" (*1)

then, if the "component" selected - the change required - turns out to not work, or is too much to do, then the action that can be taken is:

a) give up. this is not an unreasonable option. it's not a failure (*2). at least, however, someone else can take over because you released everything publicly.

b) ask for help. this again is not an unreasonable option: someone else might have more expertise than you. it is NOT a failure or a threat to your ego if you ask for help.

c) try a smaller incremental step. this again is perfectly reasonable: yes you couldn't get xyz working but so what - if you try just x or just y or just z or even w you might get a little bit further.

(1) this attitude absolutely drives me nuts: it means *you want "all the glory", or your ego is in the way - fear of criticism - which is just as bad. don't do it! work publicly, and openly invite others to collaborate with you!

(*2) however if you didn't release everything publicly, you just pissed everyone off by forcing them to duplicate all the effort that you did go to.