Assuring Users When Closed Software Becomes Open?

joeldg asks: "I just recently decided to go open source with a project I have been doing for some time. After initially going open source I have had an avalanche of questions from users about what 'Open Source' means and how it will affect them. Many are scared of the implications and the broad new sweeping changes others could make in the project. My question is how do you alleviate the fears of over 5,000 dedicated users and get them to accept the idea of the project going open source and also keep some track of the project so that you can direct the current userbase to new sites running the code?"

Comments

Kinda obvious.

[Trusty Penfold]

Write a FAQ like every other open source project in the world

So sell them something.

[orthogonal]

I have had an avalanche of questions from users about what 'Open Source' means and how it will affect them. Many are scared of the implications....

Sometimes, people don't believe a thing's valuable unless they have to pay for it. (And often with good reason; ad-ware's a case in point.)

Some other people don't feel they have any control over you, without having paid you, and thus having something (theoretically) to sue about.

So offer to sell these doubters a support contract, or specialized installation or customization.

More than a source code release

[Meowing]

From the looks of things, you're not just releasing the sources but also getting away from hosting the system. I'd imagine that users are going to be a lot more concerned about who is doing the hosting from this point on than how the software is distributed.

One possibility would be to keep a page with a list of sites that offer the service. A nice plus would be to keep track of user ratings as well -- maybe even keep hosting one board (on your own site or even on SF) where users can discuss and review the options.

One suggestion

[Anonymous Cowdog]

It would help to have a real summary of what the project is on the SourceForge Summary page. The way you have the Summary page set up now, when your (probably not-quite-as-geeky-as-you) users look at the pointer you provide them to SourceForge, they are going to be overwhelmed by how technical and intimidating it all looks.

I've seen a lot of SourceForge (and other, for that matter) projects that have this same issue. When you go to the Summary page to try to figure out what a project is all about, it instead says something like: Updated new version to fix build issues. Which is almost exactly the kind of content you have on yours now. Not very informative, and not very reassuring to normal users who tend to fear the unknown.

So while this would help your case a lot, I think it is also good advice in general for all SourceForge project owners: Write a blurb that clearly explains what your project is about! Hope this helps.

Re:gatekeeper/dictator; you have the power

[Trelane]

For an individual tree, yes. Is also a form of QA, since a given patch must convince the maintainer (either directly or via a large group) that the patch is correct. However, the program itself is very democratic, since the user has complete control over his/her own tree, and can publish this tree (AKA fork the project) independently of the original. Thus, in effect, it is a democracy, since each user has absolute control over the program that they actual ly run, although they might not have much influence with the original project. (Now, as many would point out, most users don't exercise this and/or don't particularly care, but there are those who do, and it leads to a miriad of cool possibilities, and much more control than a config file or especially a silly Registry can provide.)

Contrast this with closed source, where the company/programmer is truly a dictator, and wields extremely strict control over the program.