More on the effects of open sourcing a closed product

by Andy Lester

I've been spending the last few months driving the technical side of preparing Socialtext Open, the open source version of Socialtext's core wiki product. I've been working with other Socialtext developers to get a huge codebase that only needed to be tended by internal developers into a form that can be easily downloaded and installed by anyone. It's been a daunting task.

As we came down to the wire, preparing for today's big release, I read Nat's Radar article "Opening the source" about how much more than mere licensing will change when open sourcing a project. It prompted me to write a list that I posted to my internal development blog.

Socialtext Open is going to change everything about how we write code. Even if you're not one of those directly responsible for getting Socialtext Open out the door on Monday, after that day, we'll see a huge shift in how things happen. It won't happen overnight, but it'll happen.

Off the top of my head:

  • We're going to have a larger dev team.

  • We're going to get a tenfold increase in potential distractions.

  • What once were nice-to-have features may become mandatory.

  • Socialtext Open releases will become big events.

  • Little arcane bits of knowledge stored in our collective brains, like the maintenance of /etc/aliases.deliver, will need to get documented in a central place.

  • We're going to have two bug tracking systems to maintain: our existing RT system, and one on SourceForge (not RT) for the open source community.

  • Our visibility will increase tenfold.

  • Each of us will have to know more about our products than we did before, because we will all become the face of Socialtext.

  • Design decisions will have to be documented for the world to see.

  • FAQs will be VERY FAQs.

  • It won't just be the business folks checking us out, but now also the code folks.

  • Things that we're used to, that have grown organically over time and that we've lived with for a while, may be held against us when held up to new eyes. ("Why do you guys use both TT and Mason? That's stupid!")

I know there are plenty of others. If you've gone from a closed to open source product, I'd love to hear your additions to the list.


2006-07-25 10:20:42
Why split the tracking system? We've found that having one works much better.

ACLs work well, and it saves a lot of headaches.

Listen to your customers, but don't let them drive features directly. Take the collective request and then make sense out of it. Things that are "stupid" will be refactored out by the community if they are causing harm to the overall codebase. Though sometimes not fast enough.

Andy Lester
2006-07-25 10:35:29
We know we want to do public bug tracking on SourceForge, but we're also not going to abandon our internal RT system. Much of our RT system isn't appropriate for public distribution.
2006-07-25 10:41:25
Personally, I would avoid sourceforget. It's slow, and you have little control. IE: You will outgrow it quickly, so don't bother with the pain of going there, and then doing something else.

Setup a public bugzilla, we've found even the least technical of our customers don't have an issue with creating bug reports. In fact, they like too! It gives them a sense of helping out with the direction of the product(s).