There are three primary ways to collaboratively share code.
- As source.
- As a service.
- As a library.
These aren't mutually exclusive, but represent the main deployment strategy. For example, you might offer a library (e.g. via a Maven or NuGet repository), but also make the source available.
Source is fine, but you really only want a focused team of 5-7 working closely to manage the incoming commits. Otherwise, the code suffers from the tragedy of the commons - your tests, code coverage, and overall quality will suffer. Source sharing also makes dependency management hard - "did you build the code from this morning at 9:38am or 9:52am"?
Running a service (e.g. REST/JSON) is actually really hard because of the dependency management issues. "Well, we'd like to update the staging server services, but that will break three other teams." Interestingly, the main reasons for running a service are data management & security, not code sharing. It's possible, but you really, really need to think about service version management.
Sharing code as a library, using a proper repository manager with dependency management is by far the easiest strategy. Set up a 1-click deployment with a CI tool, and you're off to the races.
As a simple set of guidelines:
- 5-7 people with direct commit per source repository, max.
- All other incoming code should be submitted to that team as patches/pull requests.
- If the security and/or data are the key value of the code, it's a service.
- Otherwise, if possible, publish your code as a library to an appropriate binary repository (public or private as needed)