Slashdot Mirror
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:
- immediate release of the source code at product launch,
- waiting until the technology has acquired a large enough user base to insure a competitor won't just 'take the code and run',
- commit to full source code release and release piecemeal (ala ZeroKnowledge),
- a short-term (~1yr) closed-release to mutually trusted third parties (e.g. EFF),
- 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. . .
Early and Often.
--Threed-Looking out for Numero Uno since 1976!
In my programming experience I liked it better when it was realease later. The main reason is I would trying using it and then adding my own personal add ons to it, and then when the final or a later version came out all my code was broken because they changed somehting major.
ESR has a lot of good advice on this.. See www.tuxedo.org/~esr.
--
--
Mod up a post Rob doesn't like and you'll never mod again
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.
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
-------------------
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.)
-What have you contributed lately?
Early and often seems to be good except for the pull into other directions.
--Mike--
As said by ESR in The Cathedral and the Bazaar.
All browsers' default homepage should read: Don't Panic...
I would personally rather have a stable code base to be looking at rather than having to deal with a constantly (well maybe not constantly, but one big change is enough) changing codebase. I think the 'beta' stage (the original sense of the word, not ICQ) is a good time to release it, because it gives users a chance to send in comments, bugs, and perhaps get some of their own code added to the product before the 1.0 release.
mov ax, 13h
int 10h
You obviously don't work for Micro$oft.
As soon as it's runnable and you have some decent documentation (i.e. readable)
Call it Alpha if it crashes a lot.
Beta if it only crashes now and then.
A feeling of having made the same mistake before: Deja Foobar
Since you use the term "Open Source" rather than "Free Software", I'm assuming your goal is NOT freedom.
/dev/zero")
So, if your goal is:
Buzzword-compliance--Announce total open-ness right now. Actual timeline does not matter.
Free testing--release beta1 (or later) as open source. (Note: do not apply incoming patches unless the bug appears in a story on Slashdot)
Venture capital--Tell the VC's that you "comply with an open source definition". Then create your own license with instructons on how to get the source ("cat
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
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
[o]_O
For open projects, such as Mozilla, early is, of course, necessary, so that people can work on the source. But if you're going to be doing all the development yourself, I'd hold off on releasing any source until the product release, or at least until the beta stage.
The Magic Cauldron is a discussion of different models of opensourcing your project.
It's a very well written article, has some examples, etc.
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.
I need a TiVo for my car. Pause live traffic now.
If users have your source code early, they can get a feel for the programs structure and your style of programming. This means that as you release later versions, they will be better at making good decisions on how to tailor that code to their needs or even how to port that code to a new system.
The only thing to remember is, that it can be very annoying to developers if the code undergoes major changes. Sometimes API's change considerably killing legacy code, for example. This version of code rot is some of the most frustrating, because it can be often difficult to find.
-- Moondog
Give your application a name like:
- g00pr4.5.5.27-8.22.2.1.rpm
software-title-goes-here-.0.1.2.9.p4.7.3.2.9.9.c7
Add a new version number at random everytime you write two lines of code. This will make you a kewl OSS programmer.
Source code must not be released before the Marketing Department has issued a press release announcing the product, it's advance features, release date, and the company's IPO
However, This is usually done before any code is written.
134340: I am not a number. I am a free planet!
So releasing early helps not only the code, but the direction of the program itself. And its alot easier to build-as-you-go rather than releasing a stable version just to find out its not what users wanted, and then have to change your existing code base.
The maxim that I usually hear used when contemplating when to release source code into the community is, "When it does what it does reliably." In short, mark whatever subset of code is necessary as not ready for prime time, but make sure that it's in good enough shape that you can do one thing with it without fail. So given the choice between expanding features and improving reliability on current features, you should be merciless in choosing the latter. Then release.
Of course, you'll probably find out later that the "one thing without fail" isn't as bulletproof as you think, but it's still a nice thought. Folks are more interested in a project if they can see that it's actually usable for something right now, even if it isn't the be-all end-all.
Simple: Release an outdated version of your source that doesn't work out of the box. Tell your customers that an updated source release is planned, but that every time they ask for it the release is delayed for another 24 hours.
Free BeOS, runs from a Linux partition
I was thinking about what ESR said in The Cathedral and the Bazaar and putting it together with the early Linux kernel - Linus (you know, that guy from Finland) only released the first kernel when it was bootable - and just bearly.
Release early is "A Good Thing"(tm) but too early isn't good - I've seen so many useful and intresting projects die because they were released with unusable code.
All browsers' default homepage should read: Don't Panic...
I'm not a CTO, have no idea how to be. I'm just a lowly engineer in grad school, so I'm in no position to criticize the questioner. I am concerned about his statement:
"'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" It sounds like he is looking for answers that justify his desires, not necessarily what is best for his company or the investors. I would think it would be better to ask the question:
"Are there good reasons to release code earlier rather than later?" then make the decision. Of course some might still want to ask
"Are there good reasons for a commerical enterprise to make available its source code?" (no flaming on the above; I have no opinion and it's obviously not a settled questions)
ShoutingMan.com
... and thank goodness for that. If you're doing a closed-source, or semi closed-source product, then yes, release when it's releasable, or you'll annoy and insult your customers (Cf. Microsoft). If your project is purely open-source, then involve the community in it and release as soon as you have something that compiles. Involvement of the community is always beneficial to an open-source project.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Just my 2 cents. Look at mozilla for another approach :)
Release whenever you want. It matters not.
What *does* matter is how you present it.
If you come out saying 'We are a great company! now we are open source!' and have crap that doesn't work and doesn't run...... well... you're asking for people to complain about you.
On the other hand, if you have a reasonably good product already out, and claim 'we're GOING to be open sourcing it soon' you make people groan... so? Who cares what you're GOING to do? What are you doing now?
Really, if you want to be 'open source', then when you start shipping a product, or delivering it somehow, make the source available under an OSS compliant license to those who you are selling/shipping to.
ALso, there is another question. Are you looking for everyone to help develop (as in OSS project) or are you simply saying you are going to OSS the software?
An extra week is tacked on to the release date every time someone asks for the source.
-- You see, there would be these conclusions that you could jump to
I suppose it should be user configurable whether it grants +1 or -1....
If the intent of a programming project is to make allot of sales of a particular program, or to offer the technology out as a serivce, then open-sourcing early will probably hinder this situation.
On the other hand, if the intent of a project is to distribute a method or technology, then post it up on Source Forge the very first day. The more input and testing, the better and broader the project will reach.
Don't make the mistake that Mozilla made. They released it as Open Source when it was not a viable working program. That's one reason why it has been making slow progress. It's hard to get people interested in something that doesn't work.
As far as waiting until later, that's probably not the best idea either. As long as the program is good and useful, you might as well get the extra hype by making it Open Source right away, to get more users.
Software sucks. Open Source sucks less.
I was noticing the same thing, actually. I've been modded up a couple of times, but I'm stuck at 350 at the moment.
;)
...so is this Offtopic? I'm following the thread, honest!
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
Release it when you have at least a proof-of-concept, and a good design.
...and tell us more! I want to hear about a model where we can take control of our personal information. Heck, I'd like to be able to allow and disallow people myself, and update it sometimes, too, and have recourse against people who sell it without my permission, and...
---
pb Reply or e-mail; don't vaguely moderate.
pb Reply or e-mail; don't vaguely moderate.
I left 400 in the dust months ago.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
What, sort of like doves? Were you planning on using floppies, CD/DVD's, or paper? Either way, you're going to need a stiff wind, and you should check your local littering bylaws.
3.commit to full source code release and release piecemeal
Have you already talked to Kentucky Fried Chicken about this? AFAIK, it will be the first time one of their meals comes with a prize in it, let alone an open-source prize. You may want to consider McDonald's instead, as they have more experience with that sort of thing.
5.placing the code in a provable timed-release escrow.
I dunno... I was sold on that myself, once. But when they came and put it on my lawn, it didn't last any more than a week. Plus, there's some nasty burn marks along the side of the house now. I'd be careful with anything "timed-release". But as long as it's provable...
Mr. Ska
Wow.. I wish a moderator would moderate this up.. this is like the most interesting, truthful, and downright funny post I've seen regarding open source software yet.
Don't take job with any company where the CTO seeks advice on Slashdot.
The real DunkPonch is user 215121. Everyone else is Bruce Perens.
Someone stealing your idea and using it for their product.
Only the State obtains its revenue by coercion. - Murray Rothbard
Cut costs: You can reduce the expense of development both by getting other contributors and developers to help out-- free of charge. Other companies, including companies you don't compete with, could see a reason to contribute code. Show them how much a developer costs (say circa $75k for a good one), then tell them that 10 people who 'volunteer' (or are assigned by their company) are worth $750,000 dollars.
Stability: Fixing bugs and adding features is difficult and time-consuming if the architecture of the product you are using isn't sufficiently extensible, or the code unreadable. Open products have to be easy to modify, so that the project can move at all, so it is easier to add or update the product.
Good marketting: There is no substitute for being the company which wrote the industry standard app for a given market. You pick up the best developers in that market, support people learn your product first, and your brand is plastered everywhere. Even your competitors, if they use your product, become part of your marketting. Finally, the people who make purchase decisions are often technical people who will appreciate the flexibility of having access to the source.
Control of the market: Remember, if your company has the maintainer and most of the developers for a project, you can shape its direction. This gives your company useful strategic control over a market. EG: if you make operating systems, and are dominant in that market (just a hypothetical example), you could redefine the product range to, for instance, include web browsing as one of your product's features. Comparing yourselves to Microsoft will help with marketting/management types.
Simplify HR: A well known and understood open source project is much easier to staff. When an employee leaves, there is no fear that noone will understand his part of the source tree. When you hire someone, they can start working on the product on day one, rather than wasting time training on the details of your proprietary app. Regular, skilled contributors become recruitment material-- a good OSS project will help identify and build connections with great people to bring onto your team.
Open source methodology, if done right, can significantly improve your position in the market.
If you are a small fish in a market with plenty of big corporations, OSS is the means by which you can compete with them-- and win.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Y'know, I'm happy about the success of the moderation test, but a little surprised to get "Troll". Offtopic would have been fine, folks. In case you were wondering, yes, my karma is still unchanged.
Your right to not believe: Americans United for Separation of Church and
Who the hell moderated this to a "Score:2" !?!
Are moderators reading beyond the first two lines? I thought not. This guy says he's jesus, and this is worth my time?
I read at two, because I don't like wasting time on the crap. One, or even zero, is strictly for when I'm moderating. It's sad when this shite gets through.
----
As for my comment on when to release, I would think it would be better to realease at least beta software. I don't see why anyone would want to d/l really unstable software to fix. I always thought the primary benefits to open sourcing software was to provide customers/users with the ability to customize and fix stray bugs - not do core development...
A possible exception would be if you're working with someone to develop the software. Example: I worked on a newly developed relative isotope mass spectrometer, and my boss provided direct feedback on what functionality should be in the controlling sofware package. Now, in this case a source release wouldn't have really mattered, because a) only a couple machines existed at the time and b) my boss didn't code. If it had been a more widely used product, and there were users who would potentially want to customize NOW - I would think it to be good to release. Again, however, this suggests you have at least a basically functional product.
So I just went in a circle. Oh well.
To paraphrase Signal 11: Look on Taco's face when I +2 first post for as long as I like: Priceless
I dunno--I only had it for a few minutes. I really really wish there was an option to change nicks because I'm sick of this one.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
As I see it, most of the successful open-source projects (Emacs,Linux,Apache,Perl,Python
Ciao
----
FB
I'm a little bit confused as to what this question actually is. The author claims to be asking which method is best for open sourcing software, then goes on to explain this is for "Open Source-leery business types".
Is this a question on how to trick the CEO into agreeing to open source a product? If so, I got a great answer.
You explain that the technology is so revolutionary, that if you were to release it without having it be open source, the company would be declared a monopoly and be split up, similar to Microsoft.
Then, while he's got that on his mind, bring up the fact that your competition is going to be rolling out a product that *isn't* open source, so by open sourcing your product, you are expecting flocks and flocks of sheepdotters to try it out.
Now, if this is a legitimate question, the only sensible answer is to wait until you have something that works.
The best way to go about doing this is to hold a meeting and come up with the main things that would make the product profitable and put them into a list. Businesses do this all the time, and with open source it is no different. Explain that the product must be able to do these things before it will be open-sourced.
Then, when code has been written that meets all the requirements on the list, go open source. Then, check for feedback and request info from the customers on new features they would like implemented in future versions.
Check out which features can be implemented in a set timeframe, hold a meeting and come up with another list. Implement all those features and release again at the end of that timeframe.
Depending on the type of product, the timeframe for implementing features will vary. A good idea would be to at least keep everyone up to date with a "State of the Code" address once a month if your release time is a half a year or more, once a weeak if your release time is once a month or once every 3 months.
If you plan on releasing source more than once a month, this model might not work well. You'll have to look at another one, perhaps not marking down features that you want to implement, but keeping track of where you are at on a particular feature.
Why are you releasing your source? Is it because you want people to develop it along side your in-house people? Or is it because you want it available for peer review/bugfixing? If it is the former, then the earlier you release it the better. If you wait until the project nears release then there will just be too much code for developers to wrap their brains around. If you release early then people will be able to grab portions of the project to work on and enhance.
OTOH, if you merely want to release your code in order to allow people to fix bugs, find holes, etc, then you better have something that's both usable and well documented (on a source and end user level).
I would prefer to see the code released early so the actual development can take place in an open source environment, not just the maintenence.
noah
That way you can blame any bugs on those "damn open source programmers that keep screwing with the source tree."
nWo 4 Life
At least that is the approach I took with GridSlammer, and it has worked out very well.
Thad
The Bolachek Journals
I have a small project right now that I release code whenever I do something that merits a release - namely figuring out how to get something to work. Unfortunately I have not had a lot of time to work on it lately, but that is another matter.
When I got something that was in the "it kinda works" stage, I put it out there. Have had 40 downloads so far. Nobody has contributed or submitted bug fixes - probably because they are not sure what I am talking about - but I continue on.
However, the program I am working on is not anything that is mission critical and the specs are not going to really change in it over time. There are no databases or anything like that. Therefore I don't think I have too mucht to worry about if I did release "v0.00001" code.
While writing this comment I got to thinking - even if my program was mission critical and it did have a spec that could change, wouldn't releasing v0.00001 be a good thing? Doing that would be a great help in allowing others to pour over the design specs. Even releasing pseudocode would be nice at the early early stages.
I currently have a very similar problem. I am working on a project to unify the APIs for the decoding of media data (currently audio and video streams). While the API is probably very unstable and the code wont be finished in the next months, I decided to publish at least the APIs yesterday and will probably commit the remaining code into the CVS next week (libmedia.sourceforge.net). Why? Because there are at least 4 projects with somewhat, but not completely different goals, and I want to avoid doing redundant work. In fact avoiding redundant work is what my project is all about. So I decided to post the APIs and started some discussions with authors of the other framework only to get sure that there is not too much duplicate work and in the hope of getting some feedback. Of course I am not going to put out tarballs with the code, do announcements or let anyone else work directly on it, because it is WAY too early for this. But unless you want to keep a "competitive advantage" it is a good idea to let other people look what you are doing.
A few point to ponder:
Open source is great a a large number of areas, but are you sure that it will benefit *your* company? As a startup with seemingly adequate funding (giving engineers a monthly 'toy allowance'), you are working in a domain (internet client/server) where brands are not built as easily as a few years ago.
What are the long term business plans? Do you want to get bought out...well open source may provide a barrier.
Hell, if your running on VC money, open the source now. Everybody should spend a day with new client/server tech written in Java.
Ever been asked about a new technology by a manager or corporate officer. What is it? How's it work? Can we do that? Your simply making the answers easy.
Before you take the responses you get here back to your company, ask yourself who these respondents are. If you don't know they answer, you better find out. As much as I respect my 6 and 8 year old nephews, asking them for business advice would result in the first Dragonball-Z vs Pokemon word processor dump truck application...in 3D, for free, packaged in a big metal box with a million billion dollars in it.
As you flip through you new printout of the Cathedral and the Bazaar, ask yourself "has ESR every built a company?" Do not confuse the idle ranblings of a philosophy grad for a business plan. Sure he's a paper millionaire, but notice how VA has toned him down and practically shut him up? He's their bitch now. Bought and paid for, recipts will vest later.
Is this new? Because otherwise it would be impossible to get karma > 50 other than by submitting stories. And I'm somewhat over 50 :)
50 seems pretty low, but maybe that's just from my lofty perspective. I recall karma whoring before there was a name for it. And I'm not nearly as prolific as some people...
Your right to not believe: Americans United for Separation of Church and
Gorkman
As early as possible if not sooner. Have a look at pmt.sourceforge.net/exif (a project for storing Exif camera data in PNG files) which I released several days ago before writing a single byte of code. Code writing won't start until the project is specified.
...release the code at the same time you release the finial 1.0 version. That way, it will already be on the shelves so the bugs will be fixed after you've had a chance to make the money, and the new and improved version will be out there for users to buy all over again!
Warning: If you do this, you might be sued by M$ for copying their distributation scemes
So quick with fear you tiny fools!
This is very new. They tried to make a "karma limit", but in doing so froze those of us with karma>limit in place.
Consider Our Hero, Linus. The first time he publically announced linux, in comp.os.minix, he had a boot disk that you could download and boot up into a shell. I downloaded 0.12, and it did work. It didn't do much, but you could see the potential, and could tell that the author wasn't some poseur.
If you release too early, hackers won't take you seriously, and thing that you are just another wannabe.
Hate to say it, but Netscape is a failure. They can't keep up, no one is stealing from it. They are not a failure from Open Source, but from lack of new features. People want new features.
Got shack?
ShackCentral Network
Worlds best gaming network!!!
If you are a commercial organization, don't release your product until it is finished. First impressions are everything.
With Open Source, you will not be able to control how the software will be presented. No matter how much you emphasize the fact that the software is unstable and alpha quality, some bonehead distribution will include it with no warning. With no foreknowledge that your software is buggy, crash prone and unready for use, your potential customer will have their first impression be that of your software dumping the X server or corrupting the file system.
A Government Is a Body of People, Usually Notably Ungoverned
Public source release "can" be done release -1 if it is essential to "protect" your product and it's market. Otherwise - go public when the leadership team fells "most comfortable" with HEAVY bias toward "sooner" rather than "later".
My 2 cents: Within 6 months of first release.
But - that's just MY opinion. I'd rather see a slow release than NO release. (Ya listening MS?)
T_O_M
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.
It's difficult to find good evidence on both sides of the argument for Open Source. For the record, I'm definitely in favor of open source (especially if your company has no competency in software). In any case, I've included some pieces of evidence, not necessarily in favor of open source per se, but perhaps a bit more generally about dealing with an open community with regards to development.
Actually an overview of "The Sims" before it came out, but the end of the lecture discusses how they used immediate Internet feedback to improve the design of the game.
Hidden in the depths of the FAQ in the section "What CORBA implementation is GNOME using?", is a comment about how Xerox's implementation of CORBA was not used. If this had been open sourced, Xerox's name would be associated with an important part of one of the largest software projects around.
I apologize if I've being repetitive, but I didn't see this URL earlier. Anyway, this site has some very good arguments in favor of open source. You may wish to take what they have and modify it slightly for your specific purpose.
Conferences like O'Reilly's Open Source Software Convention, LinuxWorld Expo, open source projects like Apache and MySQL, and sites like SourceForge and IBM DeveloperWorks are showing that Open Source Software (in some cases) is becoming quite mainstream. If you have even one really cool project, that's advertising that no budget could pay for.
Well, I hope this helps.
-RayThe primary advantage to Open Source is distribution of effort, the primary dangers are diffusion of purpose and logarithmically increasing communications overhead. Release time needs to be a balance of these.
Unless I'm missing something (been known to happen, of course) there are three basic reasons for open sourcing a project.
The first and foremost is to allow code-savvy users to hunt down that niggling bug, fix it, and send you instructions on how to adjust the code base. If this is your intent, then releasing it before Beta is just asking to have everyone who picks up a copy of it saying "hey, wouldn't it be great if the code did _THIS_?" It is impossible to resist ALL of these, especially when the person offers to write it himself, and then you're stuck integrating it into the whole. Suddenly, the beta is pushed back six months to a year while you tell yourself that it'll be well worth it when the product eventually gets released.
The second reason is because you're trolling for developers. If you're not too terribly picky about what goes into your product, this can be a great way to get some free work out of the Internet. In this case, you should probably start by publishing a few of your design plans, then releasing the code to coders who show Interest, possibly having them sign a non-disclosure to prevent them from running off and founding their own company with it. Free (speech) doesn't have to be free (beer).
The third reason is as a publicity stunt. In this case, definitely wait until just before you have a sellable product (post-beta, pre-release). This gives you a well-timed media boost, and gives the purchasers the warm fuzzy about their ability to work with the software on an up-close-and-personal basis. This is also the optimal point to start getting "hey, with a little effort, it could do this" kind of information, which can be blissfully rolled into the 2.0 release.
Mythological Beast
Wake up - the future is arriving faster than you think.
By making a project open source, you don't just gain hackers adding more lines of code. You also gain the input of philosophers, code evangelists, people with great ideas, artists, and the like.
----
Celebrate the finer things in life
If you're being a good Peopleware people, and have spent the Mythical Man Month in the past rewriting crappy designs, you might want to start your project by writing a complete design, and releasing the design for comments BEFORE you write the code.
If you have written a coherent design, and it has been reviewed and hopefully added to by your peers, the code will come rapidly, and will be less painful to change over time. Also, I can't help noting that it's a lot more satisfying to do something technically sweet, even if it takes a little longer to get to the coding stage, and have some chance that it will actually be used by others.
If it is a commercial product that is to be open-sourced, make sure that your revenue model for the product is such that you DON'T CARE if other companies like you take the code (or the design) and run. If, for example, you are writing the world's greatest encrypted email server, you might want other entities to charge for the same thing you charge for, as long as they register their servers so that you can show that your tech is gaining market share. Open-source products with commercial possibilities can't rely on the "we have the code, you don't" advantage as a startup revenue model, it defeats the purpose of open source and will only lead to painful arguments with the business guys.
bild, www.categoryweb.com
Bazarr ESR says that you should release as soon as you have a working version. I'm thinking *very* late alpha early beta here. It gets people early but also late enough that they can see that this will be cool.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
To get the full benfit of Open Source development you may prefer to release as early as you have a stable beta. This allows you to have a wide range of Beta testers, and in the Bazaar model, real world troubleshooting and feature evaluation. But, the trade off is you never get to sell the software. There are a number of commercial apps that I know of and use here at (Unspecified Government Agency) that have excellent (and expensive) consulting services for implementation and customization of those applications. If the application that your company is developing lends itself to those services then your business model is: The application is in effect a marketing tool for the consulting services that actually brings money in. This works best if two things are true: a) Your consulting services know your product best and b) you have the capacity to satisfy demand. Open Sourcing your software can make your software much more widely used, thus increasing that critical word of mouth factor. I know that in purchasing recommendations I have recommended for or against use of a product because of the size of the user base of the product. If I've never heard of an application and it isn't used in more than one or two major places, I won't have confidence in continued support and development. This is what I think is the biggest strength of OSS, 'The cream alway floats to the top.'. OSS by it's nature can not prevent bad software, but without the use of monopolistic (and I'm not just talking M$ here) marketing bad software doesn't get used. The greatest weakness I see in OSS is dealing with responding to the customer's needs in development; this mechinism is just as important as keeping you code clean if your software is going to continue to be viable.
Spyder
Triple digit!? /3/ in the four or five months I've been on. And I've posted some pretty profound stuff too.
Gosh, I still haven't gotten past
Oh well, at least I got moderator access twice in the last two weeks. ( but the first time I didn't use it and let the 3 days run out, 'cus I was too busy posting in all the good discussions )
Ever get the impression that your life would make a good sitcom?
Ever follow this to its logical conclusion: that your life is a sitcom?
"I don't care about the Constitution!" --Bill O'Reilly, November 17, 2009
Ask Netscape. They perfected the business model for incorporating open source into a realistic project. [snorts then bursts out laughing][/sarcasm]
Love,
Bongo
Making software Open Source is always a great idea due to feedback, helpful developers, your way of saying "You can *see* that it's not a bad product" and a bunch of other stuff I could mention but it's Friday so I'll hold off.
As to when it would be a good idea to open source it, I would think waiting until it reaches a comparable state with competing products would be the best time. Releasing the source code for a product that couldn't match a competing product just seems like a waste because no one would want the source code anyway, and would probably make you look like you were on the Open Source bandwagon.
I think the best time is when there is enough interest in it from parties who could use the "other guy's" product in your own. But that's my personal opinion. I suppose it also depends on the code. Look at Enlightenment for example. Their version number (although I would say a little off) implies that the wm itself has a long way to go yet, but E is a great wm. I would say it's not a certain stage in development, but a certain stage in the maturity of the project.
"It's here, but no one wants it." - The Sugar Speaker
This is likely to get the most OS programmers interested, especially if your product has a high "cool factor". Let programmers know during all the release hoopla that they can start hacking on the code now.
2. waiting until the technology has acquired a large enough user base to insure a competitor won't just 'take the code and run',
If this is your concern, you'd better think again about your company plans. Heck, Microsoft didn't need Netscape's code to hijack their market dominance. Don't rely on your software to bring in the bucks. Use the software as a loss leader, building up other aspects of your business like consulting, documentation, easy installers, etc.
More pragmatically, think of the GPL instead of a BSD-like license, which actually protects you against this sort of thing. No one can "steal" your code because they are forced by the GPL to make their modifications public.
3. commit to full source code release and release piecemeal (ala ZeroKnowledge),
Not sure what this means... But see below
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."
Programmers are finicky, and it helps if they can start hacking with as little frustration as possible. If they know that they won't get access to all the code, or that their patches might not see the light of day for over a year, they may not want to contribute. Of course, if your stuff is so cool that people are willing to put up with frustration, you might get away with it.
However, Ghostscript shows how finicky programmers can be. Because (at least in part) of the time-delay release of the Alladin Ghostscript code for public use, GNU Ghostscript was started.
David- ------------
------------------------------------------
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Of course, Klingon software engineers advise that code should not be released. When it is ready, it will escape, leaving a bloody trail of marketing types and QA people.
A while back, on Freshmeat, I saw a project that had no actual code development done yet, but thorough planning and design. I thought it was great that they were bold enough to submit an app to freshmeat when there was no actual app to use.
-------
Oh shit! I forgot to click "Post Anonymously"...
wait untill it can run and not crash after 2 minutes, say, late pre-beta
I venture to guess/postulate that this question was a "cunning plan" to attract attention and IPO interest.
Guy posts under easily identifiable name. I put 2 and 2 together and take a look at www.meconomy.com. Woohooo, a "infomediary" startup in "stealth mode", with a product real soon.
What better place to advertise this than on slashdot? It's not just for people involved in the technical side of computing these days now, you know.
Oh well, back to Mortyr. There's something 'bout the game I like, even if I'm generally considered to be a nice person. I like alsatians, could that be it?
On the other hand, consider releasing a polished product as "beta". Potential customers will be impressed with the quality of your work ("Hey, even their beta code is solid!") A good rule of thumb might be this:
Don't call it beta until it's good enough for you. Don't call it finished until it's good enough for the rest of us.
A lot of the "Enterprise" features are in the Linux 2.4 kernel... It's "Not quite there yet" but it's comming... For now you use Solarus who is there.
In this same line it could be said the open source busness plan is comming with the 2.6.. It's still a ways off and a lot of people are working on it. But it exists like a bunch of kernel patches that are stampped "Beta".
A considerable number of open source companys have problems while many are quite successful.
The diffrences between the successful companys and the failures seem considerably small.
Open source is a compleatly new approch and it might be best for larg companys to sitback and watch or throw out test projects and see what works. Leave it to hobby companys and the sereous advocates to bang out the trubble spots.
As for the using side... Preinstalling Linux on specally made servers or just using free software is a very successful method.
Using free software was a way companys secretly cut costs.
Instead of hiring overseas or buying cheapper equipment companys could simply download free software and cut costs but not quality.
If an existing open source product isn't up to stuff for your company sick your techs on it and make it up to snuff. The small amount of R&D costs save you in the long run plus you get a small amount of premotional from the open source (not Slashdot but you may ask for a mention in the credits for the program).
As a rule if you can not see a clearly suppereor proffit moddle in open source it may not be the best choice.
Open source software develupment as a proffitable venture is a new deal and no one is really clear how to go forward.
There are no bullet proof arguments for open source. They arn't any against open source. For now your best hope is to explore and not dive right in.
Open source examples, samples, tools etc. But leave the main body closed. For now.
An example of this... With Microsoft Windows open sourcing Visual C++. Visual Basic, Internet Explorer, Dos 8 and Windows 3.11 while keeping Windows 9X, NT and 2K closed would be a bold move present a great deal of free press and get a lot of sales for 2K.
What this dose....
Dos 8 and Win3.11 could give new life to old computers giving poor users cash strapped schools and hobby develupers a chance to use the more stripped down low load operating systems on XTs,[2/3/4]86s, and load intesnive software develupment on Pentiums
IE is allready free giving away the source would give develupers a chance to finish off where IE is lacking.
Visual Basic and C++ would give a free foundation for free and comertal software develupment.
I myself have not quite understood the logic behind selling software develupment tools for your own platform.
Back in the 1970s computer makers PAID software develupers to port software. Selling software develupment tools adds an additional road block for getting software to market and frankly thats not good.
All this generates goodwill and press for the opensourcing company. So long as there is a clear revenue path.
I myself am aiming for the folowing busness plan:
Give away the software.. tech support by web forum.. make money on banner ads.
The idea here is that I've got you comming to my website to read news, information and download software. What I don't make in direct sales I make up for in bulk.
In the mean time I save money on marketting, sales etc and focus primarly on product.
This is far from ready sence I'm still just working on the web forum code. That is also open sourced.
In a few years I'll have an acuall product to give away. Then we'll see how well my plan works.
But if it dosn't... Then I'll try something else. Far from rock solid. This is an experement as are all open source busness modles.
We can only wait and see who haves the best...
Right now I'd say the Slashdot/BSI/EveryDev busness modle is the best shot. (Not the Slashdot/Andover "Buy success" but Slashdot/BSI/EveryDev Build it and they will come.. and when they come.. get em with banner ads).
I don't actually exist.
. ! it can't hurt to have extra experienced eyes running through your code at the early stages. 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. selective early release, where only some people see the code and help, and then general release after it's matured a bit.
- ---------------
don't you think that's an odd comment to make about it? isn't there a practical application here? put that way, it's a bit too general to fully agree or disagree with.
this isn't a flame. i've been willing to be part of testing mozilla, and i love it. but most consumers aren't so forgiving. -waldo if you don't, then i believe you'll be pulled in all directions by the rest of us. --mike-- -- dumping beta oss on the public to avoid paying for a qa team results in low quality. 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.
i'm not sure i agree -- consider the converse argument. when you look at the whole matter objectively, any issues seem almost bound to sort themselves out. you don't want to throw the baby out with the bathwater.
-----------------------------------------------
a lex chebowan (alexchebow@yahoo.com)
Subtract a week from the release date every time a constummer asks marketing for a release date.
The inital release date should be generated by the CFO who knowing he dosn't know will throw out a reasonably far distent date that wouldn't strain the budget to badly (as thats what he knows).
Then open lines to marketting and techs and let the users push the date around.
Release about 2 weeks late while issuing apologys that gain extra press.
Open source, IPO, Sell your shares, Quit.
Leave in hands of the genous who should have been running things from day one.
5 Years later go to work for resulting company as a consultent.
After 3 years declare your to old for this stuff anymore.
Wait a year for the company to become a global empire. Write a book "How I built GlobalCor" even thow you didn't.
I don't actually exist.
If you are hoping for people to help with development and/or bug fixes, then a late release of the developed code is okay, because during the earlier stages there probably isn't enough of an end product for users to use and get interested enough in to become involved in.
OTOH, if you are interested in getting feedback in precicely what your market wants and needs, then an early release is good, because it lets external people into your decision making process about the product.
You should note, though, that it is unlikely you will get development help from people at the start of the project unless (a) your product fills a need or interest that a lot of people who code for fun are into, or (b) you can form partnerships with other companies to have paid programmers working on it.
For example, if you decide that you are going to build an open source Just-In-Time parts management system, it is unlikely that many people will hack on it for fun if there is no code already written. However, if you write it, then open source it, many companies might be interested in paying someone to help with enhancements.
However, if you annouce your intention to produce this JIT system in industry papers, etc, you might get lots of well qualified people signing up on your mailing lists and giving you advice that is simply unattainable elsewhere.
This is a commercial Open Source project.
So since it is commercial (read: based around a business that must make money) you need to maintain your commercial advantage in some way. As has been outlined in many other articles scattered around the web, you can maintain your advantage in many ways (programs, marketing, etc).
My suggestion for building a commercial Open Source project are ...
If there is a commitment to going Open Source, work out where the opportunities exist to begin to build the community around the project. This MUST be balanced by the business aspects of what you are doing.
Going step by step is not bad. Plan, balance it against good business sense and do it as early as the Openness of the code begins to balance against other aspects of the business.
Best of luck, and welcome to your company to the commercial realm of Open Source!!!
I once tried to begin an open-source project with only an idea, no code in hand. It died from lack of direction with out line one of code ever being written.
Don't do that.
Instead what you do is do what Linus did -- get something out there first, and *then* open it up. You'll get a lot further that way.
/Brian
I know, but I bought the (cheap) upgrade from R4 just because of Realplayer and CDBurner (which doesn't work for me :( ). Waitin' for Flash and Java!!!!
Free BeOS, runs from a Linux partition
Aw crap, and I'm 2 points away from the freeze point... 2 points and I could troll all I like... d'oh :-)
You are in a maze of twisty little relative jumps, all alike.
Nope, you can't even go up by submitting stories. I'm just a tad over 50 also, had a slashback accepted today, no points, no change. Frozen stiff.
1) Does your karma go up when you submit a story, regardless of whether or not it's accepted?
2) How the hell do you people get up to 50, or 650, or whatever? Mine's been stuck at 12 for weeks. Do you just mod yourselves up with other accounts? Not EVERYthing you say can be +5, Insightful!
Email me.
Don't trust anyone over 90000.
+++ATH0
My karma is 12 points behind -- I'm stuck at 122, and I'm a little upset about it. I asked CmdrTaco about it, and he told me:
;)
Nope. Not a bug. Code revision
(I hope that he won't mind my reproducing his comment via private e-mail in a public form. It seems like a harmless enough thing to reproduce, as bad 'netiquette as it might be.)
What in the world is going on?
-Waldo
-------------------
"Not EVERYthing you say can be +5, Insightful!"
Yeah, but a lot of it can be +1 Insightful, or +2 Funny, or +1 Interesting, or +3 Informative. It all adds up.
censorship is a form of noise, which actively seeks to drown out content with silence - Crash Culligan
I had asked him too, stuck several points behind where I was... similar response. Then I had a story posted, and my karma dropped to the previously indicated 50.
--
"It's tough to be bilingual when you get hit in the head."
What is the Pr that FascDot killed?
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
A bit nasty (I liked being in the 100+ club, dammit, and with no karma whoring!) but probably necessary.
Ah, well. It's only karma.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
Yeah... being around for a log time, I had slowly built up my karma (the most in one day actually being the day of the cap)... "Whore protection" I think was the catch phrase of the minute when I mailed.
It is only karma, and since it hasn't been world viewable... oh well... I don't feel any less of a man/geek, but it was nice 8^)
--
"It's tough to be bilingual when you get hit in the head."
1) no... 3 points for an accepted story. Otherwise the queue would be even more unmanageable than I can imagine it already is.
2) Some move quickly, others slow. I used M2 (back in the good ol' days) to get a point a day until ~25. Then, responding with semi-useful info to AskSlashdots and other articles garners a point here, a point there. Heck, if your karma increases by only a point or two a week, you could have 150 karma easily.
Well written bad haiku are also useful to catch a few (1, Funny)s and (-1, Offtopic)s... they ususally balance out to ~+1.5/ haiku in my experience - YMMV.
If you want to whore with the best, include obvious general statements and bash M$ (or Micro$loth, MicroSuck, etc) and praise Linux, Apache, and Open Source. I like to ease off a little tension every now and again, which usually costs me a point or two for noting that someone is a complete idiot (that's the toned down version).
--
"It's tough to be bilingual when you get hit in the head."
>log time
oops... s/log/long/
--
"It's tough to be bilingual when you get hit in the head."
A bit nasty (I liked being in the 100+ club, dammit, and with no karma whoring!) but probably necessary.
Why?
Who cares if somebody has high karma?
Am I missing something?
Browser? I barely know her!
Self-set goals.... feeling that you are somewhat appreciated by somebody... somewhere.
Oh, that and geeks like to hoard things. Points, especially.
--
"It's tough to be bilingual when you get hit in the head."
I understand that.
/. users have high karma?
What I don't get is why there is a need to cap karma. Why does CmdrTaco care if
Browser? I barely know her!
Guess the thought was that people were posting just to get karma, instead of trying to be helpful or useful... I dunno... if somebody gets a laugh or learns something from it, it's probably worth posting... if it doesn't make someone laugh or tell someone something they don't know, then it shouldn't be getting any points, and if it does, there's M2...
I can understand not having karma publicly available, but it is unfortunate that things had to go this far (though I'm not really convinced that they really had to).
--
"It's tough to be bilingual when you get hit in the head."
CRAP! Earlier this morning karma = some large number, now karma = 50. Dagnabbit.
Your right to not believe: Americans United for Separation of Church and
You can still get to the freeze point. Worksferme...
Interesting way to think of it all, isn't it?
:) Open rebellion is needed. It doesn't pay to be a nice guy and not throw dung at the other monkeys - and hay, if I can keep my high Karma while flaming and pouring hot grits down Natallie Portman's pants, all the better. :)
The "Karma Whores" are frozen with their high karma. But this implies that everyone who got modded up past 50 is a Whore.
So to not be a Whore, you have to flame and troll for each time you are insightful and informative?
I see where this is going. I guess it's time for a little YANG, now that all YIN and no YANG doesn't pay.
-- What you do today will cost you a day of your life.
You no longer get the warm and fuzzies of seeing the cummulative effect, but you can still strive to have each and every post modded up. You just can't keep track very well.
:) It's a little contest that sort of sprang up.
:) Aristotle might have a little bit to say about that.
As for the drive behind getting more Karma, I thin kyou're right on. We're a bunch of pack-rats, and Karma is sort of like the AD&D character score.
In retrospect, Karma probably should have never been counted. It's where we are now, minus that little unchanging number. A comment deemed of worth still bubbles up.
As for the argument that people post only to score points... Well, don't they always, in one way or another. Karma is just a little more tangible than impressing people and earning their silent gratitude. Are you suggesting that the motivation for an action matteras as much, or more, than the action itself?
-- What you do today will cost you a day of your life.
I guess I'm done submitting stories. Oh,well.
-Waldo
-------------------