There is dependency manager for PHP called Composer (see http://getcomposer.org/). It allows you to keep only main project code in repository and download all used libraries from GitHub when project is deployed to a server.

I see following benefits of using it:

no need to invent the wheel, because we can use any library out there that fits our needs (need to check out library licensing though);

no large svn checkouts (for developers), because all 3rd party libraries are managed by Composer and not in In-Portal repository;

automatic 3rd party library upgrade, because Composer will take care of that;

no need to have "root" access to a server, because Composer installs all libraries locally in project's /vendor/ folder.

To make this even more interesting I'm proposing to develop new In-Portal functionality (when possible) in a way of pluggable 3rd party library. Such libraries then can be reused even without In-Portal itself.

Separating In-Portal into Components

Right now there is a lot of code in In-Portal and it's modules. Codebase is separated into 2 groups:

In-Portal releases also take a lot time to happen (1-2 months and up) because of way how decision is made whatever to create release or not. Right now we delay release until by our subjective opinion (as a release managers) we think, that all possible bugs were fixed. If a new bug is found then release is delayed to make this bug fix fit into release for greater benefit. This concept on a large codebase results in long release cycle which is bad in either case.

What I'm proposing:

Step 1

create account on GitHub (git repository hosting, that is free for OpenSource projects) for Intechnic company

put all In-Portal code (in-portal, open-source modules, themes) there (on GitHub), where each module/theme would be a separated GitHub repository

existing aliases would be empty Git repositories with a composer.phar and composer.json file in them, that would tell what versions of which modules are required

project checkout is easy:

clone a git repository

run "php composer.phar install" command

By doing so we'll get (at least these):

all In-Portal code accessible and searchable on GitHub, which is already good

anyone having composer in their In-Portal installation could install a new module with 3 steps:

put module name into his composer.json file

run "php composer.phar update" to get new module

install module from In-Portal's Admin Console

Step 2

move out loosely coupled reusable code into it's own GitHub repository (repository per-piece), e.g. ImageHelper goes to one repository and CurlHelper goes to other

each moved out piece will have it's own release cycle (can get released even before In-Portal does)

all component bug fixes are automatically applied to all projects using it (through usage of Composer "1.*" dependency)

as any code, hosted on GitHub we'll also be granted with usage of TravisCI (https://travis-ci.org/), which is Continuous Integration server, that would automatically run our tests (or whatever we need to run) on every commit.

After completing this step we'll get (at lease these):

smaller In-Portal codebase

separate components, that are:

easier to test

can be reused in other projects (even ones, not using In-Portal)

immediate bug fixes without waiting for large module release, that is using component with a bug

With GitHub no much change is required. But beware, that in Git revision numbers aren't incremental (e.g. 1, 444, 443433), but instead are md5 hashes of commit contents. If we do "less then" or "greater then" checks against 2 revision numbers, then we must fix that too.

The minimal PHP version required to use the Composer is 5.3.2. Since In-Portal 5.2.x required version is PHP 5.2+, then we can't release Composer support along with In-Portal 5.2.1 release. It would only be possible for In-Portal 5.3.0 release, where supported PHP version will be bumped.

Looking at proposed solution again reveals critical flaw in the plan, that wasn't noticed before: Composer only can install stuff into /vendor/ folder and therefore won't be of much use, because modules have data, that needs to be accessed from the web.