So don't merge it. If you look at an Oracle install, or any other sufficiently large software, you'll see it consists of a whole bunch of executables, DLLs and so on. It just has a single Interface, which starts and stops bits as needed. The argument of needing to explain how it runs to someone else isn't really one, if that's how you've designed it, then thats how it is, describe how it works to them.

It really does sound as if you need one overall script, which runs the others.. Why fork? Why not just run them using system() or similar? (I assume your three parts already have some external method of communicating). That way you get to keep the code in separate, easily managable scripts.

Alternatively, you don't need to copy all the code into one script to have it run together, using modules and such will keep the actual code separate, but allow it to act as one. Eg. make a module for one part, do 'use Module;' and 'Module::Run();' to get it started ?

(Forks are yucky, if you ask me ,)

C.