that’s whacked

Closed processes and development in an open source world

Sunday, Nov 4. 2007  –  Category: OpenSolaris, OpenSource, Songbird

I just read an interesting article on Linux.com criticising two examples of poor showing in the open source world, one revolving around a KDE icon theme, and the other around GIMP’s UI team.

Certainly I see some parallels in any open source project, both OpenSolaris & Songbird included.

First: my opinions. You didn’t ask for them, but you’ll get them anyway. Blogs rule like that. For the two examples cited in the article, I actually have differing opinions.

For the icon example, I disagree with the Oxygen project and agree with the writer. The icon developers gave up any rights they had to restrict redistribution with their license they published under. The derivative theme was well within its rights to redistribute the Oxygen icons.

For the GIMP UI example, I actually agree with the GIMP UI team. I think they way in which they phrased it could have been better. Perhaps instead of “I am afraid that I do not have positions open at the moment.”, he could have expanded and invited the volunteer to submit his work for review and inclusion without necessarily being a part of the formal GIMP UI team. While some people may disagree with me, I think UI work benefits from having a core team of people with a shared set of goals and design aesthetic. Adding another team member could alter that dynamic and/or add more overhead to the team.

Anyway – these are pertinent issues to both communities in which I participate in. OpenSolaris perhaps more than Songbird – since Songbird has no internal/closed repositories of source. But one prime example of a project people complain about is installation, or packaging – and I know I’ll probably get heat for this, but I think doing closed development is not that bad. The packaging project took some heat for doing its initial prototyping and development (I know I had at least one debate with sch about it ) between its team members before opening up and publishing its work. But given the conflict that can arise between people deriving work prematurely (e.g. the Oxygen case), or even just the issue of it being a design-in-progress (let alone a work-in-progress) means its often easier to be more agile and develop the core of the project between team members (whether that’s internal to Sun or involving external members).

Open source your work when you are ready – not when people ask you to

When you are ready for people to hack on your code, make derived works, and submit features and bugs – then you are ready for open source development. If you aren’t ready for those, then don’t. Open sourcing code isn’t free (assuming you care about your open source community – throwing code over the wall, as always, is cheap and easy – and you get what you pay for). If you want a thriving community then you have to be ready to spend time to cultivate it. If you’d rather be hacking on code to get something initially out – then you shouldn’t publish it initially.