A good question was raised in this comment by EGHDK:
Why do these modules have bug reports. Shouldn't this be a simple task for a module to complete with no errors?
He was referring to limiting the viewing of pages to users of a certain role, but the question applies broadly.
There's a big difference between creating a custom module for just one site (your own, let's say) and creating one that will be able to be used on many different sites.
For example, let's say I want to limit access to a certain content type to only users of a certain role. Let's say that content type is 'awesome_thing' and the role is 'awesome_person'. There are two ways to go about this.
This would probably consist of something like a hook that gets called for each page, examines the $node object to see if it's 'awesome_thing' and then, if it is, examines the $user object to see if it's an 'awesome_person' and, if so, loads the page or whatever.
This would have to include a configuration interface that allows users to specify which content types they want to restrict, and which roles they want to allow on those content types. If there's more than one combination of role and nodetype then you have to deal with that. Then, since you've given a mouse a cookie, people are going to have feature requests, or maybe they'll write patches that add features and you think they're cool and you want to integrate them into a new version of your module.
Then say your module has a dependency on another module for some of these features, or your naming conventions conflict with another module's. On most sites this won't be noticeable so you probably wouldn't ever encounter it as a problem just on your own site. But by the law of large numbers, if you let a whole bunch of people use your module, they're more likely to discover corner cases where things work in unexpected ways than you are to think of every possible use case.
And then someone might look at your module and see that you violated a coding standard or namespace convention. Or they might see that you used 5 lines of code to do something that could be better done in 3 lines, or that you did something that's going to be expensive on performance if the module is used on a large-scale site with higher traffic than yours.
The tl;dr is that writing your own snippet for your one little use-case is exponentially less complex than writing, say, a patch for public consumption which itself is exponentially less likely than a full-blown module to both contain bugs and to have its existing bugs noticed and called out.
I have been involved with the F/OSS community for 20+ years, and it has a dirty little secret:
There is often very little incentive for the original authors to maintain code unless they are actively using it themselves or are affected by bugs themselves.
I have several patches on issues that have sat for well over a year. There are also some really serious problems (for some people) in core that have patches that won't get committed.
When authors are committed to projects, they grow. When they get help they grow. When they encounter bugs that may affect them down the line, they accept patches.
When they don't use projects anymore, they stagnate. When they move onto other things, they die.
Inherently humans are flawed, humans write code, therefore code is flawed. This creates bugs.
Personally I suffer from "can't see the wood for the trees", when I code a new module I find it difficult to find every single use case for the module therefore I don't think of every issue that might crop up.
Why do these modules have bug reports. Shouldn't this be a simple task for a module to complete with no errors?
I disagree that creating a module without errors is that simple, if not in the cases the module's code is really simple.
For that to happen, you should test the module in different conditions, which would also mean to test it in a test site running other modules as well, and with different versions of those modules. There are so much modules that is impossible to test all the possible combination of modules, especially because it's not a matter of testing the module you wrote with any combination of two other modules. Theoretically, you should test your module with a combination of infinite modules.
Writing tests for your module helps fixing the errors in the module you are developing, but that doesn't catch all the possible errors caused from the combination of two running modules.
If the test infrastructure used on Drupal.org allows you to do that, you can test your module requiring another module to be installed, but it would be up to you to decide which other module you want installed during the test, and you cannot foresee any possible problem with other modules. Also, you cannot test your module with random combinations of modules, considering that the test servers are thought to test not just your module, but all the modules hosted on Drupal.org.
