5 ms·

And so I'm giving up the Mozilla project - Jamie Zawinski (1999)

diego 16y ago
I interviewed at Netscape shortly after they announced they would release the browser as open source (June '98, ended up going to Inktomi). I remember being very excited about this, and downloading the source when it first became available. I found out that my (decent) desktop machine was not powerful enough to compile it. When I found a machine that could compile it, it took about 8 hours. No surprise that it remained a Netscape project for so long.
- daimyoyo 16y ago
  "When I found a machine that could compile it, it took about 8 hours." Thank you. It never occurred to me that you need a lot more processing power to compile code than you do to run the software you're creating. You just saved me a lot of heartache in a few months once it's time to start compiling. I love HN. /srsly
  - windsurfer 16y ago
    ...Could you explain? I don't understand what you're saying.
  - Simucal 16y ago
    This isn't always the case. It is highly dependent on the language, the compiler used, the size of the code-base and many other factors. Most of the small to medium sized project I have worked on compile in what seems like an instant. However, I work on a medium-to-large code-base at work and it takes around 8 minutes to compile on our build server and around 12-15 minutes on my dev machine. Even these speeds seem tremendously slow to me. I can't imagine being a developer on a huge C++ project and having to wait tremendously long build times. When your compile times aren't near instant it really changes how you program. That feed back loop of code-compile-run-repeat becomes more like code-double check code-code some more-compile-surf the web-run-repeat.
    - rayval 16y ago
      Ideally, you should not be in this situation where you have to compile large amounts of code to go through the code-test-debug cycle. Even in a large project, there should be subysystems that a developer owns and works on that can be partitioned or isolated from the rest, and execute within a test harness on a dev machine -- a harness that feeds the subsystem inputs and records outputs. Successful projects either begin with or evolve to a state where they have the architecture, the toolset, the process and the culture to allow devs to enjoy a fast code/debug cycle.
      - Andrew-Dufresne 16y ago
        Besides subsystems, tools like make and nmake utility can also reduce the compile time. Make figures out automatically which files it needs to update, based on which source files have changed. It also automatically determines the proper order for updating files, in case one non-source file depends on another non-source file. As a result, if you change a few source files and then run Make, it does not need to recompile all of your program. It updates only those non-source files that depend directly or indirectly on the source files that you changed.
        voxcogitatio 16y ago
        Yes, but large projects often need to use recursive makefiles, which are notoriously flaky at detecting what has changed (if anything).
        drothlis 16y ago
        No project needs to use recursive make. "Recursive make considered harmful": http://miller.emu.id.au/pmiller/books/rmch/ http://miller.emu.id.au/pmiller/books/rmch/
    - alnayyir 16y ago
      ccache. Come on guys, this is basic tooling.
  - gaius 16y ago
    It never occurred to me that you need a lot more processing power to compile code than you do to run the software you're creating It never occurred to you because it isn't true! You could for example write a trivial raytracer that compiles in seconds and takes hours to render a scene.
  - rmc 16y ago
    Also remember that compiling code can use memory. I once had a compilation causing the machine to swap. That took a while to compile.
  - sambeau 16y ago
    This is often the case. My last company had software that took 45 mins to compile on high-end machines in 2010.
thought_alarm 16y ago
5 short years later, mozilla.org shipped a product that was finally ready for prime time.
- asadotzler 16y ago
  And today that product is used by more than 400 million people around the world -- far more users than Netscape ever had.
  - seldo 16y ago
    Specifically, it was Phoenix (aka Firebird, aka Firefox) that made that happen: a version of Mozilla that threw out everything but the browser, including the mail client that jwz considered essential. It made it smaller to download and faster to run, but most importantly it made it faster to write: they could ship improvements to Firefox way faster than they could to Mozilla, simply because there was so much less of it.
    - InclinedPlane 16y ago
      Yup. A classic example of minimum viable product (although for phoenix far more than minimum). Phoenix was a breath of fresh air back then. Mozilla was as bloated and cumbersome as Netscape ever was, but Phoenix was fast, streamlined, and a joy to use. The turning point was when the RSA patent expired and Phoenix could fully support SSL out of the box without any wonky add-ons. At that point there was no longer a good reason not to use Phoenix/Fire{bird,fox} and it started gaining huge amounts of momentum.
      - yuhong 16y ago
        The RSA patent expired back in 2000.
- yuhong 16y ago
  I think by Mozilla 1.0 it was finally ready, but it was Firefox's marketing that finally led people to adopt it. BTW, you can partly blame this petition: http://archive.webstandards.org/ng.txt http://archive.webstandards.org/ng.txt
asadotzler 16y ago
Lots of things on the Internet can move quickly but browsers are not Internet software the way that Google or Facebook are. Browsers are still desktop software and things don't move as quickly there thanks to slow PC upgrade cycles and the absolute dominance that software like Windows, Office, and Internet Explorer had a decade ago. Turning that massive ship took longer than many imagined but it is happening. Jamie gave the open source Mozilla project about a year and a half, including the months of pre-source release preparation (and I think that's being generous.) Brendan Eich and Mitchell Baker didn't give up so easily and thirteen-plus years later they're still giving all they've got to make sure that Mozilla continues to be successful in promoting choice, opportunity, and participation on the Web. Some things are worth fighting for and I believe that the Web is one of those things. I'm proud to work with some of the founding members of mozilla.org and think it's a phenomenal thing that such talented people are willing to commit their professional lives to the Mozilla mission when there were and still are far sexier opportunities available to all of them.
- lovamova 16y ago
  When Firefox 1.0 came out, it was one of the lightest browsers available on the market. What happened until version 4.0? Even the latest Firefox beta is one of the slowest browser available. I’m not talking about the JavaScript engine, I’m talking about the user experience of your product.
  - deleted 16y ago
    [deleted]
  - glenjamin 16y ago
    I'd say that in the 10 or so years since firefox 1.0, the average computing power and requirements of the firefox user have shifted enough that the goalposts have moved. Firefox 1.0's USP at a time when browsers were bloated was its lack of bloat. IMO thats less of an issue now.
    - petsos 16y ago
      I'm sorry but this mentality is everything that is wrong with software development. How is bloat not an issue now? We expect that hardware is getting better and better, but it is ok for software to become worse and worse just because it can sort of get away with it? In this case Firefox has even managed to outperform Moore's law. It managed to become slower in a faster rate than computers get faster.
Isofarro 16y ago
Excellent documentary on YouTube covering the year long open-sourcing of Mozilla, right up to the point of jwz leaving Netscape. http://www.youtube.com/watch?v=u404SLJj7ig http://www.youtube.com/watch?v=u404SLJj7ig (via codinghorror: http://www.codinghorror.com/blog/2011/01/lived-fast-died-young-left-a-tired-corpse.html http://www.codinghorror.com/blog/2011/01/lived-fast-died-you... )
- Andrew-Dufresne 16y ago
  Code Rush can downloaded from http://clickmovement.org/content/code-rush-download http://clickmovement.org/content/code-rush-download Other links for unused footage and annotated version: http://en.wikipedia.org/wiki/Code_Rush#External_links http://en.wikipedia.org/wiki/Code_Rush#External_links
- stuhacking 16y ago
  Thanks for linking that, I'd never seen it before and it was very fun to watch. Near the end Jamie says (slightly paraphrasing): "This could all turn into television again... a small number of companies controlling what we see or hear." And now we basically have Facebook, Twitter and Google as the big entry points for finding things on the web. I realise that we're not living in this closed system that's push only.. I just thought there was a slight parallel there.
nickpp 16y ago
"you can divide our industry into two kinds of people: those who want to go work for a company to make it successful, and those who want to go work for a successful company" Awesome insight. Absolutely breathtaking. Explains so much of what happens at larger companies.
DEinspanjer 16y ago
That was a good post and I had forgotten about it over the years. It prompted me to write up some of my own thoughts on the current day Mozilla Community: http://daniele.livejournal.com/80677.html http://daniele.livejournal.com/80677.html

diego 16y ago

I interviewed at Netscape shortly after they announced they would release the browser as open source (June '98, ended up going to Inktomi). I remember being very excited about this, and downloading the source when it first became available. I found out that my (decent) desktop machine was not powerful enough to compile it. When I found a machine that could compile it, it took about 8 hours. No surprise that it remained a Netscape project for so long.

daimyoyo 16y ago
"When I found a machine that could compile it, it took about 8 hours." Thank you. It never occurred to me that you need a lot more processing power to compile code than you do to run the software you're creating. You just saved me a lot of heartache in a few months once it's time to start compiling. I love HN. /srsly
- windsurfer 16y ago
  ...Could you explain? I don't understand what you're saying.
- Simucal 16y ago
  This isn't always the case. It is highly dependent on the language, the compiler used, the size of the code-base and many other factors. Most of the small to medium sized project I have worked on compile in what seems like an instant. However, I work on a medium-to-large code-base at work and it takes around 8 minutes to compile on our build server and around 12-15 minutes on my dev machine. Even these speeds seem tremendously slow to me. I can't imagine being a developer on a huge C++ project and having to wait tremendously long build times. When your compile times aren't near instant it really changes how you program. That feed back loop of code-compile-run-repeat becomes more like code-double check code-code some more-compile-surf the web-run-repeat.
  - rayval 16y ago
    Ideally, you should not be in this situation where you have to compile large amounts of code to go through the code-test-debug cycle. Even in a large project, there should be subysystems that a developer owns and works on that can be partitioned or isolated from the rest, and execute within a test harness on a dev machine -- a harness that feeds the subsystem inputs and records outputs. Successful projects either begin with or evolve to a state where they have the architecture, the toolset, the process and the culture to allow devs to enjoy a fast code/debug cycle.
    - Andrew-Dufresne 16y ago
      Besides subsystems, tools like make and nmake utility can also reduce the compile time. Make figures out automatically which files it needs to update, based on which source files have changed. It also automatically determines the proper order for updating files, in case one non-source file depends on another non-source file. As a result, if you change a few source files and then run Make, it does not need to recompile all of your program. It updates only those non-source files that depend directly or indirectly on the source files that you changed.
      - voxcogitatio 16y ago
        Yes, but large projects often need to use recursive makefiles, which are notoriously flaky at detecting what has changed (if anything).
        drothlis 16y ago
        No project needs to use recursive make. "Recursive make considered harmful": http://miller.emu.id.au/pmiller/books/rmch/ http://miller.emu.id.au/pmiller/books/rmch/
  - alnayyir 16y ago
    ccache. Come on guys, this is basic tooling.
- gaius 16y ago
  It never occurred to me that you need a lot more processing power to compile code than you do to run the software you're creating It never occurred to you because it isn't true! You could for example write a trivial raytracer that compiles in seconds and takes hours to render a scene.
- rmc 16y ago
  Also remember that compiling code can use memory. I once had a compilation causing the machine to swap. That took a while to compile.
- sambeau 16y ago
  This is often the case. My last company had software that took 45 mins to compile on high-end machines in 2010.

thought_alarm 16y ago

5 short years later, mozilla.org shipped a product that was finally ready for prime time.

asadotzler 16y ago
And today that product is used by more than 400 million people around the world -- far more users than Netscape ever had.
- seldo 16y ago
  Specifically, it was Phoenix (aka Firebird, aka Firefox) that made that happen: a version of Mozilla that threw out everything but the browser, including the mail client that jwz considered essential. It made it smaller to download and faster to run, but most importantly it made it faster to write: they could ship improvements to Firefox way faster than they could to Mozilla, simply because there was so much less of it.
  - InclinedPlane 16y ago
    Yup. A classic example of minimum viable product (although for phoenix far more than minimum). Phoenix was a breath of fresh air back then. Mozilla was as bloated and cumbersome as Netscape ever was, but Phoenix was fast, streamlined, and a joy to use. The turning point was when the RSA patent expired and Phoenix could fully support SSL out of the box without any wonky add-ons. At that point there was no longer a good reason not to use Phoenix/Fire{bird,fox} and it started gaining huge amounts of momentum.
    - yuhong 16y ago
      The RSA patent expired back in 2000.
yuhong 16y ago
I think by Mozilla 1.0 it was finally ready, but it was Firefox's marketing that finally led people to adopt it. BTW, you can partly blame this petition: http://archive.webstandards.org/ng.txt http://archive.webstandards.org/ng.txt

asadotzler 16y ago

Lots of things on the Internet can move quickly but browsers are not Internet software the way that Google or Facebook are. Browsers are still desktop software and things don't move as quickly there thanks to slow PC upgrade cycles and the absolute dominance that software like Windows, Office, and Internet Explorer had a decade ago. Turning that massive ship took longer than many imagined but it is happening. Jamie gave the open source Mozilla project about a year and a half, including the months of pre-source release preparation (and I think that's being generous.) Brendan Eich and Mitchell Baker didn't give up so easily and thirteen-plus years later they're still giving all they've got to make sure that Mozilla continues to be successful in promoting choice, opportunity, and participation on the Web. Some things are worth fighting for and I believe that the Web is one of those things. I'm proud to work with some of the founding members of mozilla.org and think it's a phenomenal thing that such talented people are willing to commit their professional lives to the Mozilla mission when there were and still are far sexier opportunities available to all of them.

lovamova 16y ago
When Firefox 1.0 came out, it was one of the lightest browsers available on the market. What happened until version 4.0? Even the latest Firefox beta is one of the slowest browser available. I’m not talking about the JavaScript engine, I’m talking about the user experience of your product.
- deleted 16y ago
  [deleted]
- glenjamin 16y ago
  I'd say that in the 10 or so years since firefox 1.0, the average computing power and requirements of the firefox user have shifted enough that the goalposts have moved. Firefox 1.0's USP at a time when browsers were bloated was its lack of bloat. IMO thats less of an issue now.
  - petsos 16y ago
    I'm sorry but this mentality is everything that is wrong with software development. How is bloat not an issue now? We expect that hardware is getting better and better, but it is ok for software to become worse and worse just because it can sort of get away with it? In this case Firefox has even managed to outperform Moore's law. It managed to become slower in a faster rate than computers get faster.

Isofarro 16y ago

Excellent documentary on YouTube covering the year long open-sourcing of Mozilla, right up to the point of jwz leaving Netscape. http://www.youtube.com/watch?v=u404SLJj7ig http://www.youtube.com/watch?v=u404SLJj7ig (via codinghorror: http://www.codinghorror.com/blog/2011/01/lived-fast-died-young-left-a-tired-corpse.html http://www.codinghorror.com/blog/2011/01/lived-fast-died-you... )

Andrew-Dufresne 16y ago
Code Rush can downloaded from http://clickmovement.org/content/code-rush-download http://clickmovement.org/content/code-rush-download Other links for unused footage and annotated version: http://en.wikipedia.org/wiki/Code_Rush#External_links http://en.wikipedia.org/wiki/Code_Rush#External_links
stuhacking 16y ago
Thanks for linking that, I'd never seen it before and it was very fun to watch. Near the end Jamie says (slightly paraphrasing): "This could all turn into television again... a small number of companies controlling what we see or hear." And now we basically have Facebook, Twitter and Google as the big entry points for finding things on the web. I realise that we're not living in this closed system that's push only.. I just thought there was a slight parallel there.

nickpp 16y ago

"you can divide our industry into two kinds of people: those who want to go work for a company to make it successful, and those who want to go work for a successful company" Awesome insight. Absolutely breathtaking. Explains so much of what happens at larger companies.

DEinspanjer 16y ago

That was a good post and I had forgotten about it over the years. It prompted me to write up some of my own thoughts on the current day Mozilla Community: http://daniele.livejournal.com/80677.html http://daniele.livejournal.com/80677.html