When Should Source Be Released? 142
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. . .
Knee Jerk Response (Score:1)
--Threed-Looking out for Numero Uno since 1976!
My experience (Score:2)
Read your ESR (Score:4)
--
early is definitely good. (Score:5)
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.
Be Careful of Mozilla / Java Problem (Score:5)
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 (Score:3)
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. (Score:5)
Early and often seems to be good except for the pull into other directions.
--Mike--
Release early, release often... (Score:2)
Stability and User hacks (Score:2)
When? (Score:1)
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.
It all depends on your goal (Score:2)
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
--
whatever you decide (Score:5)
--
Peace,
Lord Omlette
ICQ# 77863057
Early vs. Late (Score:2)
The Magic Cauldron (Score:5)
It's a very well written article, has some examples, etc.
something to consider (Score:5)
Of course IANAExpert.
Re:early is definitely good. (Score:5)
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.
Sooner better than later (Score:2)
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
A tip... (Score:5)
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.
Release Policy (Score:2)
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.
Not just about code (Score:2)
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.
Acceptable feature set, rock-solid reliability (Score:2)
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.
Release the source? (Score:2)
On second thought (Score:1)
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.
Looking for what you want? (Score:2)
"'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)
Linus hasn't waited to have a beta kernel (Score:1)
Release stable but featureless (Score:2)
Just my 2 cents. Look at mozilla for another approach :)
Release (Score:2)
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?
According to Malda (Score:2)
need new catagories (Score:2)
I suppose it should be user configurable whether it grants +1 or -1....
Depends on the licence, and intent of the project (Score:2)
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.
Release when it works well. (Score:2)
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.
Re:Attn Moderators: Public Karma Test (Score:1)
...so is this Offtopic? I'm following the thread, honest!
---
pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
Re:Release the source? (Score:2)
Re:need new catagories (Score:2)
Release... (Score:1)
...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 [ncsu.edu].
Re:Release the source? (Score:1)
(Hint: Go download BeOS4Linux.tgz, unpack it in /beos, and give it a try... works great, no Windows necessary!)
Re:Release the source? (Score:1)
Re:early is definitely good. (Score:1)
Re:When? (Score:1)
Repeat every 50 years with the newest forefront of technology. Railroads, Oil, Cars, Telephones, communications, Television, Computers, what next?
Remember: if it breaks often, but not too often, those silly costomers will be begging to buy more. It's called planned obsolecence, get used to it. I like open source, but unfortunately, greed is what will rule the world forever.
400? (Score:1)
--
Re:Be Careful of Mozilla / Java Problem (Score:1)
- he had an interesting and potentially useful point
- he didn't attack netscape, mozilla, java, or sun
how was his post a flame?
open-souse opinion [hic!] (Score:1)
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...
Ain't it the truth? (Score:1)
Note to self: (Score:1)
and (Score:1)
Re:400? (Score:1)
--
Benefits to opening quickly (Score:2)
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.
Re:400? (Score:1)
I've always wondered - what was your previous nickname (the one that FascDot killed)?
It depends (Score:2)
Re:Attn Moderators: Public Karma Test (Score:1)
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.
Re:there are advantages to an early release (Score:1)
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.
Re:Attn Moderators: Public Karma Test (Score:2)
To paraphrase Signal 11: Look on Taco's face when I +2 first post for as long as I like: Priceless
Heh (Score:1)
--
possible recipe for open source success (Score:1)
As I see it, most of the successful open-source projects (Emacs,Linux,Apache,Perl,Python
What is the question? (Score:1)
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.
remember why you're releasing (Score:2)
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
Release Early! (Score:1)
Alpha or pre-alpha release (Score:4)
At least that is the approach I took with GridSlammer, and it has worked out very well.
Thad
I think it all depends, myself.... (Score:2)
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.
Re:Benefits to opening quickly (Score:1)
Method to find new talent: If someone contributes particularly noteworthy additions to your code, it would be in the companies best interest to bring them in for an interview. The beauty is, the first step of the hiring process is free: skilled people with demonstrated work with your product are being pre-filtered by the coding process.
Contributions are more important than the release (Score:2)
Re:whatever you decide (Score:1)
The end product will be free to use for the 'geeks', so tell me why I should be forced to pay for testing, then giving the program away to the people for free. I think that the people that will later use my program for free can sure as hell help me with finding bugs and flaws.
Bibos
Re:Be Careful of Mozilla / Java Problem (Score:2)
A lot of people will say, 'release often, release early', etc (particuarly with reference to the linux model). I personally always feel that people ignore the amount of work done on GNU prior the the Linux kernel being released.
Linux was, to a fair extent, born full grown, in that there was a full UNIX just sitting there, waiting for a kernel. This let Linux explode off the blocks, and gain a lot of momentum. (Okay, 10yrs or so is quite a slow burn for me to use the term 'explode', but hey)
I am interested in OS development. So many great projects that seem to burn out as people seem to lose interest, as the project grinds on slowly. The more people drop out --> the less work getting done --> the less results seen --> the less enthusiasm --> more people drop out...
Very saddening to watch projects die this way.
G
Re:early is definitely good. (Score:1)
Have you really thought this through? (Score:1)
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.
Re:Attn Moderators: Public Karma Test (Score:1)
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...
Do it ASAP (Score:1)
Re:Note to self: (Score:1)
In the planning stage (Score:1)
Re:early is definitely good. (Score:1)
I don't follow this -- why can't the people who want to run it for free download it when 1.0 comes out? How are they filtered out? Unless you're saying he should release the pre-beta but not the final releases, but that's hardly "100% open source".
Not flaming -- just confused.
If you want to make the Businessmen happy... (Score:1)
...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
Re:Attn Moderators: Public Karma Test (Score:2)
This is very new. They tried to make a "karma limit", but in doing so froze those of us with karma>limit in place.
You can release too early (Score:1)
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.
Re:Be Careful of Mozilla / Java Problem (Score:2)
The lesson I'd draw from Java and Mozilla is, "Release early, release often, but don't start issuing press releases about how Microsoft is doomed until you've got something that runs."
Linux was, to a fair extent, born full grown, in that there was a full UNIX just sitting there, waiting for a kernel. This let Linux explode off the blocks, and gain a lot of momentum. (Okay, 10yrs or so is quite a slow burn for me to use the term 'explode', but hey)
I think the 10 years is at least as relevant in this context as the existing Unix infrastructure. If the Linux project were started today, you'd see Eric Raymond in CNet, Wired, Upside and People blaring about the glorious prospects of Linux -- followed by "Death of Linux" articles two years later when a fully functional OS wasn't shipping.
So, to MEconomy I'd say, "Release early but hype when it works."
Re:How about never? (Score:1)
Don't Release Until It's Done! (Score:2)
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.
"Why" is more important than "when" or "if" (Score:5)
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.
Why are you open sourcing? (Score:2)
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
Re:When? (Score:2)
Well, actually, what you call it depends on your mindset.
Big corporate mindset:
--Phil (Not that any of my projects even have enough code to release yet...)
Re:whatever you decide (Score:4)
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.
It depends on the nature of the project.. (Score:2)
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.
----
Re:whatever you decide (Score:2)
Nobody if forcing you to do anything. Hell, nobody is even forcing you to make it Open Source!
You are certainly free to do no quality testing. You are also free to be a fool. If you are a commercial OSS firm that pays for development but does not pay for quality assurance, you have excercised your freedom and proclaimed yourself a fool.
Software that is not professionally tested is not professional. It should remain in the realm of hobbyists.
Re:early is definitely good. (Score:2)
they will do so when 1.0 comes out, but the ratio of real developers to curiosity seekers would, theoretically, be higher with early releases, since the interest level would more apply to them.
as for the "stealing your ideas" branch of things, the idea of building one-of-a-kind proprietary software with the open source model is new to me... i couldn't really tell you how it would work out.
Re:It all depends on your goal (Score:2)
Rational discourse demands a common set of terminology. Communication cannot occur unless meanings are known. Intelligent people will either use the dictionary or present a rigid set of definitions.
The Free Software Foundation has not presented a rigid set of definitions of "free software". They have only four very loose and broad "freedoms". On the other hand, the OSI has presented a rigidly defined set of standards and meanings. It is no wonder that intelligent people use the term "Open Source" when referring to software whose source is open.
Every piece of software (and I mean every single one) that meets the Open Source Definition also meets the loose definition of free software put forth by the FSF. Freedom to run the program, for any purpose? Covered. Freedom to study how the program works, and adapt it to your needs? Covered. Freedom to redistribute copies so you can help your neighbor? Covered. Freedom to improve the program, and release your improvements to the public? Covered.
Of course there is the possibility that Open Source can be confused with source code that is merely available for perusal. But there is equal or even greater confusion in the public to confuse free software with freeware. To the average intelligent user with a dictionary, the term "free software" means software that is free of cost. I don't know languages other than English, but I have been told that "libera softvaro" is pretty much meaningless out of context.
But just what is this "freedom" you mention? There is no definition for it in the FSF pages, so I must resort to my dictionary, where I find seventeen definitions, many of which are contradictory. Which one am I to use? Is the "free" in free software related to "free electron"? "Free party"? "Free verse"? It surely can't be the "free" in "free speech" or "free press", because those freedoms give me the right to create and publish closed source and proprietary software!
But you are correct when you say that the goal of using the term "Open Source" is not some vague and ill-defined freedom. The goal is instead clarity and understanding.
Re:Heh (Score:2)
--
Klingon code (Score:2)
Re:early is definitely good. (Score:5)
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
Open source busness plan (Score:2)
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).
Re:whatever you decide (Score:2)
That businesses are saying this is our own **** fault. How many times have you seen "Free beta testing and bug report and submitted patches by the community" in the bullet list of why companies should open source their stuff? What are they supposed to think? What they are going to think is that we are a bunch of liars when they go to the trouble of opening their source and we tell them that we aren't going to do their QA. That will certainly engender maximum trust in the open source philosophy.
I understand what you are saying, but I think we need to get our own propaganda straight.
--
Depends what you are trying to achieve (Score:2)
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.
Re:When? (Score:2)
-- Abigail
Re:Linus hasn't waited to have a beta kernel (Score:2)
Not every open-source project needs to be made for "the community". Open source just means source is available - but that does not mean the project is for the benefit of "the community" (whatever "the community" is). You could write a brokerage system, that allows people to do daytrading over the web, and open source it. But Joe R Hacker isn't a broker, and doesn't have a man on the trading floor, and hence will have little use for it.
Furthermore, if you are a decent software company, you really don't want a gazillion people submitting bug reports for alpha software. You will get lots of crap reports, you will get lots of duplicate bugs reports, and assuming you are still doing development, most of the non-duplicated reports that aren't crap, are about bugs you already fixed.
I'd be weary of companies who embrace "release early, release often" because it helps them make a better product. It means something is wrong in their own development and testing departments.
-- Abigail
Re:Attn Moderators: Public Karma Test (Score:2)
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.
Re:Attn Moderators: Public Karma Test (Score:2)
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
-------------------
Re:Attn Moderators: Public Karma Test (Score:2)
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.
Re:Attn Moderators: Public Karma Test (Score:2)
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).
--
Re:Attn Moderators: Public Karma Test (Score:2)
What's a Whore? (Score:2)
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.
Karm Cap changes nothing (Score:2)
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?
Re:Attn Moderators: Public Karma Test (Score:2)
-Waldo
-------------------