Slashdot Mirror

Browsers are pretty complicated, yes. Things like low-latency high-performance VMs, hardware-accelerated video pipelines, plus the details, like actual HTML parsing, CSS layout, a network stack, and so forth. Also, what matters is not just the complication but how fast you're trying to change things, and people are adding new things (flexbox, more complicated CSS layout modes, mode DOM APIs, etc) faster than ever before.

But also, in addition to a browser Mozilla is working on FirefoxOS, which involves a whole separate bunch of developers, since it's not like the browser developers are writing things like the dialer app for FirefoxOS. Also, you need QA, not just developers.

And yes, Mozilla has 1000-ish employees, for what it's worth.

It's not just Mozilla. If I look at https://www.openhub.net/p/chro... I see on the order of 600 committers with commits in the last month. And that's not even counting whoever is working on the non-open-source parts of Chrome. And not counting, again, QA and so forth.

And the worst part is, this is not a new development. Microsoft had over 1000 people working on IE6 in 1999, according to http://ericsink.com/Browser_Wa...

So yes, browsers, complicated.

Another link from Stack Overflow (http://stackoverflow.com/questions/1469623/a-few-basic-version-control-questions) was a link to this series of articles on source control by Eric Sink: http://www.ericsink.com/scm/source_control.html Chapter 0 includes his list of benefits:

• It provides a place to store your source code.
• It provides a historical record of what you have done over time.
• It can provide a way for developers to work on separate tasks in parallel, merging their efforts later.
• It can provide a way for developers to work together without getting in each others' way.

For a completely non-technical manager, a money analogy is probably more appropriate. Remind them that their source code represents the total of investments they've made in developing software. It's the output of thousands (or millions) of hours of very expensive labor. A source code control system is like a bank, keeping their investments safe and organized.

From there, you can use all of these arguments to point out how expensive it can be to not have a source code control system. It's a single point to back up, making maintenance of all your source code simpler and more manageable. It lets you get back to when something worked, in case someone's made a change that broke stuff. It's an efficient way for developers and projects to share code, to browse the whole library of what you've got. Let them know that it makes people working on a program more efficient, because they're not spending time hunting down where the code is hiding. Let them know that the development tools you already use have the capability to integrate into source management tools (assuming you use Eclipse or Visual Studio) and that they work faster with them. A good source code management system makes things faster, not slower.

You might give them specific examples of a couple of costly failures that impacted your organization. "Remember that time Joe spent two months working on Project X, and then his PC crashed and his disk drive went bad? Remember when Jane suddenly left and nobody could find the stuff she'd been working on? Those incidents had to have cost us several thousand dollars each in wasted effort redoing all that work. A source code control tool would have prevented them automatically."

You could remind them that it's a computer program whose entire purpose is to automate the processes that your people are currently managing with manual processes. It can do those tasks far more reliably and much faster than the humans.

And to dive off the deep end, a complete application lifecycle management system makes it much easier to organize everything about your products. It lets you manage everything by storing it all in the tool, such as requirements or other project documentation, along with the source code. You can manage the projects in the tool, by assigning work items in it, collecting and managing bug reports, creating tests, managing product feature backlogs, etc. An ALM tool can make the project visible to everyone involved by presenting project status on a web page. But given that your manager doesn't yet understand the value of such an ordinary and foundational tool as a source code management system, you'd no doubt scare them off by throwing out an ambitious plan to change a lot of stuff. But it wouldn't hurt you to consider features like those as potential next steps of improving your software engineering practices.

Please. You really have no idea how the industry works, and why some companies thrive and some die. I'll give you a hint, there's one reason, and one reason only that tech companies die. And it has little to do with Microsoft (though certainly, they have their hand in it).

That reason, is that they fail to provide a product that consumers want. Microsoft is really good at making consumers want it's products, thus it gives people what they want, and people buy it. Let's look at your examples.

Wordperfect? They sat on their laurels after Windows was released, were late with a Windows product, and that product sucked and their existing userbase did not like it. They failed, time and again, to produce a product that their customers wanted in the GUI world. They ruled DOS, but they miscalculated how quickly DOS would die, and how people would quickly jump ship to a better product. In other words, Wordperfect created suicide. Later owners of the technology didn't do a lot to differentiate it from the by then dominant Word. Then, the companies that owned the technology did not put enough money behind it, and they would sell it off again and again before it could gain traction.

The guy that invented the spreadsheet is Dan Bricklin, and Visicalc was killed by Lotus. Microsoft didn't even have a decent spreadsheet until years after Visicalc was dead.

visual programming? I don't think that term means what you think it means. I'd be interested to know what company you're talking about.

The first commercial web browser? That was Spry. They sold a product called "Internet in a box", derived from NCSA Mosaic. This product existed and died before Microsoft even entered the market. So i have to wonder exactly how it was that Microsoft killed them. Spyglass was the next, and though they licensed the name Mosaic and technology from NCSA, they never used any of the code and wrote everything from scratch. It's true that Microsoft was the cause of their destruction, but it was because Microsoft out-developed them. They had 1000 Developers on the IE team, and spyglass had 20. None of this had anything to do with anti-competitive behavior, other than that Microsoft could use it's massive war chest to out-develop everyone else, and frankly there is no law against that.

You should really read http://www.ericsink.com/Browser_Wars.html as that covers it pretty well.

GEOS? Are you freaking kidding me? That was an 8086 based task switching system, no memory management, etc.. it did a lot, sure.. but they didn't have the resources to make that into any kind of major product.

Finally, we get to BeOS. BeOS was killed by Apple, not Microsoft. Ok, Microsoft may have leveled the killing blow, but apple crippled them to the point that a toddler could have killed them. Why? Because BeOS was positioning itself to be the next MacOS. They thought it was a done deal, until apple went behind their back and bought NeXT instead (just noticed, both of those have 3 capital letters and one lowercase, an e in both cases). Be had put all it's eggs in the Apple basket, and apple crushed them. In a last ditch effort, they decided to port to x86, but they were already a dead man walking and only had a handful of developers doing all the work. They couldn't support a commercial OS with that.

IE was purchased by Microsoft. They didn't do some dirty trick, they found a company making a product they liked and purchased them. Not just the rights to their product, the brought on the developers and all that.

The story is quite different if you listen to Eric Sink, and he was there so I'm going to believe him unless you provide some evidence. According to him MS did license the Spyglass code: Memoirs From the Browser Wars. JImbob0i0 already pointed out the financial shenanigans MS did in that deal.

However people whine and bitch far too much.

Sometimes they also get their facts wrong.

No, it was called SpyGlass Mosiac and they wrote it from scratch after licensing the technology and trademarks from NSCA: http://www.ericsink.com/Browser_Wars.html

A nice quote from Eric Sink's Source Control HOWTO:

Recently when I asked my fifth grade daughter what she had learned in school, she proudly informed me that "everyone in Korea eats kimchi at every meal, every day". In the world of a ten-year-old, things are simpler. Rules don't have exceptions. Generalizations always apply.

This is how we learn. We understand the basic rules first and see the finer points later. First we learn that memory leaks are impossible in the CLR. Later, when our app consumes all available RAM, we learn more.

According to this link, Spyglass Mosaic, which was licensed by Microsoft, didn't include any code from NCSA Mosaic. Assuming that's correct, Microsoft didn't use any NCSA Mosaic code, but did use Spyglass Mosaic code, so I suppose it's a matter of the interpretation of 'Mosaic code'. I had in mind the NCSA Mosaic code in my original post.

This won't Look right either but I'll try

Oh, wait... Google.

http://www.ericsink.com/bell.gif has a great picture with it all quartered up (ty images.google.com)

if you look carefully, you can see the left and right ends both have the bulk of their "curve" in the middle, while the tops have their curve nearer to the peak. I can't remember what the switchpoints are called. Calc was a LONG time ago!

Licensing our browser was a huge win for Spyglass. And it was a huge loss. We got a loud wake-up call when we tried to schedule our second conference for our OEM browser customers. Our customers told us they weren't coming because Microsoft was beating them up. The message became clear: We sold our browser technology to 120 companies, but one of them slaughtered the other 119.

Huh?

Um, I would like to see your reference material; yes, IE was an offshoot of Mosaic, but it's been established that IE came from Spyglass. MS was to give a percentage of the revenue of sales of IE back to Spyglass, and that they screwed Spyglass over by charging nothing for the use of IE, resulting in as little money as possible going back to the original developers. Spyglass of course, tanked.

Please, try to take the 4 minutes it took me to search, vet, and link material for your claims - it'll help everyone out, including you.

• A lot of the blogs out there are written by people starting companies. They have a limited time to get a product out and selling it before they run out of money. If they sit around thinking up the most perfect design ever, they run out of money and the software never gets finished. (blogging and slashdotting increase productivity though, of course)
  
• You need to get your software in front of your customers as soon as possible to get feedback on it, and let that change the product into something the customers want. If you're off in la la land designing forever to get things JUST RIGHT, and then implementing it FLAWLESSLY, with ZERO DEFECTS, well, you're going to have a SHIT PRODUCT that no one wants. But it'll be easily maintainable.
  

...Eric Sink, has a interesting piece on his blog about open sourcing Java. He says he's a C# programmer now, so kind of a different perspective...

Actually, it didn't come from NCSA Mosaic. It came from Spyglass Mosaic - a completely different browser...

I don't know, but "About Internet Explorer..." for version 5.2 on the Mac says "Based on NCSA Mosaic(TM)".

Spyglass licensed the NCSA Mosaic code and trademark but only ended up using the Mosaic trademark. The Spyglass Mosaic code was original. See http://biztech.ericsink.com/Browser_Wars.html, written by the Spyglass Mosaic project lead.

In any case, there's probably very little Mosaic code left in Internet Explorer.

Both Eric Sink (the founder of SourceGear) and Joel Spolsky seem to think so. (You'll have to search for the relevant articles yourself--I'm not going to dig through years worth of archives for you.)

Their thinking is:

1. If the guy in charge doesn't understand the technology, he (or she) will make bad strategy decisions. Spolsky's example is John Scully's decision to build a device that recognized handwriting (which is impossible, or at least very hard) vs. Bill Gates' asking his developers to write a reusable rich text edit control (which Microsoft ended up reusing for everything).
2. At the small company level, business stuff (aside from law and accounting, both of which can be outsourced) tends to be easy enough that a geek can learn it without too much trouble. Therefore (says Eric Sink), it's a better use of money to get technical people than business people.

On the other hand, the business guy is your friend and anyway, he's willing to talk to investors and answer the phone during the daytime (I'm assuming) so he's probably worth keeping around.

I think that what I'd do in your situation is give the business guy the job of CEO but retain a 51% ownership of the company. That lets him do the day-to-day business stuff and give the people he talks to a sense that they're talking to the guy in charge while at the same time letting you set him right if he tries to do something stupid.

Disclaimer: I have no actual experience in this. I'm just makin' stuff up.

Lets make this straight, what needs to be done in the business at first.
You need to develope the thing.
2nd you need to sell the thing.
3rd you need to do some paper work.
4th discuss with investors if you cannot do above well without pouring more money to it.

The 2nd part happens after most important risks related to business have already taken. And 3rd part isn't big deal until you have your start hiring people. 4th part is only important if you plan to hire or cannot sustain your living entire developement time.
So basicly if your thing isn't ready nor the business person do not add value to your business so you are already getting ripped off by giving him 50% of your business. And if its ready the business person should invest the money atleast equal to 5 times the salary you would of taken when developing the thing, in order to match your investment on the business.

I'd say read the Eric Sink:s articles beginning here. They teach part of the business part that geeks need to know. Basicly business part is easy if you need to know it. And computer guy is far better in the helm of software company than a business person. Since software person understands whats possible, and what not and proper technical trade offs.

Of course if he can do developement too and his domain expertice is needed for making the product then it wouldn't be obvious who should get bigger part. Oh and 50% /50% deal someone ALWAYS gets ripped off since people don't invest equal amounts of time to the business.

http://software.ericsink.com/bos/Geeks_Rule.html

As opposed to NCSA Mosaic and Spyglass Mosaic. MSIE didn't even exist at the time. some history for you.

I think my point is; what might seem like network abuse today is likely to be SOP in a few years time.

Revered? Irreverant is more his style. Authoritative? He's pretty authoritative on early versions on Excel and on running a small business and staying afloat. Interestingness (or lameness) is subjective and you are entitled to your opinion, but I dare say the reason the reason people link to him is because they do find him interesting.

And oh, about that 'lame blog entries' dig? A lot of people like blogs because they reveal a lot about the person. They sure make for more entertaining reading than PR pap, Unix man pages and the typical low S/N mailing list. Sure, you get angst-ridden teenagers, but you also get law professors, call girls, people who run their own small business, SGML and XML gurus. On message boards like Slashdot, though, you get dupes and the same old tired arguments about Open Source and Digital Freedoms and (bonus!) Slashdot commenters complaining about how lame other people are. Oh the irony.

No, he stated his remedy. Hire people who have self-control. You know, the kind who doesn't bray to the world at large what he did on last night's date or how her child delivery went in explicit detail. Self control and maturity will yield a decently quiet work place all on its own. I would say the chances of a company hiring a work force where each and every one of them has that level of self control and maturity is as likely as slashdot.org porting their codebase to C# and .NET. Eric Sink, of EricSink.com has an article regarding the harzards of hiring. Your best bet is an environment where developers, with a little help from headphones and music can ignore the outside world. For most, I would say that an office, or shared office, works best. (Which is why I wrote "Don't work in Cubicles, ever.")

No, he stated his remedy. Hire people who have self-control. You know, the kind who doesn't bray to the world at large what he did on last night's date or how her child delivery went in explicit detail. Self control and maturity will yield a decently quiet work place all on its own. I would say the chances of a company hiring a work force where each and every one of them has that level of self control and maturity is as likely as slashdot.org porting their codebase to C# and .NET. Eric Sink, of EricSink.com has an article regarding the harzards of hiring. Your best bet is an environment where developers, with a little help from headphones and music can ignore the outside world. For most, I would say that an office, or shared office, works best. (Which is why I wrote "Don't work in Cubicles, ever.")

Can you point to a particular line in the Linux kernel or Apache, for example, and identify who screwed it up?

Then there are the people who just don't care, or the excuse-makers who always blame the "impedance mismatch" between two pieces of code on the other guy or say that you can't apply traditional software-engineering standards when anyone who doesn't like it can change it themselves, etc. etc.

• People who just don't care about the code are more likely to be working for money in a closed-source proprietary environment, where there is the temptation to use obscure techniques to enhance job security, than they are to be contributing to a FOSS project.
• The "other guy" that people who blame the other guy would like to blame is likely to be known to the project lead, and better known than the excuse-maker. Shifting fault to another department "works" in an environment where functional software is merely an expendable means to an end, the true end being promostion within the system to a more rewarding position; because the customer is a captive, and has the choice of tolerating whatever disfunctional mess you provide or incurring the cost of changing to another system. It fails in FOSS; there is no other guy to blame, because after all you can identify the problem in whatever codebase it may lie and provide the patch; and the customer who despairs of your ever solving your organizational psychodrama has everything needed to begin a fork-with-less-crankiness.
• In FOSS, any compulsion to follow a software engineering principle arises from a desire to get your changes accepted by the maintainers, not from a desire for a promotion or fear of demotion. Maintainers who misjudge the balance between regulation and laxity will lack for contributors. In the closed proprietary environment, a programmer need please only the person who wields administrative authority (the ability to hire, fire, and adjust salary).

Can you point to a particular line in the Linux kernel or Apache, for example, and identify who screwed it up?

Then there are the people who just don't care, or the excuse-makers who always blame the "impedance mismatch" between two pieces of code on the other guy or say that you can't apply traditional software-engineering standards when anyone who doesn't like it can change it themselves, etc. etc.

• People who just don't care about the code are more likely to be working for money in a closed-source proprietary environment, where there is the temptation to use obscure techniques to enhance job security, than they are to be contributing to a FOSS project.
• The "other guy" that people who blame the other guy would like to blame is likely to be known to the project lead, and better known than the excuse-maker. Shifting fault to another department "works" in an environment where functional software is merely an expendable means to an end, the true end being promostion within the system to a more rewarding position; because the customer is a captive, and has the choice of tolerating whatever disfunctional mess you provide or incurring the cost of changing to another system. It fails in FOSS; there is no other guy to blame, because after all you can identify the problem in whatever codebase it may lie and provide the patch; and the customer who despairs of your ever solving your organizational psychodrama has everything needed to begin a fork-with-less-crankiness.
• In FOSS, any compulsion to follow a software engineering principle arises from a desire to get your changes accepted by the maintainers, not from a desire for a promotion or fear of demotion. Maintainers who misjudge the balance between regulation and laxity will lack for contributors. In the closed proprietary environment, a programmer need please only the person who wields administrative authority (the ability to hire, fire, and adjust salary).

It's a mistake to think of a successful company being the product of (1) a concept and (2) some capital. There really are three parts: the idea, the capital, and the execution. The execution is probably the most important factor on whether a company will succeed or fail. Eric Sink wrote it best (most provocatively?) when he claimed that ideas are worthless in an essay last year.

Look at Joel Spolsky (Joel on Software): he makes a bug tracker. Not a very novel idea. But he does it well, so his company is profitable and revenues are growing quickly. There are thousands of other companies out there doing the same thing. Proctor & Gamble doesn't sell anything particularly unique, they just do it well. And there are a hundred "low-cost" airlines out there, but JetBlue and Southwest are profitable because they've executed the idea correctly.

Venture capitalists are people with money and who choose not to execute on any ideas directly. There's nothing wrong with that. I don't know many people that would truly want to put in the effort required to create a winning technology startup.

Internet Explorer was not derived from NCSA Mosaic. It was derived from Spyglass Mosaic. Spyglass licensed the technology and trademarks from NCSA. But they did not use any of the NCSA Mosaic source code[1]. Microsoft then licensed Spyglass Mosaic from Spyglass.

References:
[1] http://biztech.ericsink.com/Browser_Wars.html

"Based on NCSA Mosaic. NCSA Mosaic(TM); was developed at the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. Distributed under a licensing agreement with Spyglass, Inc."

However, M$ did use their financial clout to kill the competition once they had the knowledge 'in-house' (it must be nice to be a multi-billionaire says I, somewhat jeolously).

An interesting blog on this by one of they key players who helped develope Spyglass Mosiac can be found here.

From TFA: " But Gates rallied Microsoft to develop its own browser, which it then bundled free with Windows." The reality is that IE was built on an older browser called Spyglass http://software.ericsink.com/Browser_Wars.html Upto IE 4.0, vestiges of Spyglass have lingered. Only an insider can tell us whether this is still the case with IE 6.0

IE is based on Spyglass Mosaic, not NCSA Mosaic.

Spyglass licensed the technology and trademarks from NCSA for producing their own web browser but never used any of the NCSA Mosaic source code.

See http://biztech.ericsink.com/Browser_Wars.html

"But to live up to the title of Software Engineer, you need to be much more proactive and be very involved in the non-programming aspects such as requirements gathering, documenting, designing, documenting, prototyping, documenting, and documenting."

You make an excellent point. It's the difference between being a developer vs being a "programmer", something that Eric Sink (founder of a small ISV called SourceGear) wrote a very nice article about.

Eric Sink has recently started writting a detailed HOWTO off of his personal website titles "Source Control HOWTO. He doesn't just cover his own companies project "Vault", but also touches on CVS, VSS, and Subversion.

In my IT career I've used VSS, PVCS, a bit of CVS, and now becoming more familiar with Subversion behind GForge. Of all the documentation I've consumed, Eric Sink's article has so far been the most thorough (and least dry!)

As for the comments regarding source control being overkill for personal projects; I feel there is a misconception that source control will add continually overhead to a project. The initial setup may be a pain, but when refactoring components, it's much easier to perform differences along a file's history from a source control system than diff directory which you manually copied to perserve a "version". I've done it both ways, and found using source control with my solo projects to provide a multitude of benefits. I could list them out here, but I believe they're all addressed (and then some) in the HOWTO.

Eric Sink has recently started writting a detailed HOWTO off of his personal website titles "Source Control HOWTO. He doesn't just cover his own companies project "Vault", but also touches on CVS, VSS, and Subversion.

In my IT career I've used VSS, PVCS, a bit of CVS, and now becoming more familiar with Subversion behind GForge. Of all the documentation I've consumed, Eric Sink's article has so far been the most thorough (and least dry!)

As for the comments regarding source control being overkill for personal projects; I feel there is a misconception that source control will add continually overhead to a project. The initial setup may be a pain, but when refactoring components, it's much easier to perform differences along a file's history from a source control system than diff directory which you manually copied to perserve a "version". I've done it both ways, and found using source control with my solo projects to provide a multitude of benefits. I could list them out here, but I believe they're all addressed (and then some) in the HOWTO.

As for the OS "that fills your hard disk" - unless AmigaOS is capable of running from a 128Mb USB dongle, I really don't care whether it takes 250Mb or 10Gb on my hard drive. I use my PC to actually run software that helps me do my work, not to meditate on df output.

Finally, always remember the Law of Duality. This explains very nicely why neither AmigaOS, nor BeOS would ever enjoy significant popularity on the market.

Oh, and BTW, I really don't care about the stage GUI gets loaded at. On workstations I use the GUI so it doesn't matters and on the servers, GUI gets swapped out pretty quickly.

For independent software development and running your software business:
Eric Sink
Joel on Software (read business of software newsgroup)

For inexpensive, reliable order processing:
SWREG
ShareIt

Installers:
NSIS (Windows)
BitRock (Linux, Windows)

Icons/Website:
Go to KDE Look find some artwork you like and contact the author.

I think you might have a point. Such a tactic would be a classic monopolist tactic. Charge different prices to different people based on their demand level (money willing to spend.) That way you maximize your fleecing of the public.

They already do. See Personal (or Home) vs Plus vs Professional vs Enterprise (or Data Centre).

They already spent the cost in developing the more advanced version. There is fiscal reason to make someone pay more for an advanced version (excepting support costs, but those could be marketed as as service). It's pure marketing.

Read the section titled "Price Is Not Just a Number" in Product Pricing Primer.

First, I've read Graham's essay, and his definition of "Great Hacker" is on the vague side, and consists largely of platform advocacy. It turns out that his "great hackers" are all people he knows. Fair enough: He can't really judge anybody else. But that leaves him with such a small and selective set of data that his conclusions are meaningless. For example: He claims that all "great hackers" refuse to work on Windows. He works at companies developing software for UN*X. Not surprisingly, most of the programmers he knows are UN*X people, who don't work on Windows. So what? This proves nothing at all. He has merely suggested (however plausibly) that Windows developers tend not to develop for UN*X and vice versa, which is tautological. Dennis M. Ritchie has a Windows box on his desk these days, but Graham doesn't know Ritchie personally, so Ritchie's not considered. Graham's working from a thin set of anecdotes.

Secondly (and this has been said before), Graham's "great hackers" are prima donnas who refuse to deal with practical problems outside some very limited set of problems that they enjoy. I remember a story about Richard Feynman helping paint the walls at Thinking Machines when he worked there; I guess Feynman wasn't a "great hacker".

Finally, I often hear from Java advocates that the memory-lebensraum problem and the speed problem are due to programmers not understanding the internals well enough to work around their flaws. This is not said to be true of any other programming language on Earth, as far as I know.

It all sounds like a crock to me. Knowing the tools better will always help, but if only an expert can write usable code -- not great, but merely usable -- the language is junk, or at best the implementation is junk.

From my own work experience, I think he is right (in some situations). There certainly are many great hackers I've worked with whose technical skills I respect but I would never want to work with again. Of course, I've also worked with a lot of great hackers who were also great employees, so it can go either way. But any hiring manager (or any employee for that matter) would be wise to remember that the person's technical skills are only part of a bigger picture.

Case in point: Microsoft started nearly from scratch (licensed a simpler browser, IIRC) with IE, at around the same time Netscape decided it was unable to maintain its aging source code. IE overtook Netscape

You might want to read Eric Sink on how this happened:

What was interesting was the day we learned that Netscape didn't have the funding to keep up with Microsoft. (...) At one of those meetings we sat down for a talk which was a major turning point for me and for Spyglass. Scott told me that the IE team had over 1,000 people.

I was stunned. That was 50 times the size of the Spyglass browser team. It was almost as many people as Netscape had in their whole company. I could have written the rest of the history of web browsers on that day -- no other outcomes were possible.

Well you're making the other guy's point, since KHTML was, precisely, (open source and) being reused.

Windows and IIS were the most convenient platform for our corporate web site given our .NET product focus. You can visit Eric's Eric's personal web site, which was running Apache last time I checked.

Eric Sink is well known for liking the .NET platform. Since he has actual experience developing fairly complex products with both .NET and Java, I don't think anyone should be quick to dismiss him as a Microsoft fanboy.

"Does anyone know of a marketing-for-geeks HOWTO file anywhere?"

Its not a file but its a small web site but here it is. Marketing For Geeks

Learning to market ourselves would definately help the bottom line for all the geeks around the world. We could all ban together to form an empire like no other. Would it be good, now thats an answer I just can't give you.

http://software.ericsink.com/Browser_Wars.html