Much (most?) code is trivial to write, the work is figuring out what code to write -- posing the problem correctly is half the job. Then inevitably as you work

Much (most?) code is trivial to write, the work is figuring out what code to write -- posing the problem correctly is half the job. Then inevitably as you work on solving the problem you will (if, and only if, you know the business domain well enough) discover that the problem description needs refining as the code is refined. If there was a market for code I would not participate since it takes me less time to just write the code than to write a spec you could use to deliver something good. Non-programmers cannot do that, but if they are in the people you wanted to avoid, they would likely make a spec that would create a mess, regardless of how good the code driving the mess is. I don't see how remote vs not has anything to do with managers or not...how would you get the "orders for code" written in the pure-code marketplace? The trick about open source is mainly that the programmers ARE the end-users too and very well able to understand the problem domain and also are often scratching their own itch. So the problem of making good problem descriptions and make the code match it disappears. That is much more important than remote vs non-remote.