> Perhaps the easiest way to encourage new contributors, who are assumed to be casual, is to encourage incomplete and partial fixes that the main team completes

> Perhaps the easiest way to encourage new contributors, who are assumed to be casual, is to encourage incomplete and partial fixes that the main team completes? A better way is to reduce the complexity and, especially, tight coupling in your code base. Then it doesn't cost your own developers 15 hours to do something that should take one hour either. If you look at the gnu utilities as a "project" then it's quite a lot of code, and in a sense it is a single project. To make ls(1) useful you need a shell, to make a shell useful you need things like readline(3), etc. But if I have a contribution to make to readline, it shouldn't really affect ls, or vice versa. And if I want to swap out bash for csh or make my own toy shell that uses gnu readline, or use bash with the BSD version of ls, all of that is reasonably possible. Browsers do that a little. Maybe the TLS library is a separate component, or the javascript engine. But how hard would it be to use the Mozilla javascript engine to create a toy browser to play with or to add javascript support to wget? How many external projects are actually using it?