The IDE is open source and MIT licensed. Change it and share your changes how you like. The problem is the contribution and integration process. Trying to come up with a process would be the job of an integration manager which we don't appear to have for the IDE.
If people want to stick to the binary file format then probably git should be dropped in favor of some VCS with file locking and central control such as SVN with svn:needs-lock or mirror the github repo on runrev's servers and use gitolite's file locking features http://gitolite.com/gitolite/locking
. It would basically mean RunRev would need to give RW access to the IDE stacks and it would be very difficult to revert changes if more changes were made on top of them as they would be in this kind of linear history. Also being binary files it would be difficult to see exactly what's changed. These reasons mean they might only want to trust a few people they have a long history with from the LC community to have this access and they end up in a position of potentially offending a customer by not giving them access... This is why DVCS like git is so much better for open source projects.
I will be starting a beta group for lcVCS this month so if RunRev want to use lcVCS then they can delegate an engineer to be involved if they want.
I have started to consider possibilities for contributions using lcVCS that avoid the majority of users having to use git. Basically stackFile distributions would have a custom property on the mainstack uVersion["SHA"] which is the commit hash. Someone could make a change to the stack then email it to the integration manager. The uVersion["SHA"] would then be used as the branch point for looking at the integration and merging it in if it all looks OK. It adds a bit of load to the integration manager and would be restricted to one contribution per stackFile between each LC version but given there aren't many in the LC community that have experience with VCS it may be a useful way to introduce someone to contributions. The same method could be used for other projects too and community members could offer to do these integrations and send the pull requests for people.
The IDE may also need some other special tools to deal with the fact that lcVCS importing the IDE it's running in is probably going to be issue prone... Deleting and recreating the home stack for instance would lose all externals from the environment including mergJSON which is a dependency...