Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?
Mozilla Programming

Mozilla Tries New "Lorentz" Dev Model 126

With the recent release of Firefox 3.6, Mozilla has also decided to try out a new development model dubbed "Lorentz." A blend of both Agile and more traditional "waterfall" development models, the new methodology aims to deliver new features much more quickly while still maintaining backwards compatibility, security, and overall quality. Only time will tell if this is effective, or just another management fad. "If the new approach sounds familiar, that's because Unix and Linux development has attempted similar kinds of release variations for iterating new features while maintaining backwards compatibility. HP-UX, for example, is currently on its HP-UX 11iv3 release, which receives updates several times a year that add incremental new functionality. The Linux 2.6.x kernel gets new releases approximately every three months, which include new features as well."
This discussion has been archived. No new comments can be posted.

Mozilla Tries New "Lorentz" Dev Model

Comments Filter:
  • Development cycles (Score:5, Insightful)

    by girlintraining ( 1395911 ) on Monday January 25, 2010 @02:08PM (#30893208)

    the new methodology aims to deliver new features much more quickly while still maintaining backwards compatibility, security, and overall quality.

    A style of management is only as good as its manager(s). We've had many, many methods of improving all three of those but as an industry we routinely and repeatedly turn it down for most applications over cost considerations. A new hybrid model of development won't change this -- continual pressure from inside the organization will eventually subvert any gains at the process level. Senior level management has to push this from the start -- only then would this or any other kind of methodology have a chance at achieving its goals.

  • by Hurricane78 ( 562437 ) <deleted AT slashdot DOT org> on Monday January 25, 2010 @02:25PM (#30893466)

    The waterfall model is horrible for big projects. I thought everybody knew that and had switched to the spiral model a loong time ago.
    And now they add the only thing to it, that in even more horrible? Agile?? Or in other words: Spaghetti coding with the motto: “If perfect planning is impossible, maybe not planning at all will work.”
    No, dammit! It’s just as bad.
    Maybe that’s why they try to mix them both... To get to the actually healthy middle ground.

    But still, it’s silly. We have a perfectly good spiral model. Hell, the whole game industry uses it. (As far as I know.) And it works great, even on those huge 5-year projects. (Notable exception that proves the rule: Duke Nukem Forever.)

    Sorry, but that will result in a huge epic failure, and probably Firefox’s death.
    Mark my words. :/

  • Re:No (Score:5, Insightful)

    by Magic5Ball ( 188725 ) on Monday January 25, 2010 @02:28PM (#30893520)

    Mozilla have fallen into the classic trap of trying to expand its user base via increasing features, as opposed to keeping its user base by increasing quality.

    We don't need new features directly in Firefox. Plugins do that. Remember that long ago the project made a conscious choice to take a performance hit to provide third-party access into the browser via the elaborate XUL and plugins frameworks, to minimize pushing code and features onto users who don't need them.

  • Re:No (Score:2, Insightful)

    by Anonymous Coward on Monday January 25, 2010 @02:31PM (#30893568)

    Why does the Linux community have so much trouble with it, while nobody else does?

    FreeBSD, for instance, manages to have several major-number releases in use at any given time. FreeBSD 9.x is in development. FreeBSD 8.x is the recommended production release. But even FreeBSD 7.x is still supported. Not only that, FreeBSD manages to get out several point releases each year, in addition to a major release. But it has none of the problems you mention.

    Maybe it's a maturity thing. The FreeBSD development community is made of very talented and very experienced developers who know that you shouldn't just throw patches and features around willy-nilly. The FreeBSD user community is also more mature, willing to wait a short while for a feature to become available through the natural release cycle.

  • Re:No (Score:2, Insightful)

    by Magic5Ball ( 188725 ) on Monday January 25, 2010 @02:44PM (#30893730)

    The elegant solution to too much choice among plugins isn't to revamp the software development workflow, nor is it to load every conceivable feature into the default interface. (Assuming that the opposite were true, Firefox would ship with all 10,000 plugins loaded, which it does not.)

    Since Firefox is starting to resemble an operating system anyway, it might be time for Firefox distributions, which default to a core consisting of functions expected of every browser, along with the small number of exceptional features/plugins/whatever which differentiate Firefox from everything else in a good way. (That would also give users tangible reasons to choose and stick with Firefox.) Otherwise, more features for the sake of more features leads to office productivity suites in which most users must download, install and load but will never use 95% of the available features.

  • Re:No (Score:5, Insightful)

    by diegocg ( 1680514 ) on Monday January 25, 2010 @02:49PM (#30893796)

    It's not the waiting what sucks. What sucks is that the old development model was more unstable. For big projects linux with a lot of activity, long development cycles just don't work. You don't have releases, so users don't test it. Once you get out the first stable release, users notice that it's very buggy (but you still don't know all the bugs, because most users and distros are still not using it because it has too many bugs), and it takes a full year to get the codebase into a decent shape. That's what happened with Linux 2.6. They had been dropping thousands of LoC for a couple of years. Because it's a "unstable cycle", quality was not so important, the main tree was used as a repository for "work in progress" code, and even if it was important (which it isn't, even it there's a corporate policy that says that it must be) you can't measure the quality of the code, because the users are not using it.

    The new model, in the other hand, allows new feaures in every release, but it's much easier to track regressions compared to the previous model. The new features are required to have some quality, they can't have serious bugs, maintainers must agree that they can be merged, and they only can be merged in the first two weeks of the 3 months development period. It allows to make progress faster, and at the same time bugginess is controlled more easily. Previously, you had a huge diff of several MB, users reporting that the huge diff was causing several bugs and regressions in their systems, and developers had to start debugging the alpha code they had written, and had not tested, two years ago. IMO, long term, it's much better for everybody. It's not surprising that FreeBSD and Solaris are using this model too, it makes sense for Mozilla to use it aswell.

  • by roman_mir ( 125474 ) on Monday January 25, 2010 @03:45PM (#30894534) Homepage Journal

    You know that it is silly, that every time a new version of FF comes out, every add-on author has to up the version on his code and resubmit to amo? Most of the changes from version to version of FF does not affect most addons at all and yet there is this whole thing with addons having to be resubmitted, wait in the queue for weeks and at the end the only change in the new version is the maxVersion tag in the installation rdf.

    On the other hand there is now talk of completely changing the system of interfaces between addons and the browser. Who has time and interest to rewrite the same thing over and over again?

  • by BitZtream ( 692029 ) on Monday January 25, 2010 @04:07PM (#30894862)

    First sign a developer is shitty ...

    He/She starts talking about 'which development model is better' and starts naming them.

    Its the developer with the issue in your case, not the model.

  • by Doomdark ( 136619 ) on Monday January 25, 2010 @04:56PM (#30895586) Homepage Journal
    And now they add the only thing to it, that in even more horrible? Agile?? Or in other words: Spaghetti coding with the motto: “If perfect planning is impossible, maybe not planning at all will work.”

    This is not meant as a flame, but I don't think you have a clue as to what Agile here means. Possibly because term has been abused a lot by people who just want to get rid of all processes -- nonetheless, agile does not mean "no process". Just a light-weight common-sense process that most mature developers would follow anyway.

    It is also true that agile methodology is a meta thing ("abstract methodology"). So it is bit silly to argue about it, as opposed to concrete implementation thereof like Scrum. But I assume you were referring to class of methodologies, all of which allegedly would be just excuses of not thinking through anything. And that is a false statement.

  • by luserSPAZ ( 104081 ) on Tuesday January 26, 2010 @08:02AM (#30902444) Homepage []

    Firefox codenames are always park names nowadays. This park happens to be in Indonesia, which (AFAIK) is the first country to pass 50% Firefox marketshare.

Machines that have broken down will work perfectly when the repairman arrives.