6 ms·

Since no one realizes that Mozilla actually develops stuff in the open (vs. code/project-dumps like Google after its 'done'), here's the Mozilla project page fo

by windlep 12y ago

Since no one realizes that Mozilla actually develops stuff in the open (vs. code/project-dumps like Google after its 'done'), here's the Mozilla project page for Hello (previously called Loop): https://wiki.mozilla.org/Loop https://wiki.mozilla.org/Loop A bunch of the hypothetical questions here on HN could be answered easily by skimming over this page and some of the pages linked in. Edit: I'm not suggesting its bad or good to get a project to a more polished state before open-sourcing it, mainly just pointing out that for good/bad, Mozilla does happen to keep the entirety of the process very open.

pekk 12y ago
I don't have any problem with people making open source projects and then publishing them once they are finished. It's still open source.
- siddboots 12y ago
  It is open source, but there are different models of project development. In particular, there is a lot of nuance in your term "once they are finished". If a company periodically dumps a large project tree online but continues the development and management behind closed doors, it makes it very difficult anyone else to make use of or build upon the source without forking it completely (and forking has its own risks). This is why windlep is pointing out that Mozilla "develops in the open", as opposed to being merely open source.
  - click170 12y ago
    Nitpick: I don't think there's anything wrong with a closed development model and open sourcing the result, but IMO it's not open source until the code is available. If you're starting a project with this intention, I don't think it's really Open Source until your first code dump is publicly accessible - at which point, go nuts with branding it Open Source. I also don't think it's unfair to do code dumps, if the code is available then job done. Other projects provide additional hand holding, but in my opinion that's a feature that the original authors have the freedom to choose to not implement. I'm really pleased that Mozilla have chosen an open development model.
- gcb0 12y ago
  If you had contributed to chromium for weeks, and then google come with it's monthly dump and overwritten everything you and others did in the open, you would have a different opinion.
  - justinschuh 12y ago
    Sorry, but what the FUD is this? Chromium has never done anything of the sort. It's developed completely in the open and has a huge number of non-Google contributors committing code every day.
    - azakai 12y ago
      Chromium proper is indeed developed in the open, but the Chromium browser as a whole is not, perhaps that's what was intended above, so there might be a confusion of terminology here. For example, v8 - a very important part of Chromium - is not developed fully openly: major features are developed secretly and land as surprises, like CrankShaft and TurboFan, and also daily development consists of patches landing with little or no public discussion behind them.
      - justinschuh 12y ago
        Fair enough that v8 is an odd case, but it's an external dependency that predates Chrome/Chromium with its own core team, development processes, third-party obligations, and ecosystem. And accepting that, v8 does have third-party contributors (see their policy here: https://code.google.com/p/v8-wiki/wiki/Contributing https://code.google.com/p/v8-wiki/wiki/Contributing). Plus, do you really take issue with the occasional quietly developed code drop, because isn't that pretty much how your team introduced asm.js support in Firefox? Beyond JS engines, you must appreciate that dependencies and business relationships can get very odd when shipping something as big and complicated as a browser. Chrome/Chromium absolutely experiences this, but so does Mozilla. Take HTML EME, where Adobe's technical requirements have pretty much forced Mozilla to break Andreas' and Brendan's original promises on how much the closed-source CDM will be sandboxed. Then there's the h.264 situation, which is an odd multi-step dance to deliver binaries from Cisco, and is significantly more convoluted than Chrome's use of ffmpeg. Regardless, I don't believe you're really trying to make the argument that Chromium is not a publicly developed open source project with a huge pool of non-Google contributors. Because you know that to simply be an indisputable fact, even if there is additional complexity around certain dependencies and platforms.
- nly 12y ago
  There are several problems with the code and dump scenario: * Open source contributors have to approach the codebase from a much more advanced, and often more burdened or rigid, state * The mainline developers, who worked on the code before release, aren't necessarily used to, or open to, accepting contributions as if the project had been developed in the open from a much more primitive state. * Sometimes the dump literally just means "here's the code", and isn't an indication that the project is looking for significant or lasting contributions at all. * Sometimes when companies open source their stuff what they're really doing is putting it out to pasture... but this isn't always apparent upon release. * Often the project isn't hosted on a neutral platform, like Github or the company still works on v2 in a private fork.
- jamiesonbecker 12y ago
  Open source is better than not, but there's some great insights in Eric Raymon's paper The Cathedral and the Bazaar[0] with regards to how release early, release often is better for the author, community, and (open source) project both in the near and long term. Releasing it, bugs and all, early on can build a real community in ways that dumping a finished project can never do. For example, look at projects like the original Netscape/Mozilla or Libreoffice open source projects and how long they took to build communities (with the former, they really didn't exist with non-AOL communities until AFTER a complete rewrite - Firefox - was launched; same was true with StarOffice/OpenOffice/Libreoffice). Then look at the similarly sized projects of Linux distributions, KDE, GNOME, and many others. Being able to get involved with a project early on, before it's too big to really jump into quickly and make a meaningful contribution, really helps build that initial core of developers who believe in and want/need the project. 1. http://www.catb.org/esr/writings/cathedral-bazaar/ http://www.catb.org/esr/writings/cathedral-bazaar/
tkubacki 12y ago
AFAIK Chromium and Dart are developed in the open now. despite your edit - I'm felling you are suggestiong it's worse model.
- bengoodger 12y ago
  Furthermore, Chromium's now spent the vast majority of its life developed in the open. You would probably find today's code unrecognizable if you traveled through time from 2008.
- reubenmorais 12y ago
  It's definitely a more difficult model. Open source projects tend to attract very opinionated people, and a project's infancy is when it's most fragile. Usually the objections come from the outside, but at Mozilla the critics are the core volunteers who (publicly) question weather project decisions are aligned with the manifesto [0] all the time. It's also seen as inappropriate when someone tries to develop something in private and then release it expecting it to be shielded from criticism because it's more polished than a prototype. All of this means you can't get away with shady stuff, or cool stuff that doesn't align with the project. But products need to evolve to stay competitive, and the downside is that the added friction from having to respond to people who are not in the payroll about what to develop and what to release means Firefox doesn't have the capacity to move as fast as Chrome does, for example. [0] https://www.mozilla.org/about/manifesto/ https://www.mozilla.org/about/manifesto/

by windlep 12y ago

pekk 12y ago

I don't have any problem with people making open source projects and then publishing them once they are finished. It's still open source.

siddboots 12y ago
It is open source, but there are different models of project development. In particular, there is a lot of nuance in your term "once they are finished". If a company periodically dumps a large project tree online but continues the development and management behind closed doors, it makes it very difficult anyone else to make use of or build upon the source without forking it completely (and forking has its own risks). This is why windlep is pointing out that Mozilla "develops in the open", as opposed to being merely open source.
- click170 12y ago
  Nitpick: I don't think there's anything wrong with a closed development model and open sourcing the result, but IMO it's not open source until the code is available. If you're starting a project with this intention, I don't think it's really Open Source until your first code dump is publicly accessible - at which point, go nuts with branding it Open Source. I also don't think it's unfair to do code dumps, if the code is available then job done. Other projects provide additional hand holding, but in my opinion that's a feature that the original authors have the freedom to choose to not implement. I'm really pleased that Mozilla have chosen an open development model.
gcb0 12y ago
If you had contributed to chromium for weeks, and then google come with it's monthly dump and overwritten everything you and others did in the open, you would have a different opinion.
- justinschuh 12y ago
  Sorry, but what the FUD is this? Chromium has never done anything of the sort. It's developed completely in the open and has a huge number of non-Google contributors committing code every day.
  - azakai 12y ago
    Chromium proper is indeed developed in the open, but the Chromium browser as a whole is not, perhaps that's what was intended above, so there might be a confusion of terminology here. For example, v8 - a very important part of Chromium - is not developed fully openly: major features are developed secretly and land as surprises, like CrankShaft and TurboFan, and also daily development consists of patches landing with little or no public discussion behind them.
    - justinschuh 12y ago
      Fair enough that v8 is an odd case, but it's an external dependency that predates Chrome/Chromium with its own core team, development processes, third-party obligations, and ecosystem. And accepting that, v8 does have third-party contributors (see their policy here: https://code.google.com/p/v8-wiki/wiki/Contributing https://code.google.com/p/v8-wiki/wiki/Contributing). Plus, do you really take issue with the occasional quietly developed code drop, because isn't that pretty much how your team introduced asm.js support in Firefox? Beyond JS engines, you must appreciate that dependencies and business relationships can get very odd when shipping something as big and complicated as a browser. Chrome/Chromium absolutely experiences this, but so does Mozilla. Take HTML EME, where Adobe's technical requirements have pretty much forced Mozilla to break Andreas' and Brendan's original promises on how much the closed-source CDM will be sandboxed. Then there's the h.264 situation, which is an odd multi-step dance to deliver binaries from Cisco, and is significantly more convoluted than Chrome's use of ffmpeg. Regardless, I don't believe you're really trying to make the argument that Chromium is not a publicly developed open source project with a huge pool of non-Google contributors. Because you know that to simply be an indisputable fact, even if there is additional complexity around certain dependencies and platforms.
nly 12y ago
There are several problems with the code and dump scenario: * Open source contributors have to approach the codebase from a much more advanced, and often more burdened or rigid, state * The mainline developers, who worked on the code before release, aren't necessarily used to, or open to, accepting contributions as if the project had been developed in the open from a much more primitive state. * Sometimes the dump literally just means "here's the code", and isn't an indication that the project is looking for significant or lasting contributions at all. * Sometimes when companies open source their stuff what they're really doing is putting it out to pasture... but this isn't always apparent upon release. * Often the project isn't hosted on a neutral platform, like Github or the company still works on v2 in a private fork.
jamiesonbecker 12y ago
Open source is better than not, but there's some great insights in Eric Raymon's paper The Cathedral and the Bazaar[0] with regards to how release early, release often is better for the author, community, and (open source) project both in the near and long term. Releasing it, bugs and all, early on can build a real community in ways that dumping a finished project can never do. For example, look at projects like the original Netscape/Mozilla or Libreoffice open source projects and how long they took to build communities (with the former, they really didn't exist with non-AOL communities until AFTER a complete rewrite - Firefox - was launched; same was true with StarOffice/OpenOffice/Libreoffice). Then look at the similarly sized projects of Linux distributions, KDE, GNOME, and many others. Being able to get involved with a project early on, before it's too big to really jump into quickly and make a meaningful contribution, really helps build that initial core of developers who believe in and want/need the project. 1. http://www.catb.org/esr/writings/cathedral-bazaar/ http://www.catb.org/esr/writings/cathedral-bazaar/

tkubacki 12y ago

AFAIK Chromium and Dart are developed in the open now. despite your edit - I'm felling you are suggestiong it's worse model.

bengoodger 12y ago
Furthermore, Chromium's now spent the vast majority of its life developed in the open. You would probably find today's code unrecognizable if you traveled through time from 2008.
reubenmorais 12y ago
It's definitely a more difficult model. Open source projects tend to attract very opinionated people, and a project's infancy is when it's most fragile. Usually the objections come from the outside, but at Mozilla the critics are the core volunteers who (publicly) question weather project decisions are aligned with the manifesto [0] all the time. It's also seen as inappropriate when someone tries to develop something in private and then release it expecting it to be shielded from criticism because it's more polished than a prototype. All of this means you can't get away with shady stuff, or cool stuff that doesn't align with the project. But products need to evolve to stay competitive, and the downside is that the added friction from having to respond to people who are not in the payroll about what to develop and what to release means Firefox doesn't have the capacity to move as fast as Chrome does, for example. [0] https://www.mozilla.org/about/manifesto/ https://www.mozilla.org/about/manifesto/