I've come up with a brute-force solution for my multiple installations of version 5.7: putting symlinks in the site folder(s) or index.php file to the functions I plan to share.


---> Note that I am aware of the Portland Labs hosted solution. I am under some constraints that don't allow me to adopt that solution at this time. I highly encourage everyone interested in a multiple-site solution to see what they have to offer first. <----

UPDATE:

I have developed the "Brute Force" multiple site solution quite a bit. It is still not ideal and can't be called a true enterprise CMS, but it is functioning in 8.2.1

First, I build a functional concrete5 site.
/root/sitea
Then I make a share directory with the following paths:
/root/share/concrete5/concrete5-current/
/root/share/concrete5/packages-current/
Third, I move the /packages and /concrete directories from the site into /packages-current and /concrete-current, so the paths look like:
/root/share/concrete5/concrete5-current/concrete
/root/share/concrete5/packages-current/packages
Fourth, I go to sitea/index.php and make symlinks:
symlink('/root/share/concrete5/packages-current/packages','/root/sitea/packages');
symlink('/root/share/concrete5/concrete5-current/concrete','/root/sitea/concrete');
----->UPDATE: if available from your ISP, you can make links within the folder and use the original index.php file, saving some effort.
Test the install--it should still work.

To duplicate the site, simply copy the /sitea directory
Name it what you want
root/siteb
(root/sitec, etc.)
Copy the database
Make a new, clean database for each, import the "sitea" database into it.
Go to the index.php for each new site (or the link in the folder)
change the target name in the symlink
Go to /application/config/database.php
Change the information to point to the new database.
Go tohttp://root/siteb and see what you've done.

Upgrades are done by renaming concrete5-current to concrete5-versionnumber then making a new concrete5-current folder with the latest/concrete folder inside.

Issues:
-MANY functions require going into each instance and making updates. I've learned to take a lot of care in building the original site, because if I want to change Page Type settings or permissions, I have to sit down with a checklist and a can of Red Bull.... Fortunately, the most important things are standardized through the theme.
-Licensing: What's ethical? I figure one license per site that actually uses the add-in.
-Not supported or endorsed by Portland Labs. Again, they have a superior product.

There was a speed and synchronization issue. it turned out to be a function of the host.


-----end update----

/packages is working as expected, and in a worst-case scenario, that might be all I need to accomplish the minimum amount of synchronization I need to make the multiple site solution work. I can push changes by modifying the template pages and provide custom blocks for copy.

However, there is plenty of room for deviation. I'd like to provide my site editors with a little more structure.

Did I say there will be up to 75 related sites?

One thing I'm trying to get control of is page types. I'd like to supply a set of types to each site editor so they can (fairly) automatically set up their sites to meet their needs.

I'd also like to give them a pre-mixed set of permissions. Well-written permissions and workflow will be important, since it seems a symlink works both ways.

So my questions:
-- Is there a more elegant way to accomplish this?
-- How do I gain control of page types and permissions?

Any help would be appreciated.