If the OP really means what the community as a whole needs rather than one useful thing for part of that community, then ironically I think you've just nailed it: more than anything else, the community needs a way to match up willing and able contributors with projects that could benefit from their contributions.

To do that, the OP could develop a simple database that understands things like:

• different kinds of contribution ("I want to help with programming")
• technical skills ("I program C++ pretty well, and a bit of Ruby")
• application domains ("I like graphics-related projects")
• levels of difficulty ("this is a million-lines project" => it will take a while to get into and might need significant infrastructure installed to work on it)
• availability ("I can spare an hour or two a week" => probably better to help with small things on smaller, more accessible projects).

Provide some sort of keyword store (extension: recognise related entries/common aliases) or defined scale for each property, let projects say what they need and volunteers say what they're willing to contribute, and help people get matched up.

This has the handy advantage for the OP of being readily scalable from a simple proof of concept with a simple native or web-based UI right up to a full-blown and genuinely useful service if you can find a way of getting it hosted properly. It might help particularly with contribution in areas other than programming, which in practice is often where OSS projects run by volunteers for free start to fall behind commercial projects run by businesses with cross-disciplinary teams.

It's both, though if if there's a simple workaround available, sometimes the stability aspect is actually the more important in terms of being able to build working sites and web apps on the platform.

The real killer is when bugs are introduced, which is why I'm so down on the six-weekly cycle of Chrome and Firefox. They keep breaking stuff that used to work. To be fair, often these things are cosmetic, and while they're mildly irritating, they probably get fixed again six weeks later and no real harm is done. But sometimes the regression isn't just cosmetic, it stops things working at all. And then it isn't Google or Mozilla whose guys get paged at 10pm because my client's customers can't use the web app my clients paid for. (Would you like to guess why we won't include those browsers in our support contracts any more?)

Even IE6 supported a standard-compliant mode that used the W3C box model. Remember where "quirks mode" came from? All you had to do was put a valid doctype on your page.

Moreover, to the extent that it applied since early CSS wasn't as uniform in allowing things like padding and margins to be specified anyway, pretty much all the browsers used to use that traditional model. It wasn't just IE, Netscape did the same. The W3C didn't standardise the way the major browsers worked.

So it's rather unfair to attack IE as if it was somehow either going it alone or defying the existence of then-new standards.

Still, if the traditional box model was such a dumb idea, at least it's dead now. That's why the CSS3 UI module provides a box-sizing property that allows the stylesheet author to switch explicitly to using an old-IE-style model (they called it border-box), which is supported in every major browser of recent years (including IE8+).

Even popular web design bloggers like Jon Hicks and Chris Coyier have promoted the border-box model as a useful tool, and obviously I agree with them. It makes far more sense if you're trying to implement a moderately complex page layout, particularly in the era of responsive/adaptive designs, to have the assigned width of an element reflect the total width it needs including all visible parts.

As far as the box model thing goes, most of the world saw the light at least 3-4 years ago, even if you didn't notice.

As far as rapid release cycles go, we're not there yet, but I think the push-back from people who need to get real work done will start to overtake the new-shiny factor that makes for fun blog posts fairly soon. Lots of people do get the point anyway, but it's becoming more obvious as blog posts promoting new shiny that only works in WebKit or (less often) only works in Gecko are starting to come along, and more and more people are noticing that this is just IE-vs-Netscape all over again, but with more browsers this time.

Standard way to make yourself look foolish on the Internet #735: Make a comment assuming someone with a different point of view to you must somehow be an inexperienced junior guy, and then provide direct evidence that the other guys knows a lot more about the situation than you do.

That simply isn't true. There have been numerous basic rendering bugs in Chrome, many based on CSS2.1 features that have been standard for years. Of course, there have also been quite a few in common CSS3 things like rounded corners and gradients as well, which are hardly experimental any more. And while there have been bugs, still present in the latest release today, in high profile additions like HTML5 media support, there have been some horrible regressions lately in old school areas like integrating with a Java plug-in too.

As I've just pointed out to someone else, this is not a matter of personal opinion or some sort of subjective view based on private data. The bug trackers are public, and you're just as capable as I am of googling any of the above areas with the words "Chrome bug" and finding direct links to those bug trackers that will validate my claims. Whether you chose to do so and improve your knowledge or you prefer to assume you know best and write hostile comments to someone on the Internet you don't even know is up to you -- it's not as if you're going to fool anyone else who does do that into thinking I'm some crazy guy, and obviously your bad assumptions aren't going to convince me that bugs I've got repeatable test cases for don't really exist -- but if you're really a senior web guy perhaps you should consider the more enlightened option.

As the old saying goes, if you can keep your head when all about you are losing theirs, they probably know something you don't. As I said, you might consider the possibility that you have our roles reversed, and that your own lack of real world experience with both debugging Chrome issues and negotiating contracts with major clients is showing.

Here you go

The bug trackers relevant to Chrome are public. You don't need me to post bug reports, you could just google any of the example areas I mentioned and find several different ones for yourself by looking at the first page of results.

It's a shame you didn't do that, but in a way you made my original point for me: far too many people come along every time this topic is raised on most Internet forums and just attack the critics in a knee-jerk reaction, instead of considering whether actually the criticism might be valid and making even the slightest effort to find out.

Once again, you don't seem to be reading what I'm writing before going on the attack.

We will not officially support either Mozilla or Chrome in contracts because they are rapidly moving targets. All browsers have bugs, but when the bugs they have can change every few weeks, it's simply not possible to run a proper testing programme for a major project and give any meaningful guarantee at the end of it that your work will still support Firefox or Chrome after the next update that will be no more than six weeks away. With IE, the time between major releases is long enough to make testing against and then claiming to support certain versions a meaningful concept.

You keep writing things like that, but I haven't talked about money at any point in this conversation, other than in direct reply to points you introduced yourself.

All I'm doing here is supporting TFA, which expresses a view I think should be more widely understood rather than all the nauseating hero worship that tends to go on.

And now the ad hominems based on silly assumptions start. I've been developing web sites since NCSA Mosaic was state of the art. And while font rendering is hardly my "big beef" -- I have plenty of criticisms to make about Chrome's support for CSS and basic rendering, and this is merely one of them -- that poor rendering is a real problem because it means sites that have carefully chosen design features render fine in say IE and Firefox but can become almost illegible in Chrome. Ironically, that's because Chrome sucks at following web standards in certain ways; not recognising fractional letter-spacing is one example we've run into recently.

IE6 had a different box model. When IE6 came out, there was still considerable debate about what the best model would be, and neither Firefox nor Chrome was yet a twinkle in someone's eye.

In any case, IE6 is so old that even Microsoft say everyone should upgrade these days and no longer support it. People who still harp on about how terrible IE is and then start talking about IE6 instead of at least IE8 really need to change the record.

Ironically, IE6 is still a good example of my general point, though. It didn't work the same way as more recent browsers and it had a handful of irritating layout bugs, but because it was a stable target for years, pretty much everyone in the industry knew what those bugs were (or at worst could find out reliably with a few seconds of googling) and how to work around them. It took more effort than would be ideal if everyone followed standards perfectly, but there was no trouble writing sites that would work reliably with IE6 and would continue to do so even today.

My "bitching" mostly seems to be in your head. And whether or not you personally happen to like the situation TFA described doesn't change the underlying facts or make it any less of a valid criticism that could usefully be addressed for the benefit of the entire web dev community.

Sorry, you don't seem to have actually read what I wrote before posting your reply. Here is the relevant part again:

I don't see how that equates to anything like what you wrote.

On with your next point:

And again with the twisting of words. Here to remind you is what I actually wrote:

I put the parts you twisted in bold for you so you can see where you went wrong.

In any case, I fail to see how making decisions based on extensive practical evidence constitutes prejudice. Prejudice would be, for example, saying I was going to advocate a browser that consistently shows up more bugs in basic functionality than all the other major ones instead of IE, just because the more buggy browser is not written by Microsoft.

And there is a difference between having a feature and supporting standards. I think if you're going to claim to support a standard, the feature should actually work. Chrome has had, and in many cases continues to have, obvious and fully reported bugs in CSS rendering. These include popular CSS3 effects like gradients and rounded corners not drawing properly under various conditions. They also include basic CSS 2.1 text styling problems like the infamous letter-spacing limitations, because Chrome still relies on its own very poor text rendering rather than using the far superior tools built into various host operating systems. It's not as if these kinds of issues are big secrets; some have been in the bug tracker for years with numerous people echoing the problem.

I was posting in support of TFA, not trying to make an independent case of my own.

However, I have made my own case based on my own evidence on several previous occasions on this forum and elsewhere. Unfortunately, even if you cite a bunch of specific issues, the response is rarely any better than your own: someone in denial of the situation who thinks anyone criticising their beloved browser must be trolling and can't possibly have actually experienced numerous documented and repeatable bugs, even though the bug tracker is a matter of public record and mere seconds searching it would confirm the kinds of bugs people are citing.

Sorry, but I'm a professional, and as such I do the job my clients hired me for. If Google would like to hire me to help test their code, I'll be happy to quote them a suitable fee like anyone else. But right now, my real, paying clients typically hire me to produce web apps that work for contractually specified targets, not to provide subsidised debugging for someone else's product.

Today, those specified targets are usually something like IE8, IE9 and IE10, because with the deliberate policy by both Google and Mozilla to avoid stable versions and push updates every few weeks, it's difficult to specify support for Chrome or Firefox in any useful way in a contract even if you do want to. Without a stable platform to test against, there is no way to write acceptance criteria that are going to be relevant for more than one release cycle of those browsers, which for many projects isn't even time to run through the QA/release process fully.

Of course there is: porting a vast suite of software to an entirely new OS is going to cost a fortune. No-one I've seen has yet made a convincing case for why anyone would spend serious money to buy an office suite on a touch-only tablet or smartphone, never mind enough people doing it to actually make the port profitable.

OK, but none of them produces the kind of data you create in Office-like applications. I don't see what any of them has to do with the topic at hand. To reiterate my original point, I'm not saying tablets and smartphones don't have their uses, just that they are useful for content consumption (like the book reading example you mentioned) but not very suitable for content creation (which is what Office applications are primarily used for).

Sorry, but I'm not sure what your comment has to do with mine. Did you reply to the wrong post?

In my experience, it typically takes 6-12 months for a professional software engineer joining a new large project to find their way around the codebase. And that's assuming they're doing it at work, probably with a mentor assigned to help them find their way and with other people within walking distance to ask for help on the tricky parts.

It simply isn't reasonable to expect people to understand the code base, or even the internal architecture, of a vast project like a modern web browser just in order to get problems fixed.

(Yes, this is horribly unfair on the guys developing the browser, who get a bazillion vague reports of half-broken maybe-bugs. It sucks for them. But I'm not the one claiming normal people should switch to my browser instead of other competing ones, they are. And if they do want better bug reports from normal people, they need a vastly better bug reporting system than any major browser offers today to help normal people report their problems.)

Almost everyone used to agree that the world was flat. We know better now.

HTML, CSS and JavaScript can now do many of the basic jobs that used to make the popular frameworks and plug-ins useful, as standard. If you need to support older browsers that don't include the necessary functionality as standard, you can use a polyfill approach to get exactly what you need with minimal overheads.

I wouldn't necessarily go as far as the original AC who codes everything by hand, as I have no problem with using a library or toolkit if it really does add value, but the underlying point is still valid: pulling in heavyweight add-ons like jQuery by default is unnecessary today.

I don't want to get into a flame war, but if you really think you still need to use a framework just to find DOM elements easily, you're several years behind the curve. Such functionality is available using simple JS in every major browser as far back as IE8. I think this was the original AC's point, and you missed it.

Speaking as another professional web guy who's extremely frustrated with the current situation for very much the reasons in TFA, I find comments like Kasting's frustrating. Yes, there are bug reports. Yes, they have been there for a while, many years in some cases. Yes, the bugs are sometimes in really basic, everyday functionality. Yes, Chrome is by far the worst major browser for reliability based on the objective bug tracking metrics across all the projects I work on. Yes, it has been so consistently for a long time. And yes, there are comments on quite a few of those bug reports making it clear that even glaring problems aren't going to get fixed any time soon despite the developers being well aware of them. In my experience, absolutely everything Methvin said is true, and actually he's being rather kind.

Unfortunately, on most forums, if you suggest that this is the reality, even backing it up with citations of numerous bugs in basic functionality and even citing specific records in the relevant bug databases that go back years, it's a good bet that you'll be downvoted/moderated into oblivion, or just face the kind of "What, really?" reply Kasting posted as if it's hard to believe the almighty Chrome could actually be as bad as it is. This is the stereotype geek/OSS fanboi issue, where no amount of facts and actual evidence matter in most discussions.

I've given up even trying to file bugs for everything I find now. I'm sorry, I know it's not constructive, but my clients don't pay me to be someone else's beta tester, and since Chrome is often beta quality software I really would be spending a significant amount of my working hours just doing that.

Instead, these days we just say that we write to established web standards where possible but the only browsers we'll support officially are recent versions of IE. While these don't have all the bleeding edge shiny, the basic functionality does generally work very reliably, and actually IE9+ have a lot of the more useful recent developments anyway. Just as important, the relatively few serious bugs in the more recent versions of IE tend to be well-known, and the necessary workarounds are well-established and stable because the goalposts don't move every six weeks. That's worth far more to someone developing real software for real clients than scoring X% in some artificial benchmark for supporting standards that don't exist yet, where X% is the box-ticking score but not the number of features that actually work.

Office-type applications will never be a good fit for tablets and smartphones. The applications are primarily used for content creation. The devices are primarily useful for content consumption, and suck at content creation in almost every conceivable way, starting with having tiny screens and having no fast, accurate way to input data.

An ironic comment, given that this ruling was made by the European Court of Human Rights, which is not a part of the EU machinery (and in fact applies in far more countries and has been around for far longer).

Of course they are.

For one thing, when people ask an architect to design a new home for their family, it's perfectly normal to call him back six months later in the middle of first fit and say that actually what they need is a skyscraper. With a secret underground lair. And access to open water, so unfortunately the urban site where half of it currently sits is no good and the whole thing will need to be relocated to the nearest coast. And the building regs have suddenly changed, so now instead of concrete and rebars, the whole thing has to be made of environmentally friendly engineered wood materials.

Moreover, just like houses, we have thousands of years of experience building software now. We've become pretty good at telling in advance which techniques will be needed, what order the different components will need to be built in, and especially estimating how long it's going to take and what it will cost.

Actually, maybe it is a slightly unfair comparison, because the amateurs who build physical structures, like that mile-long railway tunnel that was drilled from both ends and wound up out of position by absurd amounts like 4mm when they met in the middle, can't really keep up with software development professionals who can build precisely specified interfaces and get everything to fit together exactly on the first attempt.

That's mostly because the tools and processes for doing all of this in the software world are well understood throughout the industry, which in turn is because everyone practising software development has gone through rigorous training taught by people who are themselves experts with years of practical experience to draw upon. Engineers and architects try to do the same thing, but they just haven't quite nailed it yet. I guess software guys have an advantage here because those tools and processes are universal and uncontroversial, so everyone in software does things the same way and software project managers don't really need to co-ordinate their team to quite the same extent that, say, a lead contractor would when building a house.

But apart from that slight advantage because software development is so much better understood, I think it's perfectly reasonable to compare building a house to building software and expect things to work the same way. There's really no qualitative difference at all, and basically the same processes work just as well for both tasks.