I laugh (and "cry") when I see people echo Stallman's nonsensical use of the word proprietary as if GPL'd code isn't proprietary.
Only recently did I realize how completely Stallman has managed to frame the debate by twisting the meaning of words like "proprietary". As you say, the GPL is proprietary, but Stallman has so demonized the word that nobody wants to recognize the truth of the situation.
The GPL may be "less proprietary" than most closed-source licenses in some sense, since anyone can obtain the benefit of GPL code by agreeing to abide by its rules. However, the GPL is far more proprietary than BSD-style licenses, which are barely proprietary at all. The only truly non-proprietary software is public domain software. If someone owns the code (i.e. there's a copyright and a license), then it's proprietary, by definition -- even if anyone can redistribute it under its terms and conditions.
Stallman should be demonizing "closed" software, not "proprietary" software. (A bit late now, of course, he's already trained everyone to turn rabid at the word "proprietary" while pretending that the GPL isn't also proprietary...)
They can always refuse to accept the GPL, in whoich case it is a simple copyright violation. In that case, the worst that can happen is that they have to pay damages.
I don't know whose code they distributed, but the FSF never dues for damages if the violater stop distributing the code. It is unclear how much the damages for distributing gratis code would amount to anyway. Usually the court take the price per copy times number of copies to find the damages (at least here in Denmark), which is cheap when the price is zero.
This is a very interesting question. If Epson were to refuse to release their proprietary code that was linked with GPL code, that would void the license grant in the GPL and make it a simple case of copyright violation (reproducing the GPL code without authorization of the copyright holder).
Now, it seems like an open-and-shut case to say that the court would find infringement had taken place -- after all, they were distributing binaries including that GPL code. (Supposing that Epson was intransigent instead of cooperative, and that the FSF took it to court.)
It seems clear that a flagrent GPL violation would result in an injunction against redistribution of the GPL code, but they could still rewrite their code to replace the GPL code with non-GPL code and distribute that later. (As Epson is doing now.)
So, the real question comes down to damages. Since damages are usually tied to economic loss, and the GPL code is (usually) freely available, there's a good argument to be made that there was no economic loss to the owner of the GPL code (since the people who received the infringing copies could have received the same GPL code for free through another means, and the GPL even grants those people a license even from the infringing copy!) -- perhaps the court would find that "actual" damages are therefore zero, no matter how flagrent the GPL violation? If so, perhaps the threat of court action over copyright infringement isn't as stong as it sounds?
Does the GPL really have enough teeth for enforcement if a straight copyright infringement case might not be costly enough to discourage misuse of GPL code? If Microsoft is willing to steal Stak's compression code outright (and they did), which caused actual damages, should they be so worried about the GPL? Or can they just say "we've never intended to apply the GPL to our products" to dodge the "viral" nature of the GPL and simply pay off the occasional copyright infringement case (and rewrite the code) in the few instances where they can be caught red-handed?
Of course, if there are statutory damages for the copyright infringement, those would apply even in the absence of actual damages. I think someone mentioned damages of $100,000 -- but only applicable if the copyright is registered with the Copyright Office? (Then again, even $100,000 is pocket change to a company like Microsoft...)
Disclaimer: I think Epson is doing the Right Thing, and I'm not a lawyer. Take the above with a grain of salt; this is just food for thought...
The RIAA's fear and loathing of Napster notwithstanding, file sharing could be your best promotional tool, and a uniquely Internet-age opportunity to build a fan base without signing your interests away to the music establishment.
Make your songs freely available. Allow fans to trade them legally. Don't give up your copyrights entirely, but noncommercial copying should be explicitly allowed and guaranteed with the proper legalese. If someone wants to redistribute your songs and charge more than a nominal copying fee, they should negotiate a license with you. If Joe Sixpack likes your stuff and wants to burn free CD's for all his pals, count your lucky stars and leave him alone. The "lost sales" are more than compensated by the promotional value, and how many of Joe's buddies would have bought your songs if they've never heard of you anyway?
This will get you more exposure and gain you new fans who never would have heard of you otherwise. Signed bands with serious financial backing can afford to purchase exposure outright. Small indie bands cannot. Don't fret over control like the RIAA does; learn to let go control and the rewards will be much greater. It's kind of a Zen thing; go with the flow... (The Grateful Dead always encouraged their fans to trade "bootleg" recordings of their concerts; did it hurt them or create legions of Deadheads? Think about it.)
Don't just make 128 Kbps MP3's available, either. Offer uncompressed CD-quality.wav files for download, and let people redistribute those too! (Yes, they'll burn perfect CD's with them; deal with it.) Also offer high-quality as well as low-bandwidth versions in both MP3 and Ogg Vorbis formats. (MP3 has the mindshare, but Ogg Vorbis is better.) Anyone who prefers a different encoder or bitrate can simply download the.wav file and encode it themselves.
Of course, there's a downside to this -- bandwidth costs could become significant. The best way to deal with this is to charge for downloads ($1.00 or less per song) and thereby encourage people to get it, legally, from a friend instead. This would reduce your costs (OPB -- Other People's Bandwidth!) while retaining the promotional value.
However, don't charge for the lowest-bitrate encodings! You need to make some version of each song available completely for free to seed some interest in the high-quality versions. The free version could be a 64 Kbps MP3, but it has to be available so people can hear the songs without paying any money or looking for copies elsewhere. If they like the song, they could then pay to download the high-quality.wav file...
For all versions you offer for download, publish the MD5 checksums on your website so people can get a copy from a friend, yet still verify the authenticity of the file.
Also, offer a way to "buy" songs (or simply donate money) for fans who want to support you, but don't need to download another copy. And, of course, sell CD's online for those who'd rather get something more tangible and simpler than dealing with downloading the songs.
Major record labels can afford to spend millions of dollars promoting the chosen few. Since you can't afford that, leverage Napster-like services to your advantage by allowing (and encouraging) free trading of high-quality digital copies of your songs. Trust that you'll do better with a smaller piece of a larger pie than jealously guarding a little pie...
(For an perspective from a different content industry, check out the Baen Free Library for similar arguments.)
The RSA patent is actually my favorite example of a patent which hurt the computer industry for a number of years before it finally expired. We really needed RSA to be unencumbered in the early 90s when the internet was just taking off. If we hadn't had crypto patents back then maybe we'd actually have something like DNSSEC now.
I have mixed feelings about the RSA patent. Like you, I wish the algorithm was unencumbered 10 years ago; it would have been a boon to the Internet. On the other hand, there was actual innovation in the algorithm, and it took skill to devise it. I'm forced to admit we might not have RSA in the public domain today if R, S & A hadn't invented it. There was nothing inevitable about this innovation.
Yes, British Intelligence had already invented the RSA system a decade earlier, but it was classified. It might still be classified and unknown to the public, but for R, S & A inventing the same algorithm independently. Nevertheless, as soon as the British invention was declassified, perhaps the fact of its prior invention should have invalidated the RSA patent. However, I'm not sure it "counts" if it was an unpublished invention.
The point is that innovations like RSA do advance the state of the art, even if they restrain us from taking full advantage of it for a while. Of course, that's how the patent system was intended to work -- give the inventor a monopoly in order to eventually gain the benefit for the public. The RSA algorithm wouldn't be very useful to us if it were still classified in Britain and otherwise unknown...
Personally I think there needs to be a moritorium on software patents in order to allow software to rapidly develop. Patents do not really encourage development. I have every expectation that R, S and A would have developed their crypto system even if they couldn't have patented it. Similarly, I'm sure that Amazon would have produced one-click even if it wasn't patentable.
Yes, R, S & A probably would have invented their crypto system either way, but that's because they are academics. Suppose they were corporate researchers? Then it wouldn't be a foregone conclusion that they'd have invented it anyway.
The one-click patent is fundamentally invalid because its invention was inevitable. Faced with the problem of reducing the consumer's effort required to order a product, any halfway competent engineer could have setup a database of customer information and programmed a system to order the product with a single click and use the stored information for all payment and shipping information. This solution is obvious, which is exactly why the patent never should have been granted in the first place. Nevertheless, under our current system, this invalid patent is probably enforceable.
Patents were intended to encourage inventors to divulge their inventions which might otherwise be kept secret or never invented in the first place. The "nonobvious" requirement exists to ensure that the public doesn't make a costly concession (the statutory monopoly of a patent) for any invention which was inevitable. Patents were intended to serve a public interest, and granting obvious patents makes a mockery of the process.
Patents should not be a race to see who can develop and patent each obvious idea first, yet that's exactly what's been happening -- especially in the area of software patents. The USPTO has a miserable track record of evaluating software patents for obviousness, or even finding prior art, since most prior software art usually isn't found in their patent archives.
The patent system is failing to serve the public interest it was designed for, because the USPTO has been derelict in its duty to grant patents fairly. Society bears an enormous burden of costs associated with these invalid patents, from the direct and indirect costs associated with the monopoly itself, to the enormous costs involved in overturning an invalid patent in court -- in the few instances where a patent can be successfully challenged. No matter how questionable a patent is, it enjoys a legal presumption of validity which is difficult (and expensive) to overturn. Each bad patent represents an enormous burden on society, and we've seen a veritable flood of bad patents in recent years.
Worse yet, the system encourages abuse of the patent system. Upstanding companies who choose not to file for a patent on an obvious invention can be blackmailed later by an unscrupulous competitor who was willing and able to abuse the system and obtain a bad patent. There are no consequences for abusing the system, and plenty of potential rewards -- corporations are usually amoral and greedy; is it any wonder they are drawn to this corrupt patent system like moths to a flame?
Also, the USPTO itself is fundamentally flawed, as it derives its sole revenues from patent fees (so it's important to keep those fees coming in by granting as many patents as possible, good or not) and it bears NONE of the cost that it imposes on society for bad patents it grants. There are no checks and balances in the system to ensure that the patent office only grants good patents, so we have a proliferation of bad patents.
The USPTO is desperately in need of reform and a fundamental restructuring to incorporate checks and balances to ensure that the patent system return to its original purpose of serving a public interest instead of enriching private interests with undeserved monopolies. All existing patents which haven't expired should be audited, and the invalid ones should be revoked. (Of course, that probably won't happen.)
The only way that the USPTO can be reformed is through Congressional action. Unfortunately, the corporations who benefit from the current corrupt system are well-represented in Congress, while the plight of the public at large is largely unrecognized, as with the perpetual copyright extensions of recent decades.
The fundamental problem with "Intellectual Property" is not that it's a flawed concept, but that it's been abused and twisted into a corrupt institution which is damaging our society as much as the favoritism of the British crown granting royal monopolies at a whim in centuries past.
That's why the Constitution does not allow for perpetual monopolies, and nearly didn't allow for any intellectual-property protections at all. The only reason the "intellectual property clause" was allowed into the Constitution at all was because the framers believed that our country would be immune to exactly this corruption due to the power of the people to vote corrupt politicians out of office. Make no mistake, if they could have seen the future, they would have banned copyrights and patents entirely.
I don't see where elminating software patents will do any harm. It will, however, mean that you can't just invent one critical piece of software or algorithm and have a consistant gravy train for 20 years. It means that to get a consistant source of cash you have to innovate year over year, which apparently scares the crap out of a lot of powerful people.
If software patents were rare and reasonable (like the RSA patent) instead of frequent and ridiculous (like the one-click patent), the cost imposed on society would be a miniscule fraction of what we're paying now. Given the speed of innovation in the software field, maybe 5-10 years would be sufficient incentive, but is it good to offer different levels of protections in different industries? That might be a bad precedent.
Software patents should only be granted in those rare instances where nearly any programmer would look at the algorithm and think: "My god! How did they ever think of that? That's fucking brilliant!" Any algorithm where that is the typical reaction may well be deserving of a patent, and one isn't likely to accidently reinvent it, unknowingly infringing on a patent.
Instead, we've seen a slew of software patents where most programmers think: "That's obvious, why the hell did they grant that patent?" Many of these bad patents are obvious, given the problem to be solved. Just because someone was the first to think of the solution, often it's only because that was the first person presented with that particular problem to solve. Copyright protection is appropriate here, but patents are overkill, and impose a tremendous cost on society for no benefit whatsoever.
Unfortunately, in the mind of a patent attorney, "obvious" doesn't mean what you think it means. Any minute detail that hasn't been conceived in a particular way before is viewed as "nonobvious", which conveniently allows many more patents to be filed. The USPTO plays along with this charade, which ensures a steady revenue of patent fees to fund the USPTO. The courts are loathe to second-guess the USPTO, since it's suppose to be their job to determine what's patentable or not.
The situation is especially bad with software patents precisely because computers and software is "Greek" to judges, patent attorneys and even the patent examiners who ought to know the field they're granting patents in. This would be the best reason for a moratoriam on software patents: the system isn't competent to determine validity.
Patent litigation is notoriously expensive and dangerous, and the stakes are high -- invalid patents are licensed every day, to avoid the risk of losing in court. The more licenses a bad patent has, the greater the appearance of legitimacy -- why would anyone license an invalid patent? Bad patents should be revoked routinely through an administrative review/audit process, not an adversarial legal process.
The current system is badly broken and amounts to legalized extortion in many cases. Only Congress can fix it, and they're not likely to as long as the corporate interests have their attention. Patents are meaningless to the average voter, so it's not clear how meaningful reform can ever be expected from Congress. Campaign finance reform may help mitigate the undue corporate influence, but Congress won't do anything until they realize the damage to society and believe voters know and care about it.
Having geeks talk to congresscritters is a good start, but it's probably not enough. We also need to find a way to get Joe Sixpack to care about this issue, which is easier said than done...
So he made a good faith attempt to raise the funding to produce the item listed in the patent, but couldn't get the money for it. Just because he may have made the attempt when there wasn't billions of dollars of capital available for anyone that mentioned the word "Internet" doesn't mean that he should be punished for that fact. My gripe is the folks that file for patents without any intention of ever attempting to implement it.
I'll give him some credit for attempting to implement the idea. That puts him on higher moral ground than the bottomfeeders whose entire business model is based on patent extortion.
However, the fact remains that the patent probably never should have been granted in the first place. Patents are supposed to protect nonobvious inventions, and we're seeing droves of patents granted that are patently obvious. I believe software patents and business method patents are particularly susceptible to this sort of stupidity, and should be subject to heightened scrutiny as a result.
I'm not categorically opposed to all software patents; RSA was a brilliant invention deserving of a software patent if anything was. It was a true invention, and now that the patent has expired, it's in the public domain, for the benefit of all. This is the sort of innovation that patents exist to encourage, and the only justification for them.
The problem is that the USPTO is out of control, granting ridiculous patents on everything from XOR cursors and one-click shopping to swinging sideways on a swing! If the USPTO actually applied the "nonobvious" test properly, very few patents would be granted, and they could serve their intended purpose. Instead, the current system is legalized extortion, and a great tool to dampen economic activity.
Discuss the most egregious examples (like swinging sideways) with your congresscritter. That's the only way this situation might improve.
I've got a full mail archive of vorbis (8520 mails) and vorbis-dev (5506 mails) since aug 25 2000 in my mailbox.
Interested to fix your archive?
Well, anyone keeping an archive usually wants it to be complete, so he'd probably be interested -- why don't you email Monty directly at monty@xiph.org with your offer? (He might not notice your offer here...)
The owner wants you to work 15 hours/day, 7 days/week? That's 105 hours per week. That leaves only 9 hours/day to eat and sleep, which means you'd be sleep-deprived and have zero free time. That's a ridiculous expectation. (And is he offering to pay over 2.5 times your normal salary for these marathons?)
However, even setting aside that patent inequity of the proposal, it won't work. I forget where I was reading it, but some study concluded that productivity in software development should be measured in days rather than hours. This is because it takes just as many 15-hour days as 8-hour days to get the same amount of work done. You might spend twice as many hours working, but it won't get the job done sooner, which means you'll have given up your free time (and probably sleep) for nothing.
The reason why 15-hour days are no more productive than 8-hour days was that working so much makes you less efficient, so you end up working slower. Worse yet, you're also more prone to error, so the software you write in those 15-hour days will produce buggier, lower-quality code, without saving any time in the schedule! However, that lower quality will affect the customer, and lead to more debugging and support work, and create a reputation for low quality which is hard to live down. Also, the cost of supporting buggy software can easily drown a company, especially if salespeople continue selling full-tilt even when the software is clearly buggy.
Not to help matters any, but when management starts demanding such long hours, employees start polishing their resumes, and morale falls to the floor. There's a good chance that the best employees will be the most likely to leave. And bringing someone new up to speed can be a major delay.
People are the most valuable asset of most companies (especially a software house), yet management is often so shortsighted as to view people as fungible "human resources", which is one of the greatest fallacies management can fall prey to. They tend to view hours as fungible, linear and very mechanical in nature, which is far from true for knowledge workers -- even if it may be more valid with manual labor tasks. Context-switching is another overlooked cost, implicitly (and incorrectly) assumed to be zero. (Developers should never be expected to do support work and still accomplish any work.) Knowledge workers are not fungible, and they never were.
Smack that owner upside the head with a clue-by-four, but be prepared to go find another job, because this one will become your own personal hell if he follows through on this plan. (But beware, it's not so easy to find another job as it was a couple years ago...)
A truly Enlightened owner would have you work six hours a day (yes, 30 hours/week!) for full-time pay and benefits, and encourage you to get at least 9 hours of sleep per night. While this seems counter-intuitive to a manager with a "human resources" mindset, consider the results. He would have happy, well-rested, enthusiastic and energetic employees who would be alert and less prone to error. (This would pay dividends in reduced debugging time, reduced support work, and a higher quality product that engenders customer loyalty.) They'd be reluctant to leave, rather than biding their time waiting for a chance to jump ship. They could have a life, the software would probably be less buggy, and it'll probably take as long to finish as it would have with 15-hour days, but without burning people out in the process of creating crappy software...
Of course, an Enlightened owner would also develop realistic schedules, not arbitrary ones based on his fantasies of when he thinks the code should be ready. And project plans should devote extra time to creating a good design instead of plunging into coding, because it's very difficult and expensive to fix a bad design after the fact.
Of course, there's a 99.9% chance that this owner just won't get it anyhow. Fret not about his karma; he'll reap what he sows -- just be prepared to do what you must if he remains clueless.
Google stores user preferences for you to specify default search parameters. For this to work, the cookie is needed to associate you with your preferences, whether the preferences are in their database or directly encoded in the cookie. Do you have solid evidence that they're also doing something more nefarious like building a personal dossier of all your searches? If you've got proof, put it on the table. Otherwise, you're getting paranoid; you may need to adjust your tin-foil hat...
As for PageRank, it may not be perfect, but it works really well. Yes, it may miss a good, relevant site. Nobody's perfect. If a poorly-ranked site is really valuable, people will probably start linking to it to help find that valuable information, and it will rise in the rankings.
If you really think you can improve their search results, why don't you make concrete suggestions to Google, or apply for a job with them? Everything I've seen about Google convinces me that they're devoted to constantly improving the quality of their search results. If you've really got a way to improve it, I'm sure they'd be delighted to hear it.
PageRank may not be the be-all and end-all, but it's based on solid principles of library science, and librarians were dealing with these needle-in-a-haystack problems long before the Internet was invented. (By Al Gore, of course!)
I disagree that starting a new website dooms you to PageRank obscurity. I created a new website at the very end of November 2001 for an open-source project I released. My website is at www.gangplank.org, and I also created a Freshmeat page for it. Freshmeat is probably ranked highly, since it provides excellent information. In any event, a simple search for "gangplank" right now places my site at #3, which is plenty good enough. Today, if I search for "deven" alone, my home page comes up as the #1 entry. (It's been in the top 10 as long as I can remember.) That page has been there for years, but never promoted on a site like Freshmeat.
I agree that there's a barrier to entry into the parthenon of ranking pages. To a certain degree, it's a "good old boys' network" of the "in" web pages. But that set of "in" pages is enormous, and if your site really is where people want to go, it often finds its way near the top of the list sooner or later.
However, there's a very good reason why ranking pages count more than "worthless" ones. If all pages were "democratically" given equal "voting power", all you'd see would be webmasters creating thousands upon thousands of junk pages with thousands of links to their site to try to claim the top ranking. (Much as you used to see miles of keywords hidden in web pages to fool content-oriented search engines.) As long as search engines are so important, there will always be people trying to subvert them to show their sites, no matter what site the user might really want. Google's PageRank is more resistant to tampering than most.
Google has also demonstrated utmost integrity in all their actions. In an age of increasingly despicable behavior from every corporation in search of a quick buck, this is quite refreshing. Google never succumbed to the Portal trap, nor graphic banner ad foolishness, nor paid search result rankings, etc. They've avoided all the heinous tendencies we've come to expect from most corporations, and steadfastly pursued their mission of making information on the Internet more accessible.
They've created one excellent service after another, from their original Web search (still the best by far), to Usenet (saving the Deja News archive from destruction, I might add, after Deja succumbed to Portal and other heinous corporate foolishness), to Image search, to Catalog search, to News summary and search, etc.
f you think you can do better, then do it. Many users (including myself) switched to Google for their excellent relevance rankings long before they had 2 billion pages indexed. I think Google had only about 100,000 pages indexed (still as a beta at Stanford) when I started checking it first instead of Altavista. (And it wasn't long before I stopped bothering with the second search on Altavista.) If you can do better than Google, maybe you can take the crown of most popular search engine away from Google. You suggest that PageRank is Google's Achille's heel. So prove it by making something better. But good luck! Google's pretty damn good at what they do. I won't hold my breath.
Google has brilliant people who provide outstanding (and astonishingly fast and powerful) services for free to all comers, they have effective yet nonintrusive and nondeceptive advertising, and they even manage to turn a profit, unlike most Internet startups. They should not hold an IPO, and the government should stay out of it. Google has proven itself, and impeding the Google juggernaut would impoverish us all. Google has always done the right thing, and they've done it better than anyone could hope, much less ask. In my book, Google ranks right up at the top of the list for coolest companies ever.
Yes, Google is beloved, but that loyalty was earned, fair and square.
Funny thing is that it's still called "Windows Media Player" when you install it.
Not so odd, really. After all, it's a player for "Windows Media" formats, though it's running on a Mac. It's not a Windows player for generic media formats, after all. Just get the binding right, and it makes sense: [Windows Media] Player, not Windows [Media Player]...
We can't port QuickTime without Apple's help. It's proprietary code. Those Java QuickTime APIs only work on the Mac OS X Java platform, because OS X includes QuickTime as a core technology. So we might be able to make a Java QuickTime player that runs under OS X (for all the good that does), but it will be missing the underlying QuickTime libraries to be able to run that Java application on Linux.
This isn't a matter of lazyness; porting QuickTime isn't an option for anyone but Apple.
AND THE WHOLE THING COMES WITH THE OS. Not on a separate cd you have to send away for or anything, but right on the retail cd.
I just bought an eMac, which came with 10.2 Jaguar preinstalled, as well as a pile of CD's. I can't find GCC or any other developer tools anywhere on the hard drive or on the CD's. Why would they include the tools with the retail boxed edition but not with a computer bought with the same version of the OS?
Several people have suggested creating CPUs from FPGAs. Others have objected that such CPUs would be slow. Maybe they are, but you gotta start somewhere, right? (Just how slow is "slow" anyhow? Maybe you can't yet make a 2 GHz chip from an FPGA, but can you make a 200 MHz one?)
Here's an idea -- if anyone wants to design CPUs with FPGAs, why not aim for asynchronous CPUs? (See It's Time for Clockless Chips.) "In 1997, Intel developed an asynchronous, Pentium-compatible test chip that ran three times as fast, on half the power, as its synchronous equivalent." (Of course, that's assuming that FPGAs aren't already locked into a synchronous design...)
It sounds like asynchronous chips are the "way of the future" and inherently more efficient -- if free tools are going to be created anyway, why not have some geared toward asynchronous designs? It would be a worthwhile research effort, at least.
Who knows? If a particular design works out well on FPGAs, maybe some chip manufacturer will be willing to mass-produce the chip at much higher speeds. It could be a good thing all around...
Oh, and the original poster is an idiot for not providing some sort of reference. Extraordinary claims require extraordinary proof... didn't anyone tell him that?
Am I the only person here who read the statement as an accidental homonym substitution? The original poster wrote:
(*i know of know such company).
From the context, I read it as a disclaimer to indicate that the example was for rhetorical purposes. He should have written this:
(*i know of no such company).
Now, doesn't this seem more likely to be what he meant, rather than a vague, unsubstantianted, extraordinary claim? Yet, strangely, we have poster after poster demanding the name of the supposed company in question. Think, people!
Well, you got me there. I own a ReplayTV. And I have had it for several years now.
Perhaps ReplayTV owners almost never watch commercials, since they tend to skip over them entirely instead of watching the screen while fast-forwarding. I've tried enabling the 30-second skip on my TiVo, but I don't like it. And while I skip most commercials, on maybe 5-10% of them, I may rewind to watch the commercial if it looks like it might be interesting.
I'm willing to watch the commercials at 60x since it only takes a few seconds to scan through a commercial block. Even if the 30-second skip might save me a second or two, it's only taking 5-7 seconds now; does it really matter? Anyway, if the advertiser manages to get their message through to me in half a second, more power to them. If they can't, they should work on it.
I find that I can't tolerate watching commercial-sponsored TV live anymore.
That seems to be the case with most PVR owners, because they get impatient when forced to wait through commercials the old-fashioned way because they're watching live TV. Waiting 15 minutes is one solution -- ignoring the live schedule and watching whatever you have available is another.
The on-screen program listings are nice, time-shifting is great and all that, but the commercial-skipping aspect has become even more important to me as I've grown accustomed to it.
PVR's would still be invaluable for time-shifting purposes, even if you were forced to watch the commercials. Of course, the ability to skip commercials is very popular and an excellent reason to have a PVR, but you implied that it's the only possible reason one would buy one, and that's clearly false.
So far in all these replies, the only examples anyone has posted of watching commercials is this: [...]
I rewind my TiVo to watch commercials that look interesting frequently enough that it's a common occurrence, even though I do end up skipping most commercials. I haven't kept a log of which commercials have been successful at grabbing my attention and which aren't -- but the TiVo could potentially track that information. (During the Super Bowl, they analyzed the data and determined that the Britney Spears Pepsi commercial was the most-watch commercial among TiVo owners, for example...)
So I'm not buying people sidestepping my original argument of "what value to the Nielson Ratings purchasers are the opinions of TiVo viewers?" They're not watching the commercials except for four hours on a cold Sunday in January. If I were buying the Nielson service, perhaps knowing what shows the commercial-skippers are watching is just a good reason to not advertise on them.
This is a shortsighted viewpoint. Instead of treating PVR owners as a lost audience, this could be an opportunity for advertisers to gain some valuable insight into which ads are effective and which aren't. (Currently, the Neilson/TiVo software isn't providing them this level of detail, but it's possible.)
Think about it. Advertisers could hone their campaigns to a fine edge, learning to make better ads and avoiding the ones people hate to watch. This is a level of feedback that just isn't possible from simple focus groups. Since the PVR owners can skip the commercials so easily, if you can make a commercial they'll watch, it's more likely that the people watching live TV will watch too, rather than reading, channel surfing or going to the kitchen.
TiVo doesn't have to be the enemy of advertisers and commercial television in general -- there's a lot of potential synergy, and it makes new, less annoying marketing strategies possible. They just have to work together and try not to piss off the users in the process. (ReplayTV, on the other hand, has taken a much more antagonistic stance towards commercial television, so it's no surprise they're viewed as a clear enemy...)
TiVo viewers (along with ReplayTV viewers) DON'T WATCH COMMERCIALS. Why else would you own one of these machines?
You obviously don't own a TiVo.
Yes, most TiVo owners tend to fast-forward through commercials, though they can't skip them entirely or automatically (unlike ReplayTV). However, as the existence of primetime "best commercials" programs indicates, people will watch commercials if they're good. (Many people watch the Super Bowl for the commercials because advertisers tend to work harder on making those commercials better than the usual tripe.) While I routinely fast-forward through commercials on my TiVo, I also regularly rewind to watch one which catches my eye. The moral? If advertisers want people to watch commercials without needing to coerce them into doing it, they should make better commercials that are worth watching.
While skipping commercials may be popular (since we're all sick of being bombarded with commercial messages), timeshifting is the real killer feature of the TiVo, not commercial skipping. Until you "get it", the TiVo just sounds like a glorified VCR, but that's really an inadequate description. While a VCR is useful for timeshifting "must see" programs, it's enough of a hassle that it's only used when necessary. With a TiVo, most users soon find they're recording everything of interest (usually automatically), and watching programs when convenient. You stop scheduling your life around TV schedules, and there's always something you like available to watch no matter when you sit down at the TV. If you're interrupted by a ringing phone, you pause the TV. If you want to see something again, you rewind it. You can pause and rewind on live TV as well as prerecorded shows. (My 2-year-old daughter gets upset when we can't rewind the TV in the bedroom on demand!)
To the uninitiated, the TiVo's features seem more like parlor tricks -- neat tricks, but not really important, and not worth paying for when you have a VCR already. This is a fundamental misunderstanding of what PVR's are really about. It's not just an enhanced VCR. It fundamentally changes the way you watch TV, and once you get used to it, you'd never go back to the plain old VCR. Just ask any TiVo owner.
Better yet, go buy one from a retailer with a 30-day return privilege and see for yourself. I doubt you'll end up returning it!
Mr. Olman was speaking in favor of the Sonny Bono Public Domain Pillage Act (also known as the "Copyright Term Extension Act"). He bewailed the loss of revenues such Communists and anarchists as the Boy Scouts cost the poor, abused Content Cartel every year. (Blatant plug: The Post published my reply. Like a schlub, I've lost the actual WashPost link.)
I guess you didn't try hard to find it... the WashPost link was right there on the page you did link to!
Tom's managed to raise $10K this year [...] we spend $10K every day or so in salaries. [...] The reality is that we should be at more like $100K per day in salaries to really have a good product.
Maybe $10K-100K/day is good for a company, but suppose a single developer could bring in just $100K/year? That's only $275/day, a modest amount, but it's enough for most developers to be able to quit their day jobs and devote their time and energy to the project. So why is even this out of reach, especially for the many open source projects that thousands or millions of people find valuable?
The problem is that all you lovely slashdot folks want to get everything for free. And you'll insist on it if you can get away with it.
This is a conundrum. Many of us would like to be able to write good software and just give it away for free. Of course, everyone loves to get free stuff also. But we also need to eat, and giving away your work doesn't pay the bills. Unfortunately, it seems that most of the options suck.
We can try to create a business around our software, but that's expensive, difficult and prone to failure. It also requires sales and marketing efforts, support staff and other overhead. All this takes quite a bit more money than a single developer needs to make a living. Of course, new businesses have a very high failure rate, so this option sucks.
We can try to build a business around open source, but we probably can't bring in much revenue from sales of the software -- someone will turn around and give it away for free and undercut the market. We can try to bring in revenue with support or services, but this is uncertain, and only some markets can truly support a company this way. Many open-source companies have had trouble with funding, and there's little incentive to create high-quality software that "just works". This option sucks.
We can take the traditional route, keeping the software closed and selling it to bring in revenue. This can work, but charging for closed code will alienate the open-source community, and possibly even motivate volunteers to compete with you by writing free software. Many potential users who might have been interested will not buy the commercial product, so the market is much smaller, even if the return (per person) is better. Also, we'd rather be able to release our code as open source if we could. This option sucks.
Most of the truly effective business models we've seen for open source businesses seem to rely on some sort of hybrid where the code is open, but the revenue comes from a proprietary source, such as large companies paying for consulting or support, or paying to use the free code in their non-free products (a la Sleepycat) or offering proprietary components to work with an underlying free system (a la Sendmail), etc. These can be effective, at least, but they often depend on someone else making money from closed software, or depend on the whims of large corporations who may make their money elsewhere. So these options can suck too, but at least they can be workable.
I think the root of the problem is human nature. We like free stuff, and we think we're getting a bargain if we get away with not paying for something, especially if we're told that's okay. So it's quite rare for us to send money to send money to authors of free projects, no matter how much we may value those projects. And even when a few of us do, it's just a drop in the bucket.
What developer can afford to quit their day job just because every week a half dozen users take it upon themselves to donate $20 when they didn't have to? Sure, it's nice. No doubt it's appreciated, but that $120/week would be barely over $6K/year, which is far too little to live on. Begging for donations just doesn't work well, whether it's a developer, a charity or public television.
On the other hand, if each of 10,000 users would pay just $10/year, that would be $100K that could support that developer and allow them to quit working a day job. Why doesn't this work? Because each of those 10,000 users will tell themselves that the other 9,999 users can pay their $10, and nobody would miss that $10. And it's true; $99,990 would be just as good as $100,000. Unfortunately, the vast majority makes this same argument, and suddenly you're back at $6K instead of $100K.
So, here's the question. How can we get the masses of regular users to pay a modest amount of money, on a regular basis, to support development of the software they want? And can we do it with the free-redistribution clauses in open-source licenses, or is it only possible if redistribution is restricted? Is it compatible with the GPL? Can we offer some other tangible selective benefit that only the paying users will benefit from, that will convince them to join up?
How about some creative responses here? You, there! Yes, you! What would convince you to chip in some money on a routine basis?
I was asking myself similar questions when I was deciding when and how to release Gangplank, a "chat system" that could fit in the same niche as a standalone IRC server not participating in an IRC network. (I don't have any server-to-server code at the present time.)
Here are the conclusions I came to:
I would use the QPL as the initial license. Since the QPL is an open-source license, but requires that changes be distributed as patches against the original distribution, this should discourage code forks (although they're still possible) and make it clear which code I've "blessed" and what code is modified. (I don't want to be blamed for a bug someone else introduces...)
Ultimately, I expect to switch to another license (probably an MPL/LGPL/GPL triple license a la Mozilla), but not until my project is sufficiently well-established that it can't be trivially eclipsed by a forked project with a more active maintainer using my own code to compete against me.
For now, I want to maintain a tree which is 100% my own code, both for "vision" reasons and as a potential demonstration piece for my programming skills. However, I don't expect this branch to last forever; once my initial vision is "finished" enough and up to my own quality expectations, it will no longer be important to have 100% of the code written by myself.
Meanwhile, if others contribute worthwhile code, I expect to branch a new "community" version which will include code contributed by others, as well as my own code. This version would probably become the recommended version, and I'd probably have to work harder to apply my own changes to both branches. (Rather than branch a new version for this, it may take the form of branching the "100% mine" version and considering the mainline version to be the community version.)
I won't accept code (even for the community branch) that is poorly written or seems to fundamentally conflict with the rest of the project. However, I will happily maintain a "contrib" area of patches that I choose not to integrate, so others can apply them if desired. (Hopefully, this should reduce the incentive to fork the project, also.)
For worthwhile code contributions that constitute an unwanted shift in direction for the project, it may make sense to create a new branch for that purpose, rather than rely on "contrib" patches on sources that are likely to diverge. (In this case, someone would probably need to volunteer to maintain the branch, if it's not one I'm personally interested in.)
I decided that it is critical that (potential) contributors never be ignored. Ignoring a contribution is worse than rejecting it outright. A rejected contribution (with constructive criticism) may lead to new and better future contributions, while an ignored contribution is likely to lead very quickly to the loss of interest by that contributor.
If a patch is incomprehensible, a discussion with the contributor is in order, and perhaps a rewrite as well.
If someone forks the project, so be it. Hopefully it won't happen, but it's always a risk. It's more of a risk early on, which is why I'm using the QPL for now.
I decided to treat the project as if it might be used for "production" use, on general principle. However, rather than the simplistic (and somewhat ineffective) even/odd numbering approach of the Linux kernel, I decided to take a different approach to version numbering:
Most importantly, I decided that no release will ever be declared "stable" without spending some time out there as a "release candidate" first, to allow time for any bugs to be found and reported. The "stable" release would therefore be virtually identical to a previous "unstable" release candidate, except for the version number and perhaps small nonfunctional changes like documentation No code changes should be introduced as a "stable" release. (This has caused too many "brown-paper-bag" releases in the "stable" Linux kernel series in the past, for example.)
To distinguish "stable" from "development" (unstable) releases, I decided that the "stable" releases would be all-numeric (e.g. 1.0.0) while "development" releases would always contain alpha characters in the version number (e.g. 1.0.0.beta.3).
To distinguish various levels of stability and approach to stable status, I decided to use word tags like "experimental" (maybe "exp?), "devel", "alpha", "beta", "rc", etc. This would be followed by a sub-release number in the same group.
For development releases, I decided to use the next target stable release number as the base, hence "1.0.0.beta.3" precedes "1.0.0" instead of following it. (Of course, "1.0.0.rc.1" would be in between those.)
In the case of branches for experimental coding, I decided to use named branches rather than a numeric branching scheme. Hopefully, all branches would start from a stable release, although I suppose they wouldn't have to. (I'm not sure exactly how to number named branches, but starting with the base revision of the branch point seeks probable.) If a branch looks like it will become long-lived and separately maintained, I imagine it would migrate into a new subproject name for the codebase and become the mainline version for that subproject.
I decided that binary distributions (e.g. RPMs) should be offered for "stable" releases only, not for development releases. (Release candidates would probably be an exception, offering binaries temporarily, until the next release candidate or stable release, since they're intended to be stable releases and should be tested by non-developers...)
I decided that the cycle between stable releases must be kept short to ensure that development never diverges far from the last stable release. If a non-developer wants to install a development release, that's a sign that the stable releases are too far apart!
I decided that development releases would come with patches against the previous development release, but that stable releases would come with patches against the last stable release instead.
I decided that a CVS server should be made available for people who want to track the development without having to download each development release or keep patching.
I decided to cryptographically sign each release to ensure its integrity.
I decided that I should have a bugtracking system (like Bugzilla) and place a high priority on fixing any trivial bugs to try to keep prople from getting discouraged when even the simplest bugs they report don't get fixed. Ideally, the bugtracking system should allow for easy integration with bug reporting via email.
I decided that there should be at least two mailing lists (an announcements list and a developer's list), in addition to Freshmeat announcements of releases.
I decided that the project should have a website, ideally one which has frequent updates (i.e. news items) every day or three. (There's nothing more boring than returning to a website to find that nothing has changed!) Screenshots are also good, if possible -- people love screenshots!
Unfortunately, I haven't had the time to get my project into the shape I want -- the website is woefully inadequate right now (ugly and too static), there's no bugtracking system or mailing lists yet, I don't have a CVS server available yet, and I haven't gotten to the point of declaring a "stable" release yet. But I've been announcing the few releases I've made on Freshmeat, and signing the releases for integrity, and using my version numbering scheme (which I'm tuning as I go; it's a work in progress), and I've got a demo server running. It's coming along, but it takes a lot of work, and I never seem to have much time. Of course, this is exactly why I used the QPL, because I expected to be less active at maintaining the project than I ought to be...
In the end, I'm just making this up as I go along. I'm sure I'll make some mistakes, and others may not agree with every decision I make, but I choose to operate in the "benevolent dictator" model, not a "democratic" model. I reserve the right to be arbitrary and capricious, though I'll try not to be. Anyone who doesn't like it can fork the project, just as someone could fork Linux if they don't like Linus as benevolent dictator.
Of course, this is largely a moot point so far -- my project has generated very little interest yet and no contributors at all -- which seems to be the norm for small open-source projects. But I figure I might as well try to figure out some "best practices" from the start as I go along rather than wait until things get out of hand to start trying to implement them after the fact...
You can get an open-source spellchecker at mozdev.org that works with some Mozilla releases but I'm not sure if they've updated it to work with 1.1beta.
Um, why should it need updating to work with 1.1beta? I thought the whole point of the 1.0 release was to freeze the API so that they work across all 1.x versions! If the spellchecker works with 1.0, shouldn't it work with 1.1beta, out of the box? (If not, then what was the point of the API freeze?)
Slashdot Mirror
/* Anonymity isn't all it's cracked up to be. */
;-)
Who are you quoting?
I laugh (and "cry") when I see people echo Stallman's nonsensical use of the word proprietary as if GPL'd code isn't proprietary.
Only recently did I realize how completely Stallman has managed to frame the debate by twisting the meaning of words like "proprietary". As you say, the GPL is proprietary, but Stallman has so demonized the word that nobody wants to recognize the truth of the situation.
The GPL may be "less proprietary" than most closed-source licenses in some sense, since anyone can obtain the benefit of GPL code by agreeing to abide by its rules. However, the GPL is far more proprietary than BSD-style licenses, which are barely proprietary at all. The only truly non-proprietary software is public domain software. If someone owns the code (i.e. there's a copyright and a license), then it's proprietary, by definition -- even if anyone can redistribute it under its terms and conditions.
Stallman should be demonizing "closed" software, not "proprietary" software. (A bit late now, of course, he's already trained everyone to turn rabid at the word "proprietary" while pretending that the GPL isn't also proprietary...)
They can always refuse to accept the GPL, in whoich case it is a simple copyright violation. In that case, the worst that can happen is that they have to pay damages.
I don't know whose code they distributed, but the FSF never dues for damages if the violater stop distributing the code. It is unclear how much the damages for distributing gratis code would amount to anyway. Usually the court take the price per copy times number of copies to find the damages (at least here in Denmark), which is cheap when the price is zero.
This is a very interesting question. If Epson were to refuse to release their proprietary code that was linked with GPL code, that would void the license grant in the GPL and make it a simple case of copyright violation (reproducing the GPL code without authorization of the copyright holder).
Now, it seems like an open-and-shut case to say that the court would find infringement had taken place -- after all, they were distributing binaries including that GPL code. (Supposing that Epson was intransigent instead of cooperative, and that the FSF took it to court.)
It seems clear that a flagrent GPL violation would result in an injunction against redistribution of the GPL code, but they could still rewrite their code to replace the GPL code with non-GPL code and distribute that later. (As Epson is doing now.)
So, the real question comes down to damages. Since damages are usually tied to economic loss, and the GPL code is (usually) freely available, there's a good argument to be made that there was no economic loss to the owner of the GPL code (since the people who received the infringing copies could have received the same GPL code for free through another means, and the GPL even grants those people a license even from the infringing copy!) -- perhaps the court would find that "actual" damages are therefore zero, no matter how flagrent the GPL violation? If so, perhaps the threat of court action over copyright infringement isn't as stong as it sounds?
Does the GPL really have enough teeth for enforcement if a straight copyright infringement case might not be costly enough to discourage misuse of GPL code? If Microsoft is willing to steal Stak's compression code outright (and they did), which caused actual damages, should they be so worried about the GPL? Or can they just say "we've never intended to apply the GPL to our products" to dodge the "viral" nature of the GPL and simply pay off the occasional copyright infringement case (and rewrite the code) in the few instances where they can be caught red-handed?
Of course, if there are statutory damages for the copyright infringement, those would apply even in the absence of actual damages. I think someone mentioned damages of $100,000 -- but only applicable if the copyright is registered with the Copyright Office? (Then again, even $100,000 is pocket change to a company like Microsoft...)
Disclaimer: I think Epson is doing the Right Thing, and I'm not a lawyer. Take the above with a grain of salt; this is just food for thought...
Humor can't always be explained. If you don't get it, then you don't get it. But I found it funny...
And yes, I posted with a +1 bonus, though I'm not going to use it for this reply.
Now that's funny; mod it up!
(Translation: "Wooo! I wish I was as literate as you!")
The RIAA's fear and loathing of Napster notwithstanding, file sharing could be your best promotional tool, and a uniquely Internet-age opportunity to build a fan base without signing your interests away to the music establishment.
.wav files for download, and let people redistribute those too! (Yes, they'll burn perfect CD's with them; deal with it.) Also offer high-quality as well as low-bandwidth versions in both MP3 and Ogg Vorbis formats. (MP3 has the mindshare, but Ogg Vorbis is better.) Anyone who prefers a different encoder or bitrate can simply download the .wav file and encode it themselves.
.wav file...
Make your songs freely available. Allow fans to trade them legally. Don't give up your copyrights entirely, but noncommercial copying should be explicitly allowed and guaranteed with the proper legalese. If someone wants to redistribute your songs and charge more than a nominal copying fee, they should negotiate a license with you. If Joe Sixpack likes your stuff and wants to burn free CD's for all his pals, count your lucky stars and leave him alone. The "lost sales" are more than compensated by the promotional value, and how many of Joe's buddies would have bought your songs if they've never heard of you anyway?
This will get you more exposure and gain you new fans who never would have heard of you otherwise. Signed bands with serious financial backing can afford to purchase exposure outright. Small indie bands cannot. Don't fret over control like the RIAA does; learn to let go control and the rewards will be much greater. It's kind of a Zen thing; go with the flow... (The Grateful Dead always encouraged their fans to trade "bootleg" recordings of their concerts; did it hurt them or create legions of Deadheads? Think about it.)
Don't just make 128 Kbps MP3's available, either. Offer uncompressed CD-quality
Of course, there's a downside to this -- bandwidth costs could become significant. The best way to deal with this is to charge for downloads ($1.00 or less per song) and thereby encourage people to get it, legally, from a friend instead. This would reduce your costs (OPB -- Other People's Bandwidth!) while retaining the promotional value.
However, don't charge for the lowest-bitrate encodings! You need to make some version of each song available completely for free to seed some interest in the high-quality versions. The free version could be a 64 Kbps MP3, but it has to be available so people can hear the songs without paying any money or looking for copies elsewhere. If they like the song, they could then pay to download the high-quality
For all versions you offer for download, publish the MD5 checksums on your website so people can get a copy from a friend, yet still verify the authenticity of the file.
Also, offer a way to "buy" songs (or simply donate money) for fans who want to support you, but don't need to download another copy. And, of course, sell CD's online for those who'd rather get something more tangible and simpler than dealing with downloading the songs.
Major record labels can afford to spend millions of dollars promoting the chosen few. Since you can't afford that, leverage Napster-like services to your advantage by allowing (and encouraging) free trading of high-quality digital copies of your songs. Trust that you'll do better with a smaller piece of a larger pie than jealously guarding a little pie...
(For an perspective from a different content industry, check out the Baen Free Library for similar arguments.)
The RSA patent is actually my favorite example of a patent which hurt the computer industry for a number of years before it finally expired. We really needed RSA to be unencumbered in the early 90s when the internet was just taking off. If we hadn't had crypto patents back then maybe we'd actually have something like DNSSEC now.
I have mixed feelings about the RSA patent. Like you, I wish the algorithm was unencumbered 10 years ago; it would have been a boon to the Internet. On the other hand, there was actual innovation in the algorithm, and it took skill to devise it. I'm forced to admit we might not have RSA in the public domain today if R, S & A hadn't invented it. There was nothing inevitable about this innovation.
Yes, British Intelligence had already invented the RSA system a decade earlier, but it was classified. It might still be classified and unknown to the public, but for R, S & A inventing the same algorithm independently. Nevertheless, as soon as the British invention was declassified, perhaps the fact of its prior invention should have invalidated the RSA patent. However, I'm not sure it "counts" if it was an unpublished invention.
The point is that innovations like RSA do advance the state of the art, even if they restrain us from taking full advantage of it for a while. Of course, that's how the patent system was intended to work -- give the inventor a monopoly in order to eventually gain the benefit for the public. The RSA algorithm wouldn't be very useful to us if it were still classified in Britain and otherwise unknown...
Personally I think there needs to be a moritorium on software patents in order to allow software to rapidly develop. Patents do not really encourage development. I have every expectation that R, S and A would have developed their crypto system even if they couldn't have patented it. Similarly, I'm sure that Amazon would have produced one-click even if it wasn't patentable.
Yes, R, S & A probably would have invented their crypto system either way, but that's because they are academics. Suppose they were corporate researchers? Then it wouldn't be a foregone conclusion that they'd have invented it anyway.
The one-click patent is fundamentally invalid because its invention was inevitable. Faced with the problem of reducing the consumer's effort required to order a product, any halfway competent engineer could have setup a database of customer information and programmed a system to order the product with a single click and use the stored information for all payment and shipping information. This solution is obvious, which is exactly why the patent never should have been granted in the first place. Nevertheless, under our current system, this invalid patent is probably enforceable.
Patents were intended to encourage inventors to divulge their inventions which might otherwise be kept secret or never invented in the first place. The "nonobvious" requirement exists to ensure that the public doesn't make a costly concession (the statutory monopoly of a patent) for any invention which was inevitable. Patents were intended to serve a public interest, and granting obvious patents makes a mockery of the process.
Patents should not be a race to see who can develop and patent each obvious idea first, yet that's exactly what's been happening -- especially in the area of software patents. The USPTO has a miserable track record of evaluating software patents for obviousness, or even finding prior art, since most prior software art usually isn't found in their patent archives.
The patent system is failing to serve the public interest it was designed for, because the USPTO has been derelict in its duty to grant patents fairly. Society bears an enormous burden of costs associated with these invalid patents, from the direct and indirect costs associated with the monopoly itself, to the enormous costs involved in overturning an invalid patent in court -- in the few instances where a patent can be successfully challenged. No matter how questionable a patent is, it enjoys a legal presumption of validity which is difficult (and expensive) to overturn. Each bad patent represents an enormous burden on society, and we've seen a veritable flood of bad patents in recent years.
Worse yet, the system encourages abuse of the patent system. Upstanding companies who choose not to file for a patent on an obvious invention can be blackmailed later by an unscrupulous competitor who was willing and able to abuse the system and obtain a bad patent. There are no consequences for abusing the system, and plenty of potential rewards -- corporations are usually amoral and greedy; is it any wonder they are drawn to this corrupt patent system like moths to a flame?
Also, the USPTO itself is fundamentally flawed, as it derives its sole revenues from patent fees (so it's important to keep those fees coming in by granting as many patents as possible, good or not) and it bears NONE of the cost that it imposes on society for bad patents it grants. There are no checks and balances in the system to ensure that the patent office only grants good patents, so we have a proliferation of bad patents.
The USPTO is desperately in need of reform and a fundamental restructuring to incorporate checks and balances to ensure that the patent system return to its original purpose of serving a public interest instead of enriching private interests with undeserved monopolies. All existing patents which haven't expired should be audited, and the invalid ones should be revoked. (Of course, that probably won't happen.)
The only way that the USPTO can be reformed is through Congressional action. Unfortunately, the corporations who benefit from the current corrupt system are well-represented in Congress, while the plight of the public at large is largely unrecognized, as with the perpetual copyright extensions of recent decades.
The fundamental problem with "Intellectual Property" is not that it's a flawed concept, but that it's been abused and twisted into a corrupt institution which is damaging our society as much as the favoritism of the British crown granting royal monopolies at a whim in centuries past.
That's why the Constitution does not allow for perpetual monopolies, and nearly didn't allow for any intellectual-property protections at all. The only reason the "intellectual property clause" was allowed into the Constitution at all was because the framers believed that our country would be immune to exactly this corruption due to the power of the people to vote corrupt politicians out of office. Make no mistake, if they could have seen the future, they would have banned copyrights and patents entirely.
I don't see where elminating software patents will do any harm. It will, however, mean that you can't just invent one critical piece of software or algorithm and have a consistant gravy train for 20 years. It means that to get a consistant source of cash you have to innovate year over year, which apparently scares the crap out of a lot of powerful people.
If software patents were rare and reasonable (like the RSA patent) instead of frequent and ridiculous (like the one-click patent), the cost imposed on society would be a miniscule fraction of what we're paying now. Given the speed of innovation in the software field, maybe 5-10 years would be sufficient incentive, but is it good to offer different levels of protections in different industries? That might be a bad precedent.
Software patents should only be granted in those rare instances where nearly any programmer would look at the algorithm and think: "My god! How did they ever think of that? That's fucking brilliant!" Any algorithm where that is the typical reaction may well be deserving of a patent, and one isn't likely to accidently reinvent it, unknowingly infringing on a patent.
Instead, we've seen a slew of software patents where most programmers think: "That's obvious, why the hell did they grant that patent?" Many of these bad patents are obvious, given the problem to be solved. Just because someone was the first to think of the solution, often it's only because that was the first person presented with that particular problem to solve. Copyright protection is appropriate here, but patents are overkill, and impose a tremendous cost on society for no benefit whatsoever.
Unfortunately, in the mind of a patent attorney, "obvious" doesn't mean what you think it means. Any minute detail that hasn't been conceived in a particular way before is viewed as "nonobvious", which conveniently allows many more patents to be filed. The USPTO plays along with this charade, which ensures a steady revenue of patent fees to fund the USPTO. The courts are loathe to second-guess the USPTO, since it's suppose to be their job to determine what's patentable or not.
The situation is especially bad with software patents precisely because computers and software is "Greek" to judges, patent attorneys and even the patent examiners who ought to know the field they're granting patents in. This would be the best reason for a moratoriam on software patents: the system isn't competent to determine validity.
Patent litigation is notoriously expensive and dangerous, and the stakes are high -- invalid patents are licensed every day, to avoid the risk of losing in court. The more licenses a bad patent has, the greater the appearance of legitimacy -- why would anyone license an invalid patent? Bad patents should be revoked routinely through an administrative review/audit process, not an adversarial legal process.
The current system is badly broken and amounts to legalized extortion in many cases. Only Congress can fix it, and they're not likely to as long as the corporate interests have their attention. Patents are meaningless to the average voter, so it's not clear how meaningful reform can ever be expected from Congress. Campaign finance reform may help mitigate the undue corporate influence, but Congress won't do anything until they realize the damage to society and believe voters know and care about it.
Having geeks talk to congresscritters is a good start, but it's probably not enough. We also need to find a way to get Joe Sixpack to care about this issue, which is easier said than done...
So he made a good faith attempt to raise the funding to produce the item listed in the patent, but couldn't get the money for it. Just because he may have made the attempt when there wasn't billions of dollars of capital available for anyone that mentioned the word "Internet" doesn't mean that he should be punished for that fact. My gripe is the folks that file for patents without any intention of ever attempting to implement it.
I'll give him some credit for attempting to implement the idea. That puts him on higher moral ground than the bottomfeeders whose entire business model is based on patent extortion.
However, the fact remains that the patent probably never should have been granted in the first place. Patents are supposed to protect nonobvious inventions, and we're seeing droves of patents granted that are patently obvious. I believe software patents and business method patents are particularly susceptible to this sort of stupidity, and should be subject to heightened scrutiny as a result.
I'm not categorically opposed to all software patents; RSA was a brilliant invention deserving of a software patent if anything was. It was a true invention, and now that the patent has expired, it's in the public domain, for the benefit of all. This is the sort of innovation that patents exist to encourage, and the only justification for them.
The problem is that the USPTO is out of control, granting ridiculous patents on everything from XOR cursors and one-click shopping to swinging sideways on a swing! If the USPTO actually applied the "nonobvious" test properly, very few patents would be granted, and they could serve their intended purpose. Instead, the current system is legalized extortion, and a great tool to dampen economic activity.
Discuss the most egregious examples (like swinging sideways) with your congresscritter. That's the only way this situation might improve.
I've got a full mail archive of vorbis (8520 mails) and vorbis-dev (5506 mails) since aug 25 2000 in my mailbox.
Interested to fix your archive?
Well, anyone keeping an archive usually wants it to be complete, so he'd probably be interested -- why don't you email Monty directly at monty@xiph.org with your offer? (He might not notice your offer here...)
The owner wants you to work 15 hours/day, 7 days/week? That's 105 hours per week. That leaves only 9 hours/day to eat and sleep, which means you'd be sleep-deprived and have zero free time. That's a ridiculous expectation. (And is he offering to pay over 2.5 times your normal salary for these marathons?)
However, even setting aside that patent inequity of the proposal, it won't work. I forget where I was reading it, but some study concluded that productivity in software development should be measured in days rather than hours. This is because it takes just as many 15-hour days as 8-hour days to get the same amount of work done. You might spend twice as many hours working, but it won't get the job done sooner, which means you'll have given up your free time (and probably sleep) for nothing.
The reason why 15-hour days are no more productive than 8-hour days was that working so much makes you less efficient, so you end up working slower. Worse yet, you're also more prone to error, so the software you write in those 15-hour days will produce buggier, lower-quality code, without saving any time in the schedule! However, that lower quality will affect the customer, and lead to more debugging and support work, and create a reputation for low quality which is hard to live down. Also, the cost of supporting buggy software can easily drown a company, especially if salespeople continue selling full-tilt even when the software is clearly buggy.
Not to help matters any, but when management starts demanding such long hours, employees start polishing their resumes, and morale falls to the floor. There's a good chance that the best employees will be the most likely to leave. And bringing someone new up to speed can be a major delay.
People are the most valuable asset of most companies (especially a software house), yet management is often so shortsighted as to view people as fungible "human resources", which is one of the greatest fallacies management can fall prey to. They tend to view hours as fungible, linear and very mechanical in nature, which is far from true for knowledge workers -- even if it may be more valid with manual labor tasks. Context-switching is another overlooked cost, implicitly (and incorrectly) assumed to be zero. (Developers should never be expected to do support work and still accomplish any work.) Knowledge workers are not fungible, and they never were.
Smack that owner upside the head with a clue-by-four, but be prepared to go find another job, because this one will become your own personal hell if he follows through on this plan. (But beware, it's not so easy to find another job as it was a couple years ago...)
A truly Enlightened owner would have you work six hours a day (yes, 30 hours/week!) for full-time pay and benefits, and encourage you to get at least 9 hours of sleep per night. While this seems counter-intuitive to a manager with a "human resources" mindset, consider the results. He would have happy, well-rested, enthusiastic and energetic employees who would be alert and less prone to error. (This would pay dividends in reduced debugging time, reduced support work, and a higher quality product that engenders customer loyalty.) They'd be reluctant to leave, rather than biding their time waiting for a chance to jump ship. They could have a life, the software would probably be less buggy, and it'll probably take as long to finish as it would have with 15-hour days, but without burning people out in the process of creating crappy software...
Of course, an Enlightened owner would also develop realistic schedules, not arbitrary ones based on his fantasies of when he thinks the code should be ready. And project plans should devote extra time to creating a good design instead of plunging into coding, because it's very difficult and expensive to fix a bad design after the fact.
Of course, there's a 99.9% chance that this owner just won't get it anyhow. Fret not about his karma; he'll reap what he sows -- just be prepared to do what you must if he remains clueless.
Google stores user preferences for you to specify default search parameters. For this to work, the cookie is needed to associate you with your preferences, whether the preferences are in their database or directly encoded in the cookie. Do you have solid evidence that they're also doing something more nefarious like building a personal dossier of all your searches? If you've got proof, put it on the table. Otherwise, you're getting paranoid; you may need to adjust your tin-foil hat...
As for PageRank, it may not be perfect, but it works really well. Yes, it may miss a good, relevant site. Nobody's perfect. If a poorly-ranked site is really valuable, people will probably start linking to it to help find that valuable information, and it will rise in the rankings.
If you really think you can improve their search results, why don't you make concrete suggestions to Google, or apply for a job with them? Everything I've seen about Google convinces me that they're devoted to constantly improving the quality of their search results. If you've really got a way to improve it, I'm sure they'd be delighted to hear it.
PageRank may not be the be-all and end-all, but it's based on solid principles of library science, and librarians were dealing with these needle-in-a-haystack problems long before the Internet was invented. (By Al Gore, of course!)
I disagree that starting a new website dooms you to PageRank obscurity. I created a new website at the very end of November 2001 for an open-source project I released. My website is at www.gangplank.org, and I also created a Freshmeat page for it. Freshmeat is probably ranked highly, since it provides excellent information. In any event, a simple search for "gangplank" right now places my site at #3, which is plenty good enough. Today, if I search for "deven" alone, my home page comes up as the #1 entry. (It's been in the top 10 as long as I can remember.) That page has been there for years, but never promoted on a site like Freshmeat.
I agree that there's a barrier to entry into the parthenon of ranking pages. To a certain degree, it's a "good old boys' network" of the "in" web pages. But that set of "in" pages is enormous, and if your site really is where people want to go, it often finds its way near the top of the list sooner or later.
However, there's a very good reason why ranking pages count more than "worthless" ones. If all pages were "democratically" given equal "voting power", all you'd see would be webmasters creating thousands upon thousands of junk pages with thousands of links to their site to try to claim the top ranking. (Much as you used to see miles of keywords hidden in web pages to fool content-oriented search engines.) As long as search engines are so important, there will always be people trying to subvert them to show their sites, no matter what site the user might really want. Google's PageRank is more resistant to tampering than most.
Google has also demonstrated utmost integrity in all their actions. In an age of increasingly despicable behavior from every corporation in search of a quick buck, this is quite refreshing. Google never succumbed to the Portal trap, nor graphic banner ad foolishness, nor paid search result rankings, etc. They've avoided all the heinous tendencies we've come to expect from most corporations, and steadfastly pursued their mission of making information on the Internet more accessible.
They've created one excellent service after another, from their original Web search (still the best by far), to Usenet (saving the Deja News archive from destruction, I might add, after Deja succumbed to Portal and other heinous corporate foolishness), to Image search, to Catalog search, to News summary and search, etc.
f you think you can do better, then do it. Many users (including myself) switched to Google for their excellent relevance rankings long before they had 2 billion pages indexed. I think Google had only about 100,000 pages indexed (still as a beta at Stanford) when I started checking it first instead of Altavista. (And it wasn't long before I stopped bothering with the second search on Altavista.) If you can do better than Google, maybe you can take the crown of most popular search engine away from Google. You suggest that PageRank is Google's Achille's heel. So prove it by making something better. But good luck! Google's pretty damn good at what they do. I won't hold my breath.
Google has brilliant people who provide outstanding (and astonishingly fast and powerful) services for free to all comers, they have effective yet nonintrusive and nondeceptive advertising, and they even manage to turn a profit, unlike most Internet startups. They should not hold an IPO, and the government should stay out of it. Google has proven itself, and impeding the Google juggernaut would impoverish us all. Google has always done the right thing, and they've done it better than anyone could hope, much less ask. In my book, Google ranks right up at the top of the list for coolest companies ever.
Yes, Google is beloved, but that loyalty was earned, fair and square.
Funny thing is that it's still called "Windows Media Player" when you install it.
Not so odd, really. After all, it's a player for "Windows Media" formats, though it's running on a Mac. It's not a Windows player for generic media formats, after all. Just get the binding right, and it makes sense: [Windows Media] Player, not Windows [Media Player]...
We can't port QuickTime without Apple's help. It's proprietary code. Those Java QuickTime APIs only work on the Mac OS X Java platform, because OS X includes QuickTime as a core technology. So we might be able to make a Java QuickTime player that runs under OS X (for all the good that does), but it will be missing the underlying QuickTime libraries to be able to run that Java application on Linux.
This isn't a matter of lazyness; porting QuickTime isn't an option for anyone but Apple.
AND THE WHOLE THING COMES WITH THE OS. Not on a separate cd you have to send away for or anything, but right on the retail cd.
I just bought an eMac, which came with 10.2 Jaguar preinstalled, as well as a pile of CD's. I can't find GCC or any other developer tools anywhere on the hard drive or on the CD's. Why would they include the tools with the retail boxed edition but not with a computer bought with the same version of the OS?
Killjoy
Aww... Hasn't the poor guy had enough lashes yet for such a small mistake?
Several people have suggested creating CPUs from FPGAs. Others have objected that such CPUs would be slow. Maybe they are, but you gotta start somewhere, right? (Just how slow is "slow" anyhow? Maybe you can't yet make a 2 GHz chip from an FPGA, but can you make a 200 MHz one?)
Here's an idea -- if anyone wants to design CPUs with FPGAs, why not aim for asynchronous CPUs? (See It's Time for Clockless Chips.) "In 1997, Intel developed an asynchronous, Pentium-compatible test chip that ran three times as fast, on half the power, as its synchronous equivalent." (Of course, that's assuming that FPGAs aren't already locked into a synchronous design...)
It sounds like asynchronous chips are the "way of the future" and inherently more efficient -- if free tools are going to be created anyway, why not have some geared toward asynchronous designs? It would be a worthwhile research effort, at least.
Who knows? If a particular design works out well on FPGAs, maybe some chip manufacturer will be willing to mass-produce the chip at much higher speeds. It could be a good thing all around...
Oh, and the original poster is an idiot for not providing some sort of reference. Extraordinary claims require extraordinary proof... didn't anyone tell him that?
Am I the only person here who read the statement as an accidental homonym substitution? The original poster wrote:
(*i know of know such company).
From the context, I read it as a disclaimer to indicate that the example was for rhetorical purposes. He should have written this:
(*i know of no such company).
Now, doesn't this seem more likely to be what he meant, rather than a vague, unsubstantianted, extraordinary claim? Yet, strangely, we have poster after poster demanding the name of the supposed company in question. Think, people!
Well, you got me there. I own a ReplayTV. And I have had it for several years now.
Perhaps ReplayTV owners almost never watch commercials, since they tend to skip over them entirely instead of watching the screen while fast-forwarding. I've tried enabling the 30-second skip on my TiVo, but I don't like it. And while I skip most commercials, on maybe 5-10% of them, I may rewind to watch the commercial if it looks like it might be interesting.
I'm willing to watch the commercials at 60x since it only takes a few seconds to scan through a commercial block. Even if the 30-second skip might save me a second or two, it's only taking 5-7 seconds now; does it really matter? Anyway, if the advertiser manages to get their message through to me in half a second, more power to them. If they can't, they should work on it.
I find that I can't tolerate watching commercial-sponsored TV live anymore.
That seems to be the case with most PVR owners, because they get impatient when forced to wait through commercials the old-fashioned way because they're watching live TV. Waiting 15 minutes is one solution -- ignoring the live schedule and watching whatever you have available is another.
The on-screen program listings are nice, time-shifting is great and all that, but the commercial-skipping aspect has become even more important to me as I've grown accustomed to it.
PVR's would still be invaluable for time-shifting purposes, even if you were forced to watch the commercials. Of course, the ability to skip commercials is very popular and an excellent reason to have a PVR, but you implied that it's the only possible reason one would buy one, and that's clearly false.
So far in all these replies, the only examples anyone has posted of watching commercials is this: [...]
I rewind my TiVo to watch commercials that look interesting frequently enough that it's a common occurrence, even though I do end up skipping most commercials. I haven't kept a log of which commercials have been successful at grabbing my attention and which aren't -- but the TiVo could potentially track that information. (During the Super Bowl, they analyzed the data and determined that the Britney Spears Pepsi commercial was the most-watch commercial among TiVo owners, for example...)
So I'm not buying people sidestepping my original argument of "what value to the Nielson Ratings purchasers are the opinions of TiVo viewers?" They're not watching the commercials except for four hours on a cold Sunday in January. If I were buying the Nielson service, perhaps knowing what shows the commercial-skippers are watching is just a good reason to not advertise on them.
This is a shortsighted viewpoint. Instead of treating PVR owners as a lost audience, this could be an opportunity for advertisers to gain some valuable insight into which ads are effective and which aren't. (Currently, the Neilson/TiVo software isn't providing them this level of detail, but it's possible.)
Think about it. Advertisers could hone their campaigns to a fine edge, learning to make better ads and avoiding the ones people hate to watch. This is a level of feedback that just isn't possible from simple focus groups. Since the PVR owners can skip the commercials so easily, if you can make a commercial they'll watch, it's more likely that the people watching live TV will watch too, rather than reading, channel surfing or going to the kitchen.
TiVo doesn't have to be the enemy of advertisers and commercial television in general -- there's a lot of potential synergy, and it makes new, less annoying marketing strategies possible. They just have to work together and try not to piss off the users in the process. (ReplayTV, on the other hand, has taken a much more antagonistic stance towards commercial television, so it's no surprise they're viewed as a clear enemy...)
- Part 1: E-Mail Users, Sites Growing Weary of Spam Onslaught
- Part 2: Spam Fattens Both E-mail And Bank Accounts
- Part 3: Anti-Spam Tools Are Not Perfect, But Can Mitigate Annoyance
(Just in case anyone is interested in the rest of the series...)TiVo viewers (along with ReplayTV viewers) DON'T WATCH COMMERCIALS. Why else would you own one of these machines?
You obviously don't own a TiVo.
Yes, most TiVo owners tend to fast-forward through commercials, though they can't skip them entirely or automatically (unlike ReplayTV). However, as the existence of primetime "best commercials" programs indicates, people will watch commercials if they're good. (Many people watch the Super Bowl for the commercials because advertisers tend to work harder on making those commercials better than the usual tripe.) While I routinely fast-forward through commercials on my TiVo, I also regularly rewind to watch one which catches my eye. The moral? If advertisers want people to watch commercials without needing to coerce them into doing it, they should make better commercials that are worth watching.
While skipping commercials may be popular (since we're all sick of being bombarded with commercial messages), timeshifting is the real killer feature of the TiVo, not commercial skipping. Until you "get it", the TiVo just sounds like a glorified VCR, but that's really an inadequate description. While a VCR is useful for timeshifting "must see" programs, it's enough of a hassle that it's only used when necessary. With a TiVo, most users soon find they're recording everything of interest (usually automatically), and watching programs when convenient. You stop scheduling your life around TV schedules, and there's always something you like available to watch no matter when you sit down at the TV. If you're interrupted by a ringing phone, you pause the TV. If you want to see something again, you rewind it. You can pause and rewind on live TV as well as prerecorded shows. (My 2-year-old daughter gets upset when we can't rewind the TV in the bedroom on demand!)
To the uninitiated, the TiVo's features seem more like parlor tricks -- neat tricks, but not really important, and not worth paying for when you have a VCR already. This is a fundamental misunderstanding of what PVR's are really about. It's not just an enhanced VCR. It fundamentally changes the way you watch TV, and once you get used to it, you'd never go back to the plain old VCR. Just ask any TiVo owner.
Better yet, go buy one from a retailer with a 30-day return privilege and see for yourself. I doubt you'll end up returning it!
Mr. Olman was speaking in favor of the Sonny Bono Public Domain Pillage Act (also known as the "Copyright Term Extension Act"). He bewailed the loss of revenues such Communists and anarchists as the Boy Scouts cost the poor, abused Content Cartel every year. (Blatant plug: The Post published my reply. Like a schlub, I've lost the actual WashPost link.)
I guess you didn't try hard to find it... the WashPost link was right there on the page you did link to!
Tom's managed to raise $10K this year [...] we spend $10K every day or so in salaries. [...] The reality is that we should be at more like $100K per day in salaries to really have a good product.
Maybe $10K-100K/day is good for a company, but suppose a single developer could bring in just $100K/year? That's only $275/day, a modest amount, but it's enough for most developers to be able to quit their day jobs and devote their time and energy to the project. So why is even this out of reach, especially for the many open source projects that thousands or millions of people find valuable?
The problem is that all you lovely slashdot folks want to get everything for free. And you'll insist on it if you can get away with it.
This is a conundrum. Many of us would like to be able to write good software and just give it away for free. Of course, everyone loves to get free stuff also. But we also need to eat, and giving away your work doesn't pay the bills. Unfortunately, it seems that most of the options suck.
We can try to create a business around our software, but that's expensive, difficult and prone to failure. It also requires sales and marketing efforts, support staff and other overhead. All this takes quite a bit more money than a single developer needs to make a living. Of course, new businesses have a very high failure rate, so this option sucks.
We can try to build a business around open source, but we probably can't bring in much revenue from sales of the software -- someone will turn around and give it away for free and undercut the market. We can try to bring in revenue with support or services, but this is uncertain, and only some markets can truly support a company this way. Many open-source companies have had trouble with funding, and there's little incentive to create high-quality software that "just works". This option sucks.
We can take the traditional route, keeping the software closed and selling it to bring in revenue. This can work, but charging for closed code will alienate the open-source community, and possibly even motivate volunteers to compete with you by writing free software. Many potential users who might have been interested will not buy the commercial product, so the market is much smaller, even if the return (per person) is better. Also, we'd rather be able to release our code as open source if we could. This option sucks.
Most of the truly effective business models we've seen for open source businesses seem to rely on some sort of hybrid where the code is open, but the revenue comes from a proprietary source, such as large companies paying for consulting or support, or paying to use the free code in their non-free products (a la Sleepycat) or offering proprietary components to work with an underlying free system (a la Sendmail), etc. These can be effective, at least, but they often depend on someone else making money from closed software, or depend on the whims of large corporations who may make their money elsewhere. So these options can suck too, but at least they can be workable.
I think the root of the problem is human nature. We like free stuff, and we think we're getting a bargain if we get away with not paying for something, especially if we're told that's okay. So it's quite rare for us to send money to send money to authors of free projects, no matter how much we may value those projects. And even when a few of us do, it's just a drop in the bucket.
What developer can afford to quit their day job just because every week a half dozen users take it upon themselves to donate $20 when they didn't have to? Sure, it's nice. No doubt it's appreciated, but that $120/week would be barely over $6K/year, which is far too little to live on. Begging for donations just doesn't work well, whether it's a developer, a charity or public television.
On the other hand, if each of 10,000 users would pay just $10/year, that would be $100K that could support that developer and allow them to quit working a day job. Why doesn't this work? Because each of those 10,000 users will tell themselves that the other 9,999 users can pay their $10, and nobody would miss that $10. And it's true; $99,990 would be just as good as $100,000. Unfortunately, the vast majority makes this same argument, and suddenly you're back at $6K instead of $100K.
So, here's the question. How can we get the masses of regular users to pay a modest amount of money, on a regular basis, to support development of the software they want? And can we do it with the free-redistribution clauses in open-source licenses, or is it only possible if redistribution is restricted? Is it compatible with the GPL? Can we offer some other tangible selective benefit that only the paying users will benefit from, that will convince them to join up?
How about some creative responses here? You, there! Yes, you! What would convince you to chip in some money on a routine basis?
Here are the conclusions I came to:
- I would use the QPL as the initial license. Since the QPL is an open-source license, but requires that changes be distributed as patches against the original distribution, this should discourage code forks (although they're still possible) and make it clear which code I've "blessed" and what code is modified. (I don't want to be blamed for a bug someone else introduces...)
- Ultimately, I expect to switch to another license (probably an MPL/LGPL/GPL triple license a la Mozilla), but not until my project is sufficiently well-established that it can't be trivially eclipsed by a forked project with a more active maintainer using my own code to compete against me.
- For now, I want to maintain a tree which is 100% my own code, both for "vision" reasons and as a potential demonstration piece for my programming skills. However, I don't expect this branch to last forever; once my initial vision is "finished" enough and up to my own quality expectations, it will no longer be important to have 100% of the code written by myself.
- Meanwhile, if others contribute worthwhile code, I expect to branch a new "community" version which will include code contributed by others, as well as my own code. This version would probably become the recommended version, and I'd probably have to work harder to apply my own changes to both branches. (Rather than branch a new version for this, it may take the form of branching the "100% mine" version and considering the mainline version to be the community version.)
- I won't accept code (even for the community branch) that is poorly written or seems to fundamentally conflict with the rest of the project. However, I will happily maintain a "contrib" area of patches that I choose not to integrate, so others can apply them if desired. (Hopefully, this should reduce the incentive to fork the project, also.)
- For worthwhile code contributions that constitute an unwanted shift in direction for the project, it may make sense to create a new branch for that purpose, rather than rely on "contrib" patches on sources that are likely to diverge. (In this case, someone would probably need to volunteer to maintain the branch, if it's not one I'm personally interested in.)
- I decided that it is critical that (potential) contributors never be ignored. Ignoring a contribution is worse than rejecting it outright. A rejected contribution (with constructive criticism) may lead to new and better future contributions, while an ignored contribution is likely to lead very quickly to the loss of interest by that contributor.
- If a patch is incomprehensible, a discussion with the contributor is in order, and perhaps a rewrite as well.
- If someone forks the project, so be it. Hopefully it won't happen, but it's always a risk. It's more of a risk early on, which is why I'm using the QPL for now.
- I decided to treat the project as if it might be used for "production" use, on general principle. However, rather than the simplistic (and somewhat ineffective) even/odd numbering approach of the Linux kernel, I decided to take a different approach to version numbering:
- Most importantly, I decided that no release will ever be declared "stable" without spending some time out there as a "release candidate" first, to allow time for any bugs to be found and reported. The "stable" release would therefore be virtually identical to a previous "unstable" release candidate, except for the version number and perhaps small nonfunctional changes like documentation No code changes should be introduced as a "stable" release. (This has caused too many "brown-paper-bag" releases in the "stable" Linux kernel series in the past, for example.)
- To distinguish "stable" from "development" (unstable) releases, I decided that the "stable" releases would be all-numeric (e.g. 1.0.0) while "development" releases would always contain alpha characters in the version number (e.g. 1.0.0.beta.3).
- To distinguish various levels of stability and approach to stable status, I decided to use word tags like "experimental" (maybe "exp?), "devel", "alpha", "beta", "rc", etc. This would be followed by a sub-release number in the same group.
- For development releases, I decided to use the next target stable release number as the base, hence "1.0.0.beta.3" precedes "1.0.0" instead of following it. (Of course, "1.0.0.rc.1" would be in between those.)
- In the case of branches for experimental coding, I decided to use named branches rather than a numeric branching scheme. Hopefully, all branches would start from a stable release, although I suppose they wouldn't have to. (I'm not sure exactly how to number named branches, but starting with the base revision of the branch point seeks probable.) If a branch looks like it will become long-lived and separately maintained, I imagine it would migrate into a new subproject name for the codebase and become the mainline version for that subproject.
- I decided that binary distributions (e.g. RPMs) should be offered for "stable" releases only, not for development releases. (Release candidates would probably be an exception, offering binaries temporarily, until the next release candidate or stable release, since they're intended to be stable releases and should be tested by non-developers...)
- I decided that the cycle between stable releases must be kept short to ensure that development never diverges far from the last stable release. If a non-developer wants to install a development release, that's a sign that the stable releases are too far apart!
- I decided that development releases would come with patches against the previous development release, but that stable releases would come with patches against the last stable release instead.
- I decided that a CVS server should be made available for people who want to track the development without having to download each development release or keep patching.
- I decided to cryptographically sign each release to ensure its integrity.
- I decided that I should have a bugtracking system (like Bugzilla) and place a high priority on fixing any trivial bugs to try to keep prople from getting discouraged when even the simplest bugs they report don't get fixed. Ideally, the bugtracking system should allow for easy integration with bug reporting via email.
- I decided that there should be at least two mailing lists (an announcements list and a developer's list), in addition to Freshmeat announcements of releases.
- I decided that the project should have a website, ideally one which has frequent updates (i.e. news items) every day or three. (There's nothing more boring than returning to a website to find that nothing has changed!) Screenshots are also good, if possible -- people love screenshots!
Unfortunately, I haven't had the time to get my project into the shape I want -- the website is woefully inadequate right now (ugly and too static), there's no bugtracking system or mailing lists yet, I don't have a CVS server available yet, and I haven't gotten to the point of declaring a "stable" release yet. But I've been announcing the few releases I've made on Freshmeat, and signing the releases for integrity, and using my version numbering scheme (which I'm tuning as I go; it's a work in progress), and I've got a demo server running. It's coming along, but it takes a lot of work, and I never seem to have much time. Of course, this is exactly why I used the QPL, because I expected to be less active at maintaining the project than I ought to be...In the end, I'm just making this up as I go along. I'm sure I'll make some mistakes, and others may not agree with every decision I make, but I choose to operate in the "benevolent dictator" model, not a "democratic" model. I reserve the right to be arbitrary and capricious, though I'll try not to be. Anyone who doesn't like it can fork the project, just as someone could fork Linux if they don't like Linus as benevolent dictator.
Of course, this is largely a moot point so far -- my project has generated very little interest yet and no contributors at all -- which seems to be the norm for small open-source projects. But I figure I might as well try to figure out some "best practices" from the start as I go along rather than wait until things get out of hand to start trying to implement them after the fact...
You can get an open-source spellchecker at mozdev.org that works with some Mozilla releases but I'm not sure if they've updated it to work with 1.1beta.
Um, why should it need updating to work with 1.1beta? I thought the whole point of the 1.0 release was to freeze the API so that they work across all 1.x versions! If the spellchecker works with 1.0, shouldn't it work with 1.1beta, out of the box? (If not, then what was the point of the API freeze?)
Sure, unless I'm also running it. Then, we can't talk to each other because our polite automated replies won't be read.
That seems like a nasty Catch-22. I wonder what the solution is?