I am a fairly active linux contributor. I have patches all over the kernel tree. I also review drivers/staging code.
Most of the patches that I send are things that I cannot test because I don't have the hardware. Even though I'm careful, there are still a few times where I have introduced bugs. The most recent example was code like this "if (!attributes & 0x4000)". That has a precedence bug so the condition is always false. Unfortunately changing it to "if (!(attributes & 0x4000))" disabled certain graphics card. The correct thing was to delete the condition.
Breaking stuff is just a part of development, you try your best but don't let fear of breaking things stop you from applying patches.
Probably over 5% of the 10,000 patches in every new kernel are cleanups. We're always merging API changes and unlike Microsoft we don't care if it affects out of tree drivers. There isn't any subsystem where the owner says, "This code is stable now and I'm only accepting actual bug fixes."
The other thing that helps is the short release cycle. If something does break, it's easy to fix.
Some people find linux development frustrating. One developer told me, "Ever since XXX took over the YYY subsystem he has been constantly changing the API and re-writing my code. Does he ever sleep? I don't know how anything works any more."
It's hard on reviewers as well. I have reviewed literally over 3000 cleanup patches to the comedi subsystem. I have mornings when I feel lazy and it doesn't fill me with joy to see 40 new cleanup patches in my inbox. The process is expensive.
But I do feel a great deal of pride in the work.