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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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). 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.
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,
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).
Do you really think a code drop from an obscurely named github repo qualifies as open development? Because it can just as easily be interpreted as hiding in the noise, particularly when the eventual asm.js unveiling was done as a giant PR blitz. Of course, you can argue that the secrecy was unintentional, but you can't really argue that it wasn't taken advantage of.
To your argument that Chromium is not developed fully openly, you must understand that Blink and Chromium contributors dwarf the v8 team by orders of magnitude, right (even the security team is a bigger)? And you understand that the difference in code size is even larger, right? I get that you're focused on JS because it's your area, but in the grand scheme it's only one of many, many important pieces. And if we're going to dig into it like this, do you really believe every part of Firefox would hold up to the same level of scrutiny? after all, Richard Stallman has made similar arguments about Firefox not being truly free.
Now for Dart. I just don't see Chromium approaching Dart the same way Mozilla approached asm.js. On the contrary, I strongly expect that dart.js will need to prove the viability and popularity of the language before Chromium includes any specific optimizations or support for it. As for the "leaks," I suggest you read the doc people are referencing and consider the timelines involved. Because, the content paints a very different picture, and the timelines don't at all align with what you're claiming.
As for why the Dart team follows their particular development practice, I don't know. They spun out of the original v8 team and aren't a part of Chrome team. However, I do know both Dart and v8 have some non-negligible testing and workflows tied to Google infrastructure. So, it may just be hard for them to switch, or maybe no one has ever made the case to do so. Honestly, have you tried just asking nicely rather than making accusations? I mean, you say you can't understand it, but your behavior seems to assume and voice the worst motivations for anything related to Google.
Well, asm.js was a research project for a few months. During those, it was open on github, it was discussed openly on IRC (e.g. #emscripten, for example when experimental commits came in to emit asm.js-like stuff), etc. During that time, we didn't know if it would work or just be a waste of time. So no blogposts were written, because what would we write? Most research projects fail, and are not worth making an effort to mention. One just develops them in the open and sees how things go.
What are you saying we should have done differently during the early research period of asm.js? (Honest question, this situation happens all the time with new research projects - I'd love to do better next time.)
And how exactly was the non-prominence "taken advantage of"? What benefit did we get from it?
I completely agree with you about chromium (the project) being open, and yes, clearly it is far larger than v8. Also, very likely I consider v8 to be more important than the average person, since JS is my area, that is a fair point.
Still, I don't want to go all the way to saying something like "v8 is negligible". It's not. JS is the only standardized programming language available for web pages. The JS writing community is huge. People writing websites use HTML, JS and CSS, with JS being pivotal. So JS does matter quite a lot, even if v8's size is small in comparison to the rest of chromium.
Hence, v8 not being developed openly is a black mark against the openness of the chromium browser. That seems an unavoidable conclusion. But it is open to debate on the amount - is v8 more or less important - of course.
I'm not sure what you think I'm claiming about Dart, if you think the timeline in the Dart document doesn't align with anything I said?
I apologize if it seems like I'm assuming the worst about Google's motivations regarding anything. I think I was pretty careful in not talking about motivations, because I don't know them. The facts are that v8 development is not fully open. And, it is a fact that I don't understand that. Not sure how that shows I think Google is being evil or anything like that? Not is anything I said an "accusation" about Google's motivations, as again, I tried to focus on the observable facts. (Or, did you make that statement referring to something else I said - if so, what?)
I have talked to v8 people, and I have asked questions about openness and development procedures and so forth. I also file bugs regularly and interact with them on the tracker. I admire the v8 developers - they are doing an amazing job! So I'm not someone from afar that is assuming the worst. I'm someone that likes the v8 project, tries to help out, and interacts with it, while at the same time is kind of puzzled and disappointed that it isn't developed openly. And I feel that reflects poorly on chromium. That's all.
go find all the 3 (last time i counted) ways to enable "disable referrer header" that was present in the community version for months and removed by google in their 'big code blob release'
Your response is utter nonsense. If you had any legitimate argument to make here you'd be citing something to support these wild accusations, but you have nothing of the sort.
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.
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.
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.
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.
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.