When new interesting open source projects emerge, some of us hackers start scrutinizing it to see how it was built, how it managed to solve specific problems and how it approached issues like security, performance, etc. A debate, sometimes fierce, that arise every now and then, is about sticking or not with what is thought to be good practice.
Yesterday, if you happen to follow the same open source devs as I am on twitter, you might as well have lost a couple hours reading through a quite lively discussion about the choice of cryptography system to protect passwords, stored on Lamer News’ redis database. The core dev, Salvatore Sanfilipo, was trying to bring an educative discussion forward about the right system for the requirements, after being criticized for his early inappropriate simple solution – technically SHA-1 with a global salt. A lot of the people there were simply urging him to opt for what’s now considered as a good solution, namely bcrypt, without further development.
I think a part of the issue brought up can be approximated to this : A lot of people argue that projects should focus on the function they wish to provide, reusing proven libraries as much as possible, in order to simplify the work to just gluing them together. This is incredible about nowadays’ way of doing programming, and now tech businesses. Factoring out libraries usable by others and releasing them under an open source license is greatly valued today; programming stars rise and fall on github; the pace at which influential new projects are released is amazing.
Apart from the collaboration perspective, one perverse effect expressed by some community members can arise from this culture : Some people become dogmatic about the use of remote projects for solving problems, often quite specific to local constraints. Never should a library/database/template engine/[blank] be used in any serious project, without an thorough (and polite) debate – even just to oneself – on the available options.
As important to respect is the creativity of the developers, where a new solution might arise and later be factored out to a separate, open source project. This new solution might just be the perfect solution for the actual constraints and might become the next big thing. Even if that component is not directly targeted at the core function of the project, let’s not forget that programmers’ creativity is at the heart of today’s richness in software.