From good, working FOSS projects you can learn just about anything. As for the distributed software development: One thing people can learn from FOSS is versioning. Seriously. Quite a few teams I've met in RL can't and don't/didn't version, with FOSS it's mandatory. A very important aspect is that FOSS teams version just about everything, including docs and assets. Very important.
Another thing distributed teams can learn from successful FOSS projects is not to drown in tooling-bloat. Most tools in FOSS are tried and true and have a track record of decades. IRC, simple IDE/compile setups, tried and true working environments (f.e. LAMP stack), a bug/issue tracker that does the job and maybe a web-forum. I like to use the Google suite for my projects, but that's mostly for FOSS stuff, so it doesn't matter to me that much what Google is reading along. YMMV.
One thing that I would recommend when doing distributed development is, that you should set up your entire environment and pipeline, so that it is ready for distributed devlopment. You should have different pipelines depending on location. The overall process of versioning, tracking, compiling and deployment should be the same for everyone. The difficult part isn't getting the externals to do their thing but to get the locals to switch to the new, optimsed processes.
Another thing good (FOSS) projects have in common is a clear vision and good gouvernance. The stakeholders and PMs of FOSS projects actually have their agency behind the thing. If they don't, they quickly drop out or the project simply never gets off the ground. ... That's a huge upside to FOSS btw. In paid development, you get idiots dragging along for years, simply because there's a paycheck involved. Very painful. I've seen that a lot of that.