Jonathan: Yup. There’s quite a lot of work involved in making all those changes that localize a product general enough that they’ll make other installers happy. Sometimes we need to apply hacks for our local environment that can’t easily be made general, and it’s hard to know what to do in those cases — do we run a local fork of our own project? That sucks.

Karen: I’ve run into two main hurdles in the “release, and let the community improve things” approach.
First, reviewing, testing, and applying patches takes a nontrivial amount of time. Is this patch of reasonable quality? Do I like what it does? Is it likely to break things for me or someone else?
Secondly, community involvement beyond “This doesn’t work, can you help?” is very rare — I can count the number of submitted patches on one hand. This is not meant as a complaint — getting deeply enough into a project to commit code is a huge investment — but the “build it and the world will contribute” thing Just Does Not Happen.

That’s a pretty big “and”. There’s another part though too. I have realized lately that releasing code that other people can config to use locally _without_ changing your code also takes more time. The more typical way libraries do ‘open source’ is I’ll give you my code, and then you’ll hack it to do what you want. But now we each have different codebases, and it becomes difficult to share our improvements with each other, we each are running different ‘forks’. Compare to succesful open source, where everyone runs the same code, but _configures_ it through flexible config to be different.

Anyway, I guess the end point is that, to get the kind of open source that will really benefit our community, it IS more work than just taking what you would have done anyway internally and releasing it. Pretending you can get the real open source benefits for free helps nobody; instead, we need to realize that it does take effort, and that effort needs to be supported, but that effort can result in dividends that make it worthwhile.