The open source paradox (2020)
antirez.com
antirez.com
But it was not always so.
In recent history "professional" indicated that the task was bounded by time, and thus constrained in quality. An amateur building say a clock could take unbounded time, and hence create a superior product whereas a professional had to sell the clock, so it had to be produced in affordable time.
John Harrison starts life as a carpenter, making some clocks on the side as a hobby, interested more in perfecting the concept of clock than selling clocks for money. (although he had a prize in sight for inventing an accurate nautical clock.)
Despite making only a handful of clocks in his life, he's credited as being the most important clock maker ever.
Thus it is with OSS. Given the lack of monetary benefit, the benefits of writing it have to be elsewhere. In the satisfaction of a job done well. In the beauty and elegance of the code. The timeless perfection.
Or the idea that OSS presence will look good on your CV and held get you that job. In which case just throw stuff at Github to make a "portfolio". Never to be looked at again.
I think it's safe to say that the majority of OSS is the later, but we are all better off for the fraction that is the former.
As examples I would like to call out ffmpeg and x264. Years of refining and refining make it software of a quality that didn't exist before in the world of codecs.
"Hobbyist", on the other hand, feels both knowledgeable and at the same time homely, unthreatening, to me (see synonyms[2]). I don't like talking about my JS library on GitHub[3] as a "side project" (a phrase I think many people would interpret as: "something that may one day make some good money"). Rather, I think about it as one of my hobbies, something I do because the work both fascinates and pleases me, allows me to experiment and push boundaries of what's possible to do with a 2d canvas element in the browser without the need to meet the demands and constraints of employers, clients, time, etc.
One of my other hobbies is writing poetry, which probably explains why I care too much about the meanings of words ...
[1] - https://www.thesaurus.com/browse/amateur
A certain distance has opened up in modernity. It is between what is accounted for and what is casual. Between the formal and the informal. Official, and unofficial. It is about what it "recognised" ... by whom?
Paradoxically, this age in which everything must be measured, approved, certified and stamped, has made the amateur-professional distinction more about the rituals and symbols of quality rather than measurable quality.
My bachelors degree in CS&EE meant reading about 12 books, plus validation through a gauntlet of examinations. For my troubles I got a nice certificate and 40 years of salary increase. The reality is that I read two dozen other books in my spare time as a teenager, just for fun and interest, and received no degree for them. Since then I've read many hundreds of books in my life, on philosophy, law, psychology, politics and other subjects. No degrees.
Out of love, I've paid more attention, taken better notes and more deeply considered those subjects than I did in the brief 3 years upon which my credentialled career is predicated.
Interestingly a doctor, lawyer or professional politician [1] is as free to write code on which a billion people depend as I, yet I cannot practice law, treat patients or have much of a say in how my society is run [2] - not that I'd be any good at those things.
Professionalism seems as much about money as it is about how society, including its incumbent elites and class structures, select who is "recognised", who gets to bestow the blessings, and ultimately to control produce and behaviour.
While in the army many young lads, whose "heart isn't really in it", are technically "professional soldiers". They hang up their boots after the first tour. Only the crazy ones who become "contractors" (mercenaries) might be said to have the truest instinct for it.
Software has carved out a very unusual niche this past 50 years. It's a mercenary game, so complex and difficult that a genuine meritocracy ensues, one that cannot be ignored or papered over with accolades or associations. Either your code works or it doesn't.
But that unregulated laissez faire has also created a brutal world in which becoming a "professional" coder is certainly the best way to kill any fun and love for it. Meanwhile many well paid, hard working lawyers and doctors hold on to the love for their work.
So I think "professionalism" and the identity, recognition, provision and protections it can offer makes for some very interesting distinctions.
[1] Should we even have "professional" politicians?
[2] Voting in a race between two idiots doesn't count.
I'm not sure about it. it's more about the behaviour you display. If you want a secure job it's better to display servitude and finish your degree even if you would make more progress on your own. When you want to become an artist or entrepreneur it is better to display a strong will, risk taking & inability for submission which sometimes means to drop out and follow your own thing.
I truly believe that if you want to get to the top you need to leave the path most people take with the risk to land at the very bottom.
I don't think complexity automatically breeds meritocracy, and I don't think software is a meritocracy. There's still a "human side" of things that may drown out true merit.
For example my first OSS project went something like this: I wrote something from scratch with thousands of lines of code and put it out under the GPL. I told my friend about it. My friend forked the project, wrote only a handful of lines of code of his own, and did a better job at advertising his fork than I did on mine. The result was that he basically stole control over the OSS project from me by doing a better job as a marketer rather than as a programmer. ...nothing meritocratic about that.
One thing that has happened to me quite a lot working in commercial environments. Me: "Hey boss, I see your team is trying to tackle problem X with solution Y which doesn't take into account complexity Z. Let me solve that for you." Boss: "Okay, explain complexity Z to me." Me: "Yadda, yadda, yadda, ..." Boss: "I don't understand. It must be because you're a bad communicator." Me: "It may be because I'm smarter than you, and, as a corollary, you're dumber than I. Throw in some Dunning-Kruger effect." Boss: "I'm not dumb, you're dumb, and whenever I let you near any complex problem, you end up making me feel dumb. I don't like feeling that way. Go write some HTML, where I don't end up feeling that way as I go about micromanaging you."
They really don't. Professional work life, or, any field to which you enter to work for money, is as difficult as the other. Software is not an exception.
It has more to do with our current economic system (capitalism) trying to get the maximum profit out of everybody and overworking them than the specificities of any field.
In modern times it is usually assumed that an amartur has a real job and can only devote so much time to their hobbies.
- People too young to be in employment.
- People too old to be in employment.
- People with illnesses or disabilities that make employment difficult or impossible.
- People who don't have skills that anyone wants to pay them for.
These people are not aristocrats, for sure, but most of them will not be highly effective working for love as opposed to working for money.
Also, being poor can be exhausting. Someone who isn't employed and isn't an aristocrat is likely to have a lot of their mental energy taken up with surviving, which again is likely to make them less able to do wonderful things working for love.
Important note: of course all the above is "most", "likely", etc.; there will be exceptions. Some school-age people are geniuses. Some retired people still have plenty of energy and focus. Some people have illnesses or disabilities that make ordinary jobs impossible but can still do great things if they can do the work on their own time and on their own terms. Some people have skills that others would pay them for if the others had any sense but for whatever reason don't sell themselves well. Etc., etc., etc. But, proportionally, there are going to be fewer people suited to create great things while not employed among that 42% than among the aristocrats of an earlier age. (Or of this age.)
Another important note: Of course the starving artist or writer is something of a cliche, so it was never all aristocrats who were creating great things outside the constraints of paid employment.
- People who are doing unpaid care work (e.g. for children, or sick relatives)
There is a difference between being given an island by the king to build your own astronomical observatory in the 1600s [1] and knowing that you don't have to worry about food and shelter for the next few years because of your well-placed long-term investments. In this sense, the very few amateurs left today are the billionaires funding their own space agencies and whatever else they fancy.
[1] https://en.wikipedia.org/wiki/Tycho_Brahe#:~:text=King%20Fre...
[1] "Gellius appears to have feared that Tycho wanted to keep him on Hven 'working like a slave.'", 1991, Victor E. Thoren, The Lord of Uraniborg. A Biography of Tycho Brahe, Cambridge University Press, p. 357
[2] ibid., p. 193
This is probably true if your amateur project is building a rocket to go to Mars, but not true for the vast majority of independently-pursued projects of art, craft, design and engineering.
As these working class clubs started to become increasingly successful, the governing rugby body which was dominated by the private schools insisted that players are amateurs. The conflict escalated to the working class clubs splitting of to form a different code of rugby (rugby league). The classism behind the split is still causes animosity behind the different supporters in the UK (it is less so in e.g. NZ were rugby was never a rich kids sport).
You can read more here https://www.newstatesman.com/culture/sport/2019/10/split-bet...
or, more realistically and less rose tintedly, people want to implement a functionality for their personal use case and hack together some code and libraries to get it done as quickly as possible
Whoever has ever done something knows that you can help someone more with a messy project that does something than a near-perfect codebase that does nothing of value. And you publish something to help someone else!
A personal project can be done to achieve something or to aim for that illusive perfection we can never achieve at work (or both, ofc: it's not a XOR). Neither is to be discounted!
Being a professional implies that you will deliver a minimum standard of quality and consistency to your customers, because you as a professional are demanding money for your work. Amateur work by comparison can be all over the place, ranging from the mindblowing to the putrid, with no guarantees.
The flipside of this is that the only qualification to be a professional is whether you make money with your work. No matter how skilled or knowledgable you are, you aren't a professional if you can't successfully demand or aren't demanding money for your work.
So true. And professionals can range from "mindblowing to the putrid, with no guarantees" too. In fact, I'd say they are able to achieve a far greater level of putrid than non-professionals, "amateurs".
> An amateur is generally considered a person who pursues an avocation independent from their source of income. Amateurs and their pursuits are also described as popular, informal, self-taught, user-generated, DIY, and hobbyist.
That does describe much of the open source world.
But great work has come from amateurs. Ah, Wikipedia has a wonderful description of this.
> Contribution of amateurs
> Many amateurs make valuable contributions in the field of computer programming through the open source movement.
> Amateur dramatics is the performance of plays or musical theater, often to high standards, but lacking the budgets of professional West End or Broadway performances.
> Astronomy, chemistry, history, linguistics, and the natural sciences are among the fields that have benefited from the activities of amateurs. Gregor Mendel was an amateur scientist who never held a position in his field of study. Radio astronomy was founded by Grote Reber, an amateur radio operator. Radio itself was greatly advanced by Guglielmo Marconi, a young Italian gentleman who started out by tinkering with a coherer and a spark coil as an amateur electrician. Pierre de Fermat was a highly influential mathematician whose primary vocation was law.
> In the 2000s and 2010s, the distinction between amateur and professional has become increasingly blurred, especially in areas such as computer programming, music and astronomy. The term amateur professionalism, or pro-am, is used to describe these activities.
Which, on top of the aforementioned resources limitation, means client agency and a lots of time spent marketing and selling... Many amateurs are experts who just don't want to deal with the commercial relationship.
> Or the idea that OSS presence will look good on your CV and held get you that job. In which case just throw stuff at Github to make a "portfolio". Never to be looked at again.
> I think it's safe to say that the majority of OSS is the later, but we are all better off for the fraction that is the former.
In my case, it's the former, but the latter happens to be a byproduct.
The analogy that I use, when someone asks me why I do what I do, is thus:
Think of me as the old Swiss geek, making cuckoo clocks in his basement.
I like making cuckoo clocks. Like, a lot.
Cuckoo clocks aren't everyone's cup of tea, and that's fine with me. They are my cup of tea, and that's what matters to me.
It's my goal to make the best damn cuckoo clocks available. I hang them all over my house. Every hour on the hour sounds like a Munich Beer Hall band.
If you want a cuckoo clock, I'm your man.
If you don't, that's fine. I don't lose any sleep over it.
I guess they are saying that both bug reporters and open source maintainers care about software quality (generally excluding learning projects and research prototypes and the like).
No shit. I don't think anyone has ever disputed that.
In the open source world we generally say that users are not entitled to anything. They get what we feel like giving, because they are not paying us.
This is just as true in the corporate world. If your manager tells you to do X, and some random on twitter wants you to fix bug Y, you do X not Y. The random on twitter probably cares about software quality too. That has no bearing on you probably ignoring them.
Are there any good ways to convert those who comment/suggest into contributors? I feel like instead of simply dismissing suggestions with "you get what you paid for", there must be a better way to handle the situation. Or perhaps I'm too naive on the topic
most of the time when i d̶r̶o̶p̶/contribute a suggestion as a user then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and contribute a patch.
and for those who don't know how, most likely the idea they had is more complex than they would be able to do as a first project, even if they were willing to learn. they are better off contributing in other areas that match their skill-level or enable them to learn. but how to motivate them to work on something that does not relate to their suggestion? maybe by arguing that if they help with those beginner tasks over there, then someone else can find the time to work on their idea, but it feels risky to make that kind of promise.
so i would rather focus on those who say they want to contribute something but don't know what because they feel they don't have the skill. those are hopefully motivated to learn. point them to issues that are suitable for people starting out.
and for anyone else: thank you for the suggestion. patches for this idea are welcome. (and optionally) feel free to ask for pointers how to get started.
That is true, but there are also other issues, such as:
- Knowing most of what to write, but possibly missing some part of the code that you might not know of, which is needed to implement this feature.
They might not accept the change, leading to further things below:
- Possibility of breaking the interface and making it not compatible, especially with future versions of the official program if there are bit fields, structures, enumerations, etc that need to be extended.
- Needing to maintain your own fork of the project.
- If making multiple patches, making them to not interfere with each other.
I had made a repository of unofficial patches of SQLite; currently only contains my own patch for non-Unicode, and list of links to a few others. However, later I should perhaps add also such things as documents about enumerations, etc. Depending what needs to be done, possibly forking it and breaking the interface might have some advantages (can avoid some problems with the existing interface), but also disadvantages (more complicated to maintain).
> most of the time when i drop a suggestion then it's because it's a good idea but not a priority and i don't have the time to implement it, or rather it's not important enough for me to make the time and produce a patch.
I had considered this, and I think that you can specify reasons for dropping a suggestion, as well as details of what might be needed even if it is accepted but not implemented yet. As an example, I had made this list:
0. It already has this feature, or this capability can be easily done by the existing features.
1. Yes, I will likely add it soon (and may be working on it already).
2. Yes, but it is not a high priority; it may be added later.
3. Yes, but more work will be needed before it is added.
4. Probably; more work will be needed, and/or design decisions must be made, before it is added.
5. Maybe, but I am unlikely to implement it by myself; if you provide a patch then it will likely be added.
6. Unlikely, but possible. More work will be needed, and I probably will not add it by myself but a patch may be acceptable.
7. No, I consider it to be a bad idea. You may make your own fork of the project if you want it, though.
8. No, it is out of the scope of the intended project. You may make your own fork of the project if you want it.
9. No, it is probably too complicated and not very helpful anyways.
10. No, it is probably impossible. Forking it probably won't help.
11. The request is completely impossible; in addition to being impossible, it might also be incoherent, incomprehensible, unethical, etc.
In the case of bug fixes, it is a bit different, e.g. if you cannot figure out what is wrong, or if you do know what is wrong but you do not know how to fix it, etc.
Since last year, I began reading the code of popular open source projects I use in order to determine the source of a problem I was having, and a lot of those times ended up as bug reports.
I now take the time to explain my whole reasoning into finding the bug and linking appropriate code snippets, but I'm still a bit afraid to start a PR on my own to fix it.
Since I did so on popular projects, with lots of issues/PR about half of them got ignored, or responded to a year later saying "not applicable to latest version".
That demotivates me a little about starting simple bug fixing PRs for big projects.
PRs that get ignored is really demotivating. It can depend on which project a lot. If you're new to the project informally (and politely) chatting about your patch on project's irc/discord can help ensure you are not missing any social conventions.
when you fix a problem consider first of all, to do it for yourself. for your experience, or to solve a problem that you actually have.
fixing a problem and then finding out that it is already fixed, or that someone elses later fix was accepted ignoring yours, is also a common experience. there is nothing malicious about it. communication is just not perfect, and for some things, it may just be easier for the known and trusted developers to fix a problem themselves rather than to take the effort to review your contribution, even though taking care of your contribution would give them the opportunity to invite a new contributor. not every project has inviting new contributors on their radar.
my suggestion would be to look at projects that have an explicit policy of being welcoming to new contributors. they will either say on their site or in the documentation, or they have issues that are marked "good for beginners" "or good for a first contribution" or something similar.
work on such issues. join the community, their mailinglists, chat rooms, or whatever they use, and talk to other developers there. get to know the people, help other new contributors, make friends. later when one of your submissions is ignored or overlooked again, those new friends will be able to help you get attention to it. or they may know why it was ignored.
Three years away from having a degree. If you routinely do software engineering, you're a software engineering (possibly s/engineer/develop/ for a similar claim.)
> Since last year, I began reading the code of popular open source projects I use in order to determine the source of a problem I was having, and a lot of those times ended up as bug reports.
You are a saint! I would _love_ for people to read through my code looking for bugs and oddities.
Just remember that some FOSS projects are coded well, while others are coded horrendously.
> I now take the time to explain my whole reasoning into finding the bug and linking appropriate code snippets, but I'm still a bit afraid to start a PR on my own to fix it. > > Since I did so on popular projects, with lots of issues/PR about half of them got ignored, or responded to a year later saying "not applicable to latest version".
If you are considering writing a PR, get in touch with developers in a chatroom, or even over email, to coordinate this. They are likely to respond favorably to offers of PRs, and tell you things like "Don't do it now, we have a refactor coming up" or "base yourself off of this branch". And even if they say "not interested, don't bother" - you've still gotten useful information from them.
People who make good faith suggestions can sometimes be converted, but you also have to respect that some people don't have the inclination or time but can still make good suggestions. Sort of similar to how on an internet forum most people are lurkers and that is ok. Good faith suggestions are really valuable to open source projects.
Further, what, precisely, is the paradox? The unfounded assertion that quality exists only in absence of compensation?
Even if you're Free and Open Source, you're injecting code and ideas into a community. By making that public (and intended for wide use) you are opening up for criticism from anybody to say "I think your software is bad and you should stop promoting it." That's just free speech 101.
if the software is bad, don't use it. if it is dangerous (you could loose work when you use it) then be explicit about the danger. "your software is bad" is a rather useless criticism. tell me why. tell me which alternative is better. tell me what would make my software better. but don't just tell me to stop promoting it, because that is not your place to say.
But, here's the thing in my experience. I might believe believe your software is "bad to the point of harming the ecosystem" (which I do feel about e.g. Wayland, I think they haven't done a good enough job of preserving backward-compatibility, YMMV)
At this stage, it is absolutely my place to say. And very frequently what happens is they put up arguments like yours, even when I have been explicit about the danger, which I do good-faith believe is real enough to get very critical about.
that is the challenge in every human interaction. sometimes it is difficult to tell how a message comes across. if it isn't well received, the best one can do is to back up, apologize that the message didn't come across the way it was meant to and try restating the problem in a different way.
and if that doesn't work, keep trying or give up. some people are just not open to any form of criticism, and the best one can do is to try to be polite and state the problem in neutral terms to anyone who needs to hear it.
Places like this; I don't argue with individuals primarily to privately change their minds. I argue "in public" to get the debate out there and perhaps change the minds of the other readers.
i like to go by this: try to avoid offending anyone with what i say, but also try to not get offended by what others say.
if someone is offended, it could be something that was a trigger, or some misunderstanding, or that person is just to easily offended or there is some deeper issue that i am not aware of.
either way, there is a failure in communication, and if i want to continue the conversation, i need to find away around it. in most cases an apology is a way to do that. not doing anything about the offense assumes that the other person knows that their taking offense is unwarranted. but i believe many don't, or they wouldn't have taken offense.
if the person is reasonable, they will accept the apology and be able to calm down and the discussion can continue. if they are not, the conversation is most likely over, or it escalates. both are things i'd rather avoid.
I didn't have to develop a new computer music for a musicology phd and my scholarship was just for a humanity thesis, but I just wanted to do it.
In recent memory I cannot think of any serious open-source software that doesn't have individuals from well-paying tech companies contributing to it in significant ways. These projects are usually of higher quality and are done in the spirit of the open-source ethos - everything is done in the open with open governance etc. Usually expectation is everyone contributes and gets a lot of value for a lot less effort due to the collective effort.
Then, there's a long tail of unpaid software that's put out in GitHub etc. whose quality is highly suspect. They are done as a hobby of an individual, may not even have a proper project community structure (website, mailing list, seeking contributors etc).
Then, there's another category of open-source – these are commercial ventures that want to garner the goodwill associated with open-source model/movement to further the adoption of their commercial offering. Nothing wrong with it, as long as they are honest about it. They are different in some fundamental ways. They intend to control the fate of the project very tightly and privately and there is no open governance of the project. Entirety of the project may not be open-source. Big chunks of the critical functionality may be closed source. At some point they may change the open-source license of the project to make it more onerous.
Some of the best open-source software that I have seen that do both open-source and commercial parts really really well are sqlite, haproxy, nginx.
Because they are popular, people pay and contribute to popular things. Many become popular before they have paying patrons, but once you are popular you will get people who are happy to help pay and contribute.
Surely, it's the other way around. You are likely thinking on projects which are not just popular, but with a target audience so large that they are nearly-mainstream-media-level popular, or alternative, important enough to be necessary for large corporations' activities. For those you may be right, and even there I'm not sure.
Bash? Chet Ramey is employed at a university, but I don't think they pay him to work on it.
The gap is the ability to generate something of value to others to the point at which you can sustain your efforts without needing to subsidise it like a hobby.
OSS is seen as a way to escape the rat race, either as a better job or as some form of passive income.
It's no wonder developers complain about not paying "customers", their goal was money from the get go.
This is why OSS can't be a replacement for paid software and companies should rely more on paid software - whether open or closed; paying money, after all, is nothing but a way to recognise the value that went into a piece of work.
OSS relies on a few exceptional individuals (Salvatore certainly being one of the enlightened ones - as well as someone that found a way to monetize) but it doesn't scale to your average Joe.
grafana did start small and managed to raise funding from investors.
i think the blender model is the best future for FOSS though. funded by its users without making a profit. grafana's success is nice, but like most startups fail, that kind of success is not common.
that happened to debian. when they attempted to use some of their funds to hire developers some people got very upset.
so taking advantage of opportunities to earn money has to be carefully considered. the funds are best used for things that the community has been unable to achieve. or at least a community consensus for how to spend the money should be there, lest anyone get the impression that someone is able to enrich themselves through the project.
i can't think of a concrete example right now, but i seem to remember some projects that have literally fallen apart over issues like these.
not every project is like that of course, and debian may be the extreme here. but for most projects where this is not an issue it is because this has been clear from the start, and the kind of people for whom it would be an issue self-selected to avoid contributing to these projects in the first place.
I feel like the paradox of this claim is that paid work seems to be collectively far higher quality software than personal OSS projects. This claim is my opinion, I’m not stating it as fact, and I can certainly think of specific cases of very high quality OSS and very low quality commercial software. That said, in my experience both personal and witnessing others, the sum total open source software has a worse user experience precisely because it’s not catering to what other people need, while paid work might seem less cared for but actually does take care of all the boring chores that need to be done to make software great. Things like good documentation, good unit and end-to-end tests, and polished interfaces, just to name a few. Even just building a GUI is probably eschewed more often by OSS projects because it takes loads more work than making a functional CLI. All these things tend to get skipped more often when you’re writing software for yourself, it certainly has been true for me as well as other people I know. It certainly seems true if you pick random projects to read through on github or npm or whatever, most of it seems like it was a passion project for a month or so before getting abandoned.
I'm a creative. I have to create. I would be satisfied with nothing less.
I used to think, like you, that everyone was like me. But I've discovered, most are not. Most are happy to float through life just consuming what is around them.
Sure,many lack opportunities and resources. But creatives exist everywhere - creatives create regardless. There are lots of creatives, but most are just consumers.
And that's fine.
Statements like this, and the whole article basically, make me wonder - since I'm apparently an outlier because none of this is really true for me - whether this originates from people doing jobs they don't really like and/or working for companies which have questionable work ethics and/or working for companies which are mostly about profit not product. I don't really feel any difference in motivation for the payed jobs I do and the contributions to OSS and the personal side projects. And to some extent: the hobbies I have, the non-software things I build. I just want to get creative and do the best thing possible. Sometimes that gets skewed somewhat due to certain requirements, and that happens more for payed jobs, but that doesn't change my motivation.
Code is no different: you only get to tell me how my code should look and feel, or what features it has, if you pay me for it. If I'm creating it for the joy of creating it, then I get to say what it is and what it does. And it's utterly my right to refuse your money, block your comments, and continue doing something with my code that you don't like.
At least in OS you can fork my repo. Then it's your code and you can do what you like with it.
Linux was created to meed common needs. For scratching each others' backs and sharing costs and risks, similar to investing in 1/10 of 10 risky enterprises, rather than taking on the full cost of one.
Linux does not care about "software quality, grandiosity, perfection", rather, to get/keep things working and address the needs of its stakeholders: https://www.linuxfoundation.org/our-members-are-our-superpow...
NVIDIA requires signed firmware since Maxwell (GeForce 750, GeForce 900). https://www.phoronix.com/news/MTc5ODA
Which is why I will never buy such a card.
> programmers are likely to spend more energies in their open source side projects than during office hours
These remind me of Paul Graham's essay "Holding a Program in One's Head": http://www.paulgraham.com/head.html
> It's striking how often programmers manage to hit all eight points by accident. Someone has an idea for a new project, but because it's not officially sanctioned, he has to do it in off hours—which turn out to be more productive because there are no distractions.
> ordinary programmers working in typical office conditions never really understand the problems they're solving
If the developer has strong knowledge of the business while designing a product, it always ends up with better qa as they are writing the right product on first draft.
You hardly get that when you hire someone to do something for you. That is valid in other domain than programming.