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. . .
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
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'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
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.
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)
To paraphrase Signal 11: Look on Taco's face when I +2 first post for as long as I like: Priceless
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
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.
This is very new. They tried to make a "karma limit", but in doing so froze those of us with karma>limit in place.
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
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.
The 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.
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...)
355/113 -- Not the famous irrational number PI, but an incredible simulation!
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
me too, no offense (that truncation is just annoying). Oh, and about the Karma thing. I went up a couple earlier this week, but I'm at a lowly 218 so maybe the limit is higher than that.
--
+&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 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.
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.
-- Abigail
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
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.
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
-------------------
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
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."
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
-------------------