I think moving to a distributed version control system is a really good idea, and we are looking to do that for opentaps. That way, more people could share their customizations and enhancements on top of the core opentaps.

The distributed version control system is just one part of the puzzle, though. Another big part of it is making the architecture more modular, so that a lot of enhancements could be viewed as modules on top of the core, rather than customizations to the core. I’m really impressed for example at how many modules there are for WordPress or Magento, and that’s how I’d like to structure opentaps going forward as well.

Yes, “tempting” is indeed the right word! But do you really need it? I think Phil’s point is that (only) in a small number of cases do you really need to customize. The other customizations are probably not necessary, but often are done to placate different groups of existing users. In other words, if you showed up with the software “as is” and told a new group of users “learn this and use it,” they would probably be okay. But if you go into a company with a group of existing users, they will often come up with customizations that aren’t necessary.

Do not however assume that sending patches back to the maintainers would always work. I think people often don’t realize that there’s a real cost for “maintainers” to maintain code, be a code that they wrote or other people contributed. This is where Drew’s comments to this thread about making the code “social” really make sense.

@Drew Purdy – I suppose that it’s all a function of numbers. If an OS app gains significant traction, then you’d think that bridging would take place. I just read Here Comes Everyone by Clay Shirky and he cites a stat that something like 75% of all OS projects are essentially untouched. He cites a “power distribution” in which projects like Firefox, WordPress, and Linux account for the vast majority of OS work.

So, I’d assume that more popular OS apps stand a better chance of bridging than really obscure ones.

Of course, I could be wrong.

One thing that really interests me in this conversation that goes off topic a bit is how distributed version control systems might really help us leverage dealing with customizations for customers in an open source company. Just look at the two communities github and bitbucket.org and how they are getting so popular. Look at how quickly and often people will branch the code and work on whatever feature that itches and how you can pull those itches that turn into good functionality back in to the core. Often times the connection between the core code and customizations is across to vcs projects. And merging or branching across subversion is not cheap in time or complexity. Github and bitbucket are really bridging that gap of having to add people to your subversion access and grant authority to commit and having to police the trunk. Instead, these dvcs\’s let you fork easily and pull in changes you see fit without having the overhead of managing all those users. It\’s social networking being applied to code.

So my question is this? Why wouldn\’t the open source companies get involved with bridging their customers\’ customizations so that there is an opportunity to support, incorporate, or push out of the core customizations more easily by using a dvcs?

But, when you want stability over all, which is mandatory for servers and applications that run on them, there’s no point in risking getting left behind when new features are delivered in said applications’ releases, or even end up with broken systems. Better safe than sorry.

Maybe a better way to go is to send patches to maintainers to try to get our changes incorporated into a new release. Anyway, there’s no guarantee that they will be taken into consideration at all.

No easy answer.