Self-Taught Software Engineers: Why Open Source Is Important to Us
medium.com
medium.com
This seems a bit like his early attempts to sell free Ubuntu discs. Hopefully he got the wording slightly wrong and forked it instead of starting a brand new repository with no attribution.
And frankly the article is so relevant to current goings on in the FOSS world that it hurts reading it.
Initially, Stallman made a living selling GNU tapes, and pre-Internet, linux was often installed by a "friend" who made the stack of 40 floppies and charged a few bucks to cover his time and media expenses.
In many parts of the world claiming to be an engineer (in a professional capacity) without the required qualifications opens you (and your employer) up to all sorts of liability issues.
I am a Materials Engineer I've long suspected the software engineer title is not regulated anywhere near as heavily.
But... I don't call myself a materials engineer, which probably has some sort of licensing or regulation, no?
This whole line of thinking doesn't really apply to software development. Formal qualifications are, at best, only required to get you a first interview. Formal software development qualifications are generally regarded as being only tangentially related to the ability to do the job.
I'd always presumed there were similar requirements (i.e open source licenses often disclaim liability for code released under them)
Not sure. I have personally never heard of it but that is hardly conclusive.
Its not the kind of job where individuals are out making decisions on their own as a rule. Particularly at established companies people's work likely has to pass assorted automated tests and rounds of human review and testing. And then the companies software is wrapped in extremely carefully worded licences and contracts to limit liability.
Also bear in mind that software is typically produced behind closed doors. The external users of the software likely have no idea as to the identities of the humans producing the software they use. You would never know if someone incompetent was hired (assuming their poor quality work somehow got released) because you don't know if the software is being produced by 1 or 100 humans.
Most licenses disclaim liability.
99% of all software comes with an end-user license agreement saying “we aren’t liable for anything that’s gonna happen to you because of our software”. Also, EULAs sometimes (like in MS Windows) forbid usage of the software in safety-critical applications, defined as “device or system in which a malfunction of the software would result in foreseeable risk of injury or death to any person”
Other 1% of the software, legal teams underperformed and were unable to press public enough to accept similar agreements. So, in automotive, avionics and especially medical devices, users sometimes indeed sue manufacturers over faulty software. However, I’ve never heard about a process for hiring someone incompetent. People usually bring claims against companies for making a defective product, asking for compensation.
It sounds unlikely that employee school papers would be the deciding factor though.
[1] https://en.wikipedia.org/wiki/Software_engineer#Regulatory_c...
I'm better than lots of people I've met with the degree but I don't want people to infer that I have a degree from that convention.
It can be a big difference if the library author allows contributions much-much easier to make.
Some have overview of their source code and their design principles (like Redis) but many don't.
Some have good documentation of how to get your patches in main tree but many (especially those not hosted on github) don't have it.
Most notably for C/C++ projects, the undocumented dependencies to build the library can waste hours at a time.
Open source is great (I have contributed to a couple of projects) but not all projects are equal in terms of quality/easy-to-hack.
Brad Fitzpatrick has also written quite a bit about this http://brad.livejournal.com/2409049.html