Hacker News Reader

Please provide a criticism of open source software which you can't answer with "If you don't like it, fix it."[1] I wager you can't. If that's true, you're basically claiming that open source projects are immune to criticism[2].

[1] It's really, "If you don't like it, learn programming, then download the source code, then learn to build it, then learn to read it, then make your change, then build it, then use it, then champion getting it merged."

[2] Complaint, whine, we can call it whatever you want. I'm a grown man secure in my whining.

---

Do you really go hack on random large codebases at a moment's notice when something about them irks you? If so, please know that nobody else on the planet can do this without spending weeks of time (conservatively). It's utterly disingenuous to so ignore the fixed costs inherent in programming.

---

Is this the same firefox that can afford to advertise in the NYTimes? How much of its development is really on a volunteer basis anymore? Let's decide once and for all whether this is a mature codebase that's encouraging us to use it for mission-critical work in the world. If it is, it's open to criticism (yes, even trivial criticism).

Not "immune to criticism", but set up in such a way that criticism always has a specific, useful outcome.

Or turning your question on its head: If it is possible to fix and you would like to see it fixed, why do you insist on criticizing?

And it's not just "here, hack our code to make it work for us", although that is of course preferred. It's already useful to have people report problems or to talk to people who work on the code on forums. It is absolutely conceivable that a lot of the people already working on Firefox simply never thought of adding line numbers to the view source (as mentioned elsewhere, you CAN see the linenumber already, just not constantly on the side) and having the suggestion come up from the community is already a valuable asset. If that's not your thing - no problem. But for some people, it is, and that's how the software grows.

As for the comment about advertising: Mozilla does collect money on Firefox (through Google, mostly, IIRC) and uses the money to advertise it. Advertisement brings more users in who may be interested in participating.

They are simply not your standard software corporation that turns money into software and software into money.

Or turning your question on its head: If it is possible to fix and you would like to see it fixed, why do you insist on criticizing?

Because the time he would spend changing it (and learning how the project codebase is structured, and setting up the environment, etc, etc.) would be orders of magnitude higher than if the same change was done by someone who actively works on the project.

Because even if he writes a patch, it might be rejected and then all his effort will be effectively wasted.

Besides, this is not a valid response anyway. If the code browser should have had line number support and didn't get it for seven years, then clearly there is some problem. Pinning that problem on the person who first spoke about it doesn't really improve anything.

First - maybe my reversed question wasn't entirely clear. I was asking why he so insists on his right to level as much criticism as he can at a FOSS project when there are clearly ways to get the job done.

What I said was that there already are places to bring your ideas and criticism. You say "the code browser should have had line numbers support" - well, by what right is that a necessity? If it really was such a bad idea to not have line numbers, you'd think people would be all over this for the past 7 years. They weren't, because there already is a way to figure out the line numbers. It might be a matter of taste whether their old solution did the job, but that's why I think it's a sign of how the consensus has shown that it wasn't needed.

Now the tables have turned - somebody went through the trouble to get the code done, enough people were convinced that it's a good idea and it has been accepted. So what's your beef here? The process works just fine.

Just because you or the person you are defending wouldn't go through the trouble doesn't mean that it wouldn't be taken over by other people once a critical mass is built.

It's all fine and well to bitch about hypothetical issues, but I don't see how you can do that in a topic that screams the exact opposite.

Downvotes, really? Is it because I used one of the grown-up words?

[edit]And downvotes yet again. Look - This is growing into yet another HN meta-problem. I think I really did my best in having a discussion - the result is it being abandoned and me being downvoted. At least have the courtesy to give me a reason.

Ok, I'll give you an opportunity to downvote me back.

You keep turning this into something more melodramatic than it really is by using words like 'insist', and like 'bitch'. That's not conducive to a discussion.

Somebody pointed out what they think is a flaw in some product. In one sentence. Your defensiveness to that sentence is just way out of proportion. It's not unsurprising nobody's responding. A downvote is the appropriate response.

Elsewhere you said:

"you don't need to act surprised.."

That is passive-aggressive. You're insinuating surprise that I can't see. And you're claiming the surprise is pretend. A lie. Who wants to respond to that?

I cannot downvote you because I don't have that power yet.

I guess my defensiveness stems from me being in a similar field as a FOSS developer. I have seen far too many times that people prefer to "bitch" about an issue instead of even notifying me about it. In fact, people love to "bitch" about issues that aren't even there (as an example, the classic "Firefox is slow" is almost always a matter of somebody who has used and upgraded for a long time, resulting in an application with too much baggage - of course a freshly installed application will outperform 6 years of history, cookies, passwords, extensions etc.).

I really wasn't talking about "the flaw in some product", because whether it's a flaw is subjective and also whether it's a product is subjective. They are trying to force a discussion that goes against the very nature of the subject. That is the reason why the discussion is not appreciated - they cannot have the discussion they want and so they ignore mine.

As for "don't need to act surprised" - sorry, that's really what is happening here. I see a lot of people who are bending over backwards making the case that line numbers should have been there for 7 years ("now! finally they get to it! how crazy to take so long!") and share the cognitive disconnect that they apparently have a desire to moan about the FOSS process being broken while actually being witness to a situation where it worked.

Cue them moaning about whether or not "OSS projects [are] immune to criticism merely because you can fix them, given enough time?". No, they are not. This is an example where it worked. Don't act surprised.

See why this is an unproductive discussion, and both sides just vote? (With your side happening to be less numerous in this thread, pure accident, doesn't mean anything.)

I don't think the original commenter is trying to accomplish anything. It's such a minor issue. Passing judgment isn't about wanting to effect change at all. Judgment is about deciding between say firefox and chrome. (Now this is a minor dimension, so hopefully nobody's using it as a basis for the decision.)

Let me turn the question around. If you want to accomplish something why would you use confrontational language? I'm certain you too realize that and aren't trying to convince anyone of anything. You just need to vent. So, if both sides are like this, what's the point of discussion?

The only thing to do with judgment is to take it in the chin (maybe correcting gross factual inaccuracies) and move on. Anything else sheds more heat than light. If that seems unfair, remember that I have no users in my open source projects, and would kill for someone to try it long enough to judge it. (links in profile)

Yeah, I'm afraid you are right - being a FOSS guy talking to people who want their "product to just work!" is a very tiring thing. They want to pass judgment while I want to discuss the process of their judgment. I don't do it often, but this thread was just too tempting, what with it having an example of the process working as it's main subject. Of course, people still get it wrong and then insist on being right. Very hard to deal with in general.

As for your project - phew, that is miles over my head, sorry. Trust me, though, traction can also be a curse. At a certain level, you start to get people who don't criticize your software or code, they criticize you for their own inability to use it.

"It is absolutely conceivable that a lot of the people already working on Firefox simply never thought of adding line numbers.."

The bug was opened in 2004.

"...line numbers to the view source (as mentioned elsewhere, you CAN see the linenumber already, just not constantly on the side) and having the suggestion come up from the community is already a valuable asset.".

In 2004 it was the same developer-focussed feature that it is today. I suppose it's only that today, the community is more concerned with developers and back then, people didn't mind as much. I still don't, as an n=1 example.

Do you really go hack on random large codebases at a moment's notice when something about them irks you? If so, please know that nobody else on the planet can do this without spending weeks of time (conservatively).

Yes. At least when the codebase is in a paradigm that I'm familiar with. Note: language is not important in exploring a codebase. I probably couldn't do this with, say, GHC. But, I bet I could with Clang or a js library, if I wanted.

While I might not know my way around the codebase, I can certainly use grep to find where I need to go, or just ask someone on irc. In a few hours, I can at least find where I need to be, and be hacking.

The end result might not be good enough to send in as a patch, but it'll certainly fulfill my needs.

Sure, I have some skills that others don't. But, I'm not the only one who can do this, either.

It's interesting to think that this might be a skill that we free software developers have to degrees that other developers don't. I generally think of this as "hacking".

Yeah I'd love to have a place or way to learn from free software developers.

That's really cool. I'd love to see and learn from some of your past patches.

The biggest thing to learn isnt in the patches. It's in the process -- don't be afraid to break things, and dont let "I don't know everything about this" stop you from learning one small corner of it.

Yeah I've tried that many times (I have some experience with vim, gcc, windowmaker, but mozilla was larger than them all, last time I checked) and with some success. It's totally possible. My point is merely that it's labor-intensive. There's a cost to swapping in all that state, and to swapping it out and back in again everytime you find a bug with your hacks.

(Tangent) Lately I find I'm much more likely to hack on codebases with lots of tests. Having a single command tell me when I've broken things makes me less afraid of having to deal with subtle breakage, where my changes break some feature I just happen to not use for the next n weeks/months.

Depends on which Firefox you are talking about. If you're talking about "the community of people and organizations that develop the browser called Firefox," then your post is correct.

On the other hand, if you are looking at Firefox from the perspective of a consumer deciding between browsers, then the complaint is valid, assuming line numbers are important to you. They are kind of basic, and the product has gone long without having them.

> Ultimately, a free software project lacks feature X because you haven't added it yet.

This is also true of proprietary projects. I can edit the machine code or clone it. This fact doesn't invalidate observations of behind-the-times features in proprietary projects. In OSS, the barrier to entry is lower, but still substantial. Likewise, it's reasonable for us, as consumers, to observe when OSS projects don't implement things we want. I don't hold them to different standards merely because I have been invited to spend my valuable hours working on them.

I guess I will boil my argument down to: it's not their fault it's bad, it's your fault you're using it.

This applies equally to Free Software and proprietary software. "Don't like it? Don't use it." Your complaining isn't going to make the software better.

Decide on a course of action that will resolve your complaints, and then act on it. Posting to HN, "look at those l4m3rz at Firefox not implementing my features! They suck!" does not count because the logical conclusion of this action does not lead to increased happiness (either yours, or the wider community). It's like a little kid complaining to his teacher, "Johnnie hit me!", the teacher asking Johnnie "Why'd you hit Bobby?", and Bobby saying "Because Johnnie hit me first". The end result is a couple of sore schoolkids and an irked teacher. As adults, we need not let our actions devolve this way.

So, if this issue bothers you, you need to suck it up and stop using Firefox, or suck it up and implement the damn feature that you obviously care so deeply about. If you don't care about your feature enough to implement it, why should anyone else? Why are other people different from you? Because they've implemented features before? You expect free work from people that have given you a free product, simply because they have proven themselves willing to work for you for free before? Right, that make sense.

The advantage that free software projects have over "don't like it, don't use it" is that any user can change the software and other users will be thankful for the time and effort you put in. That's what being an adult is like.

Ultimately, all free software is based on altruism; people contribute because they want to. If you don't understand the concepts altruism or community and just want to take and complain, then you're not going to get any argument about how you should take ownership of issues that concern you.

> Your complaining isn't going to make the software better.

There are many cases where this is not true. For example, any feature request based on a bug report. It's true that a bug report is in a different forum of complaint. But unless you can point out something that makes feedback from this forum useless and bug forums not useless, I'm pretty convinced this is generally false.

> So, if this issue bothers you, you need to suck it up and stop using Firefox

You can use this same argument to forbid criticism of anything. While I don't want to accuse you of doing this directly, it strikes me that if an argument can as easily be used for something obviously nonsensical as what you're actually using it for, it might not be a very good argument.

So we're going to call "whine about it until someone gives me free stuff" a good argument then?

The point is simple: Firefox gives you everything you need to decide your own destiny. If you decide on a bad one, why should Firefox be blamed?

I'm not calling anything a good argument. Just pointing out flaws in yours.

You seem to be bending over backwards to make that work, though. Playing the devils advocate is all fine and well, but you do need to know where your argument is headed.

"Just pointing out flaws" is a good thing, too, but it would help to balance that with an equal amount of discussing his argument.

I think his argument is sound even though he doesn't have a pleasant way of arguing it. But similar to the point he is making about FOSS Projects - in that they do tell people "Either you're helping, or using, or you're not helpful", you are not helpful.

If you insist on being a "consumer" of a FOSS project, you insist on being something that they have no use for. That's your decision. You cannot argue that that is their problem.

I disagree. Someone else boiled it down better: are OSS projects immune to criticism merely because you can fix them, given enough time? No. Doesn't matter whether you can argue it pleasantly or not.

Yes, I think I replied to that branch of the comments as well.

And again: No, they are not immune to criticism, they have just set up a way in which criticism is handled in a particular manner, ie. channeled into discussions or in hands-on fixing. If you don't use either, you don't need to act surprised that they don't appreciate your criticism.

Are you saying criticism of firefox must be restricted to bug reports and mailing lists?

No, but I'm saying that if you care about your criticism actually accomplishing anything, those are certainly the best addresses to ring a bell.

Don't really see how you came to this conclusion. The very bug that's linked in this story was filed in the proper forum more than half a decade ago (i.e. it's a counter-evidence to your assertion).

Replace 'complaint' with 'feedback'.

Is all feedback bad now because you have the opportunity (however unrealistic to many) to just sort it out yourself, or just use different software?

Or do you only dislike the concept of feedback when it's not positive?

I don't think this discussion is helped by rephrasing some of the core statements until they mean something different.

This entire topic was about people kicking some dirt at Firefox because it didn't have individual line number markers until now. That's not feedback, that's not even just complaining anymore.

Of course feedback isn't bad and even complaints aren't bad - if they are directed at making the situation better. If it's just random people bitching in their own blog or a comment site like HN about how slow, bloated or whatever the criticism-du-jour-X of firefox is, that's their right, but it doesn't get anybody anywhere and they shouldn't pretend like it's Mozillas fault for not having a process for addressing and pleasing them.

If they want to actually see Firefox progress, they need to put their speech where it is heard and put their hands where they help. People who do neither are complaining for its own sake or to show off how much better alternative-option-du-jour-Y is, to them. Both don't get anybody anywhere, so THAT is bad - has always been, will always be, anywhere.

I think your point is that if you want a feature implemented in an OS project, you should implement it yourself. In practice, we're web developers, and it's much easier to just pick up google chrome than it is to get set up with developing firefox, getting into the code and implementing the change.

That being said, I'm seriously considering cowboying up and contributing to get the ruby tag implemented in firefox. This is not because I use Firefox myself, but my users do, and faking it with js/css is brittle as hell.

Note that Firefox did show the line (and column, which is impossible to get in Chrome) number if you actually clicked on any point in the view-source window. It just didn't have a gutter on the left with the line numbers.

As far as the ruby tag, if you really are interested I'd be very glad to get you up to speed. There's a partial patch, but it has some issues that should really get dealt with before it lands. Of course every single ruby implementation out there is broken as hell in the relevant ways, so maybe it should just land issues and all... In any case, let me know if you do want to get it into shape. I do have to warn that this is not a small-and-simple project unless you really want to learn about the layout engine internals anyway.

Thanks for the offer. I would take you up on it but as you say (and I sort of expected) it's not going to be a simple project and I have a lot on my plate right now.

The "switch to something else to fix a bug" strategy is clearly unsustainable. What do you do when you find a bug in chrome then? Switch back to firefox? Switch to opera first before you switch back to firefox? Just change browsers every month in the hope that they all have different bugs?

(chrome has plenty of bugs: the latest update on linux has a tendency to hang and use 100% cpu in some glib functions)

On the other hand to do changes to large code bases on short notice is a big asset to your programming skills. See it as a challenge. It's well something you could put up on your resume.

Often the main challenge is just to find the code, and if you can't do that can you deal with any other non toy code bases? Once you found it a lot problems are easy.

nn -- (who has one patch in Firefox)

You can do so, however, note that you still need acceptance for mainline.

Obvious things such as line numbers, are obviously accepted once implemented properly.

Note: the below comment is actually inaccurate, I though ruby tag was the language (as the author mentioned js as alternative). Keeping it for the comments discussing it, but keep in mind I was actually wrong.

Things like a ruby tag might be more complicated than you'd think.

You see, the main difference between Firefox and Chrome (yeah, it's not the UI! ;P) is ideology.

Firefox folks believe in a standard and compatible web. Chrome folks believe in .. implement whatever we think is faster than what we have (or /flamebait hat on, whatever helps Google make money/adverts/lock-in users).

Supporting ruby might fall in the "but it's not standard" "it splits the web" category.

And that's be correct, in my opinion. So you might want to check on that before actually getting the code done, unless you plan to fork.

The ruby tag is not related to the ruby language

http://dev.w3.org/html5/spec/Overview.html#the-ruby-element

Seems to be part of the standard...

Alright, I did not actually know that.

i'd say go right ahead.

I'll note also that it's a draft - something that annoys me with HTML5. New drafts are sent every next day or so, so it's not actually very standard. It's a different story though.

Chrome folks believe in .. implement whatever helps Google make money/adverts/lock-in users.

Citation needed.

I had the hat on.

But for the sake of discussion, please keep entire quotes, instead of rewriting what I wrote initially.

Chrome folks believe in .. implement whatever we think is faster than what we have

For example SPDY is faster. NaCl is faster. That's not bad. It's just not the same focus.

Now, NaCl also helps making money and helps with lock-in for example.

There are several other examples in the -webkit functions and some things which are not part of the actual webkit (only Chrome's version) such as Dart and the like.

While I can't provide a citation, I believe that the contrapositive is true: if it doesn't help Google, it's not going to be implemented. Right now, Google's interests are aligned with a standardised, compatible web, and when Google gets big enough, or greedy enough, it's going to take Chrome in its own direction. Opera still fares badly at Google's services, but they consider IE worth supporting.

> when Google gets big enough [..] it's going to take Chrome in its own direction

Hasn't Google already taken Chrome in its own direction? Chrome includes lots of non-standard technologies like Flash, NaCl, Pepper, Chrome Apps, and soon a Dart VM. Google believes these technologies are good, but no other browser does, and not even WebKit.

Maybe those are good and useful technologies, that is a separate matter. I'm just pointing out that Google is already well in the process of taking Chrome in the direction Google feels is best, regardless of what the rest of the web thinks.

I see. So you're blaming Google now for something you imagine they might do in the future. How could Google defend itself against your accusations?

Not blaming, but worrying about. There is plenty of software that can read Word's .doc files. Yet I store my data as plain text, as I imagine that the software will be killed or end-of-lifed in the future, even though I can use it fine right now. In the same way, I'd rather use a browser designed for an open, standardised Web.

Chrome doesn't have nearly enough market dominance for me to make accusations about it; I just want to minimise any future disaster scenarios.

>This is how Free Software projects work

Isn't Mozilla a non-profit org with a hefty budget ? I guess it isn't unreasonable to expect improvements from the core team. Sure you can't demand them but I guess once you have a paid team working on the project you expect some polish, especially when it coincides with their goals of helping/enabling developers.

It is, but think about it; all the developers that know how to fix this also know how to fix one of the other million bugs in Firefox. And those are probably more important "to developers" than this one.

All bugs and features are important to someone; the reality is that there is an infinite amount of stuff to do that would be of great benefit to everyone, but only a finite (but perhaps large) number of people that are able to act on. The only way to act purely in your own self interest is to do something yourself; then you get one task and one person to implement it that you have full control over. Acting entitled doesn't get you anything other than the ability to stop giving Mozilla money and switching to Chrome. (But I'm guessing that 99% of people wanting Firefox features aren't giving Firefox any significant amount of money. A feature like this probably takes someone skillful 8 hours to implement. At $100/hr, which is a reasonable rate for an employee with overhead, you should be donating $800 to be entitled to a fix. And that's not even how donations work.)

I'm saying that if this enhancement was truly important, it would have been done sooner. What people think is important and what is important are often very different. "Let the market decide," is my philosophy.

It sounds like you're saying that the entity called "Firefox" shouldn't be blamed for aissing feature, because it's up to people to write the code. That's a strange definition of what "Firefox" is. I think Firefox is its community of developers, both those that work on the product full time and those that volunteer. A lack of such an obvious feature is in my eyes a problem with "Firefox."

  > This is how Free Software projects work

I'd argue that was the opposite how Firefox project worked when Blake Ross was still guiding it. Clear vision and direction, not passive wait for someone to submit something. Without this any project just becomes a mess of patches.

That's simply not true. Maintainers exist to coordinate effort, not to do all the work themselves.

A good example is GNU Emacs. There are two maintainers, but most of the code is written by other people. Even RMS' code doesn't amount to a particularly large percentage of Emacs anymore.

By this logic, it is impossible to evaluate any open source project, because all that ends up being evaluated is the reviewer's personal failure to implement whatever qualities they were looking for.