When Should Source Be Released?

MEconomy asks: "I'm the CTO of a commercial entity developing a technology that we plan to 100% open source. I'm looking for other options, opinions, and bulletproof arguments to take to Open Source-leery business types to convince them to release earlier (my preference) rather than later." While releasing the source early is a good thing, it can be released too early. I would never release the code to a project that wasn't in a runnable state, and would honestly consider holding off source releases until the project was at least in the "beta" stage. What do you think?

"I am very curious what peoples' thoughts are on the tradeoffs (business risks, community reputation, etc...) between:

1. immediate release of the source code at product launch,
2. waiting until the technology has acquired a large enough user base to insure a competitor won't just 'take the code and run',
3. commit to full source code release and release piecemeal (ala ZeroKnowledge),
4. a short-term (~1yr) closed-release to mutually trusted third parties (e.g. EFF),
5. placing the code in a provable timed-release escrow."

   [Update by nik]: Accepted practice seems to be to wait until about a year after you're bought by Sun. . .

Comments

Read your ESR

[Mike Schiraldi]

ESR has a lot of good advice on this.. See www.tuxedo.org/~esr.
--

early is definitely good.

[AugstWest]

If you release pre-beta code, you're essentially filtering out people who would download the code simply to run it for free. Not many people are eager to deal with the extremely buggy, pre-beta or even pre-alpha code.

Releasing early also gives you the advantage of having more eyes looking at your code early to spot any bad design decisions -- it's a lot easier to fix bad choices early in the project than it is when the code is more developed... You don't want to have to rewrite the entire foundation just because you made a seemingly good decision early on, which later turns out to cause issues.

It can't hurt to have extra experienced eyes running through your code at the early stages.

Re:early is definitely good.

[demaria]

It can also work against you as well. Some of the better programmers out there may look at it and say....okay this sucks. Screw it, I hear sendmail needs some work.

I occasionally get soft/trialware that makes me say funk dat, I'm not using this, and then it gets blown away from my realm forever.

Your source code having a bad reputation is not a good way to generate interest. Maybe, combine your idea AugstWest and my reservations. Selective early release, where only some people see the code and help, and then general release after it's matured a bit.

Re:early is definitely good.

[SvnLyrBrto]

Another VERY important reason to release early is to prevent your code from being forcebly supressed by certian entities that have it in for independent open source developers.

Witness the Gnutella/Nullsoft saga. To employ a couple of bad cliches, Gnutella just barely dodged the RIAA's bullet, but is not out of the woods yet.

For those of you not familiar with the story, Nullsoft are the fellows who developed WinAmp, and were subsequently bought by AOL with the promise that they would be independent within the company. Their next project was to be a new file-shareing program that, unlike Napster, would allow ANY kind of file to be transferred, and would not be reliant on centrally located servers. Not only that, it was intended to be a GPLed program from the very start.

Well, you might also know that AOL recently aquired Time-Warner, notorious member of the RIAA *AND* MPAA. Well, TW turned on Steve Case and ordered him to put a stop to Nullsoft's latest creation. And put a stop to it he did.

Fortunately, the wego guys suceeded in getting ahold of the source and have been producing binaries. But the FAQ seems to indicate that there are still legal issues with the source code, so there is no source available for a program that was INTENDED BY ITS CREATORS to be open sourced.

If Nullsoft had the foresight to released the source under the GPL at the first opportunity, with the first release, BEFORE Gnutella appeared on time warner / RIAA / metallica's radar, this problem would not exist. The source would be out under the GPL and I suspect that development would have proceeded much faster than it has (it's been at ver 0.56 for HOW long now???).

Or imagine if Jon Johnson had delayed the release of deCSS. The MPAA could possibly have acted to supress him in time to destroy the code before the world had redistributed.

If you're working on code that might challange the business model, compete with, or in any way irritate, someone who ALREADY has tons of money, such as RIAA/metallica, or the MPAA, or microsoft, etc. it's DEFINATELY the best idea to "get the geinie out of the bottle", as soon as you can.

That way, even if *you* are persecuted, your IDEAS cannot be realisticly suppressed.

(I would hope that if Napster DOES lose against the RIAA/metallica, that Fanning's last act of defiance before the company's execution would be to GPL the entire source for everything. I would have a LOT of respect for anyone with that kind of courage and integrity)

john


Resistance is NOT futile!!!

Haiku:
I am not a drone.
Remove the collective if

Be Careful of Mozilla / Java Problem

[waldoj]

This isn't a flame. I swear.

Both Mozilla and Java have the problem of long development / consumer introduction periods. So the general public (or, in the case of smaller technologies) gets really sick of hearing about them (but knowing that they can't relly use them), until, eventually, they get sick of them.

I've been willing to be part of testing Mozilla, and I love it. So have many of us. But most consumers aren't so forgiving. Be careful of saturating the market with concept so that people have tuned it out by the time you have some substance.

-Waldo
-------------------

v0.99

[Dysan2k]

I'd suggest releasing code at your v0.99 point which should be a code-freeze state and final bug-fixes. At this point, OSS people will no doubt grab the source and put it through the ringer. After a couple of weeks worth of reports and suggestions, you'll probably be able to put together a release.

But please note:
Since you didn't say what KIND of software it is, a fair evaluation is extremely hard to give. Also, what lang. is it written in, and is it going to be standards compliant? (i18n, etc.)

Plan first, then release often.

[ka9dgx]

My knee jerk response is to get the planning done, get the "vision" mapped out. If you've got a firm set of goals and a project plan, you can release as early and often as you like. If you don't, then I believe you'll be pulled in all directions by the rest of us.

Early and often seems to be good except for the pull into other directions.

--Mike--

whatever you decide

[Lord Omlette]

You sure as fuck had better not be releasing the source code as an alternative to having your own people test it. "Why pay QA when geeks will test it for free?!" Nonono, make sure the code is secure after you have your own people banging on it for a while, make sure it's well documented, THEN feel free to release whenever and however you want.
--
Peace,
Lord Omlette
ICQ# 77863057

Re:whatever you decide

[Arandir]

I definitely agree. Too many developers (of both the commercial and non-commercial variety) believe that QA people are merely bug finders. This is absolute nonsense. Dumping beta OSS on the public to avoid paying for a QA team results in low quality.

Not having any statistics, I can only surmise one of two possibilities. A) too few bug reports will be submitted to be of any use, B) too many bug reports will be submitted leading to information overload.

As a professional QA engineer, I thought I would do my civic duty in the OSS community and perform a somewhat rigorous testing of a certain noted software project. I submitted about a dozen bug reports after an half day of testing. One of them resulted in a fix. Of the rest, the typical response from the developer was one to two months later, with the typical reply being that it wasn't really a bug.

In another noted (and commercially funded) OSS project, I offered my services as a QA tester and was accepted. Then I asked for requirement and specification documents, only to be told that they didn't exist. After a bit of pleading one of the developers spent about ten minutes coming up with a two paragraph spec of the entire project.

Dumping software testing off on the unsuspecting public is not only an insult to the QA engineer, but also to the user.

The Magic Cauldron

[drodrigo]

The Magic Cauldron is a discussion of different models of opensourcing your project.
It's a very well written article, has some examples, etc.

something to consider

[Kailden]

Is it an applciation that is going to gain a lot of interest? In that case I would start publishing a least the API's so that you can see how many people are interested in working with your technology. A lot depends on what you are trying to release. If it's something that you can have people start writing add-ons and features to without releasing the whole thing, then you should probably consider open sourcing that part right away. (ie, keep the "kernel" closed until you have a big jump on competitors)

Of course IANAExpert.

A tip...

[Bill Daras]

Give your application a name like:

software-title-goes-here-.0.1.2.9.p4.7.3.2.9.9.c7- g00pr4.5.5.27-8.22.2.1.rpm

Add a new version number at random everytime you write two lines of code. This will make you a kewl OSS programmer.

Alpha or pre-alpha release

[Izaak]

My personal oppinion is to release at alpha or even pre-alpha, rather than beta. Alpha means the code runs but some functionality is still missing. Beta means the code is basically all there but needs extensive debugging. The whole point of open source is to let other people contribute (not just debug), so as soon as you have something that compiles cleanly and is even marginally usuable, release it. Of course label it very clearly as alpha code and not yet ready for prime time, but release all the same.

At least that is the approach I took with GridSlammer, and it has worked out very well.

Thad

"Why" is more important than "when" or "if"

[Anonymous Coward]

I have discussed Open Source software releases with several companies, mainly concerning obsolete or discontinued products. The motivations for Open Source release are far more complex than the surface "religious" issues would indicate. I have raised these issues with several of the Open Source luminaries (in particular with ESR), and have developed a series of questions that should have solid business-motivated answers before proceeding with an Open Source code release.

1. Is this product intended to produce a revenue stream for the company?

If "no", then Open Source release is probably OK. Otherwise:

2. Does this product contain trade secrets or protected/restricted Intellectual Property (IP)?

If "yes", then the source code is likely to be useless unless a license to the related IP is included. Otherwise:

3. Is this product of strategic importance to the company?

This is a difficult question. It could be something as simple as a specialized driver for a very rare piece of equipment, or something as complex as an ASIC partitioning and layout system. In either case, the product could be vital to the business process, yet not be a revenue source in and of itself. This leads to two questions:

3.1. Does the company expect to rely on assistance from the Open Source community to make this product usable to the company itself?

If "yes", then the company is taking an extreme risk, since there is no guarantee the Open Source community will express any interest at all in the product. However, if the company lacks the expertise to complete the work, or the funds to hire outside assistance, this may be the only way to get the work done. Otherwise:

3.2. Will this product be useful to your competitors? Does it pose an economic or competitive threat to your business?

This is the two-edged sword of Open Source: The product may be of immense help to you, but may be of even greater help to your competition. However, all such advantages are transient and temporary to a greater or lesser degree, so it is often far more important to give your own needs top priority, and let the competition do what it may with the product.

This list of questions goes on to greater length and detail, dealing with a wide range of resource and business issues surrounding Open Source, some of which have been mentioned in prior replies on this topic. There are also many issues related to the management and functioning of the software development process, and control of the product. (Such as: "Who decides which patches and CVS commits are rolled into the next release?)

It all boils down to a simple question: Why do you want this released as Open Source? This question demands an affirmative answer, and not the obsequious answer of "Why not?".

For an enlightened view of an intermediate stance, take a look at Caldera's new policy of "Open Access": All software will be released with full source code. The source code will have the same license as the binary, which may range from fully proprietary to GPL. All licensed customers will be able to build their own binaries, and develop and incorporate any and all pacthes they need. The main goal is to give Caldera customers a real say in the software they use, and to avoid the restrictive license hegemony that helped make Microsoft the monopoly it is today.

Caldera also plans to rely on continual innovation to stay competitive, which means all products will evolve toward the GPL as they age (either by succesively more liberal licenses, or piecemeal). And all products will fall under the GPL by default if Caldera is unable to support their end of the license for any reason whatsoever.

This policy, in essence, takes all the teeth out of the "shrink wrap" licenses and the ludicrous rules embodied within UCITA.

But I digress: The decision to release under Open Source is NOT a black and white issue, and ESR (among others) lists several reasons when Open Source is inappropriate.

Seek the greatest advantage for yourself AND for the Open Source community. In very many circumstances, a radical rethink of business processes and reasoning will often result in the decision that Open Source is a net advantage for all concerned.

But not always.