5 ms·

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.

by pekk 12y ago

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.
      - azakai 12y ago
        Of course I agree that the chromium project itself, as opposed to the chromium browser, is developed openly and in a nice way. There is no argument between us on that - it's a clear fact. And I agree that in a large project like a browser, compromises can be necessary when you must work with partners, as in the examples that you made. Good points. But I strongly disagree on two things you mention: Regarding asm.js, that is not how it was developed. It was from day 1 done on an open github repo, https://github.com/dherman/asm.js/ https://github.com/dherman/asm.js/ There was never anything secret about it. (What would we have even gained by being secretive about it? Nothing.) Also, in v8 the issue is not just CrankShaft and TurboFan, but as I mentioned, daily development. I file bugs when I find v8 failing on an emscripten output, and so I follow v8 commits. There is almost no public discussion on them - just patches, plus perhaps a review comment or two. No public bug with background, explanations, motivation, etc. The code is open, but development is clearly not. I think it's obvious v8 is a major part of chromium, and it's completely unnecessarily developed in a non-open manner. So I think it's fair to say the chromium browser as a whole - as opposed to the chromium project itself - is not developed fully openly. Another example is Dart. Dart is not yet part of chromium, but the plans to integrate it are public. Dart was developed secretly for a while, and in fact only became known unintentionally in a leaked email. It's not clear when it would have become public if not for that leaked email. Again, like with v8, this is unnecessarily closed development - there are no legal issues or partners that must be compromised with. It was just decided that v8 and Dart would be developed non-openly (for reasons I can't understand).
- 72deluxe 12y ago
  Has that happened to you? I noticed a new fancy Bookmark management system in Chromium and then it suddenly disappeared again.
  - amelius 12y ago
    Well, offtopic, but imho bookmarks need serious work in Chromium. I'm constantly looking for my bookmarks, and not finding them. Perhaps a search+time filter could help here. Also, when clicking on "Other bookmarks", I currently get a dropdown of about a thousand elements :) I hope a UX person can have a good look at this sometime.
    - 72deluxe 12y ago
      Yes, the bookmarks need some attention. The new UX I saw for bookmarks presented them as a grid of large colourful squares but I wasn't sure that was easier to read or use than a list. Hopefully someone will come up with something (that will no doubt be hated by many). I always thought the system for displaying the bookmarks bar was a bit daft because you could only see about 10 bookmarks before running out of horizontal room. On OSX at least we have a dedicated "Bookmarks" menu but using it under Linux and Windows was always painful due to this strange (IMHO) design.
      - amelius 12y ago
        Personally, I just want a way to sort bookmarks by date, a grep-like search of titles, and a similar grep-like search of the page contents. And then perhaps a more intelligent search.
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/

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.

by 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.
    - azakai 12y ago
      Of course I agree that the chromium project itself, as opposed to the chromium browser, is developed openly and in a nice way. There is no argument between us on that - it's a clear fact. And I agree that in a large project like a browser, compromises can be necessary when you must work with partners, as in the examples that you made. Good points. But I strongly disagree on two things you mention: Regarding asm.js, that is not how it was developed. It was from day 1 done on an open github repo, https://github.com/dherman/asm.js/ https://github.com/dherman/asm.js/ There was never anything secret about it. (What would we have even gained by being secretive about it? Nothing.) Also, in v8 the issue is not just CrankShaft and TurboFan, but as I mentioned, daily development. I file bugs when I find v8 failing on an emscripten output, and so I follow v8 commits. There is almost no public discussion on them - just patches, plus perhaps a review comment or two. No public bug with background, explanations, motivation, etc. The code is open, but development is clearly not. I think it's obvious v8 is a major part of chromium, and it's completely unnecessarily developed in a non-open manner. So I think it's fair to say the chromium browser as a whole - as opposed to the chromium project itself - is not developed fully openly. Another example is Dart. Dart is not yet part of chromium, but the plans to integrate it are public. Dart was developed secretly for a while, and in fact only became known unintentionally in a leaked email. It's not clear when it would have become public if not for that leaked email. Again, like with v8, this is unnecessarily closed development - there are no legal issues or partners that must be compromised with. It was just decided that v8 and Dart would be developed non-openly (for reasons I can't understand).
72deluxe 12y ago
Has that happened to you? I noticed a new fancy Bookmark management system in Chromium and then it suddenly disappeared again.
- amelius 12y ago
  Well, offtopic, but imho bookmarks need serious work in Chromium. I'm constantly looking for my bookmarks, and not finding them. Perhaps a search+time filter could help here. Also, when clicking on "Other bookmarks", I currently get a dropdown of about a thousand elements :) I hope a UX person can have a good look at this sometime.
  - 72deluxe 12y ago
    Yes, the bookmarks need some attention. The new UX I saw for bookmarks presented them as a grid of large colourful squares but I wasn't sure that was easier to read or use than a list. Hopefully someone will come up with something (that will no doubt be hated by many). I always thought the system for displaying the bookmarks bar was a bit daft because you could only see about 10 bookmarks before running out of horizontal room. On OSX at least we have a dedicated "Bookmarks" menu but using it under Linux and Windows was always painful due to this strange (IMHO) design.
    - amelius 12y ago
      Personally, I just want a way to sort bookmarks by date, a grep-like search of titles, and a similar grep-like search of the page contents. And then perhaps a more intelligent search.

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/