Hacker News new | past | comments | ask | show | jobs | submit login

Don't get me wrong. I agree with you, and I don't think it's really a problem. Hell, if it is it's not a problem to use both libraries, and to serve 1.x to those using older browsers. It's just a shift in the core mentality of what people view jQuery as.

Many of us use jQuery because it works, regardless of what browser a user is on. For a lot of others, jQuery IS JavaScript. If they want to do something on their site, they look for a jQuery plugin and use that, otherwise in their mind it'll be too much work to get it done. It's depressing, but it's the reality of development.

One point you raise that I do disagree with is:

> Go in 10.9 and fix any incompatibility you find with the latest browsers yourself. Or wait for someone of the multi-million strong web dev community to do it for you.

This is the classic open-source "fuck you with a smile" response. Fixing new functionality is not an attractive problem, and out of the multi-million strong community I can see very few people with both the skills, the time, or the desire to fix these problems, and those that could fix the problems are more likely to wait for someone else to do it.

I'd consider myself fairly handy with JavaScript, but I'm also a very busy man, and my office won't want me spending company time fixing a bug in a plugin if there is another way. Also, there isn't a developer alive that likes fixing legacy bugs. I can think of a million things I'd rather do than fix IE6-7 bugs.




> This is the classic open-source "fuck you with a smile" response.

Since open source is free and open, it really can't fuck you †. You can however screw yourself by relying on it to do your work for you.

As you say, few people have the skills, time and desire to fix these sorts of problems, and that means you can't rely on open source to fix them for you.

Fortunately, there is a simple solution to this called "money" which companies have and which can be given to a developer with the skills who will magically convert that money into the time and desire to fix the problem.

† If your company is willing to use open source, but only when it is perfect, and not willing to help improve it, maybe they are the doing the fucking?


I like how you denied the "fuck you with a smile" response with the very "fuck you with a smile" response he was complaining about.


The point is that if you're a company that's relying on an open source project and not contributing back to it then you have no basis to be "fucked" by the project.


Well, I believe the person in question wasn't saying that the project itself was saying "fuck you", but the people answering the response were saying it. The point being that there are too many people that say if you don't contribute then shut the fuck up. But, of course, different people contribute in different ways. Not everyone who uses open source software are developers, and for many of these people the simple fact they use the software is their way of contributing. So when one of these people stand up and say, "I have this problem", the appropriate response is not "contribute or shut the fuck up". This is the response that is being encouraged here. It is irrelevant if the statement about a problem came from an individual or a company. The reason that such a response is a bad idea is that it actively encourages people to not use the software in question. If the goal is to get everyone to stop using open source software, then by all means continue to tell them to fuck off.


There's more than just source code contributions that help an open source project.

Being the lead dev of a fairly well used open source project I can say for certain that too many people I've had interactions with that want a bug fixed or a new feature added do so with entitlement. As if by not doing it they're being told to fuck off.

I may have dramatized it a bit but there's something about software that people feel entitled to get value at no cost.


So, you treat the entire group based on the actions of individuals? Do all the people who use your software behave in this manner? Do you think it's possible that people researching your software will see any of your possible bad behavior (I don't know if you do or not) and decide not to bother?

I never said that someone like you were telling people such things by not doing what they request. I'm describing people who's immediate reaction to almost anything is "only contributors may complain!" and if you don't fit that category then good for you. That means I'm not talking about you.

If someone submits a bug report or feature request that you feel you cannot get to in a timely manner or don't feel is necessary then you can politely explain why. If the person responds to this with an entitled attitude then the problem then lays with that person, not you. If you respond to a bad attitude with a bad attitude then what picture are you painting to everyone else?

It's classic customer service, you are polite to everyone but firm in your decisions. No one says that you must cater to every single person who says anything about your software, but you should be polite in saying no. How you say no provides a much clearer picture of your project than how you say yes.


Agree with all of that except you saying that I'm generalizing. I mentioned it is a subset, but that's the subset I'm talking about. I hope anyone who asks politely will get a polite response.

But the idea of "being fucked" [1] implies some level of entitlement or deserving something.

Providing feedback is very useful for open source projects. But there's a fine line between providing feedback and feeling like you're getting a "fuck you" when it's not implemented or fixed.

[1] > This is the classic open-source "fuck you with a smile" response.


I think at this point we're not agreeing on the terms in use.

When you say someone is "being fucked" by an open-source project I see that as the project itself, or the people on the project, causing a significant problem for the person involved. In fact, I would say that such a strong term means that the the detrimental aspect is likely intentional. The project itself is causing a negative action to that person. This is not what I'm describing.

When I say the response is "fuck you with a smile", there's no detrimental action involved. I see it as a very impolite way of saying no. The person receiving the response can ignore it or choose to go somewhere else, either way there's no real negative action being done to them. All I'm saying is with that response I would assume most people would choose to go somewhere else.

Again, this issue isn't whether someone acts with a sense of entitlement if they complain that their suggestion or bug report isn't implemented. As I said before, if someone whines in that instance then the problem is with them, not the developers. On the other hand, if someone makes a statement along the lines of "this feature doesn't seem to work right", or "this bug prevents me from doing something I want to do", or "it would be nice if this feature was implemented" then responses like "only contributors can complain!" or "learn to code and fix it yourself!" are developers using the "fuck you with a smile" response. I feel that is wrong and not productive in any way. It is actions like this that will push people away from the idea of open-source software because who wants to deal with that nonsense?


>This is the classic open-source "fuck you with a smile" response. Fixing new functionality is not an attractive problem, and out of the multi-million strong community I can see very few people with both the skills, the time, or the desire to fix these problems, and those that could fix the problems are more likely to wait for someone else to do it.

If it was something like a database engine, an obscure language, some network utility, a server, etc, I might have agreed. That is, if it was something esoteric, that needs high skills, and only some very knowledgable of it's internals could adopt it.

But this is jQuery we're talking about. Not rocket science. Lots of guys have the skills and time to fix these problems.

>I'd consider myself fairly handy with JavaScript, but I'm also a very busy man, and my office won't want me spending company time fixing a bug in a plugin if there is another way. Also, there isn't a developer alive that likes fixing legacy bugs. I can think of a million things I'd rather do than fix IE6-7 bugs.

And wouldn't the same exact reasonings apply to the jQuery team? They can also could think "of a million things they'd rather do than fix IE6-7 bugs".

Still, they said the will release 1.10, and support old browsers for as long as needed. If they hadn't released 2.0 that would also be the case. They would support old browsers for as long as needed. The only difference is now they are doing it with two codebases.

That said, your company might not want you "spending company time fixing a bug in a plugin", but for popular plugins there are companies with the money and the resources to have their stuff fix them if the need arises.


I think we'll get a lot less from the open source community if they think they have to support all legacy crap for all time. Eventually there comes a time to move on.

We're just arguing about if its time yet. People can still keep using IE 6/7 for the shitty inhouse apps written for it by their company a decade ago, and use a damn modern browser for everything else.


> People can still keep using IE 6/7 for the shitty inhouse apps written for it by their company a decade ago, and use a damn modern browser for everything else.

You should try working for an agency that handles large clients.

A year ago I was still building pages for an airport that needed to support IE6 to a functional level. We charged a huge number for that support, but this was such a large client that had a proven need for it (analytics and sales data) that they would happily pay several thousand for us to build a section that supported these users. Luckily we left that client, but we still have a number of clients that want IE7 browser support.

I'd like nothing more than to ditch older browsers, but until XP dies many of us will still have to support older browsers. Once XP is gone, the older browsers are gone.


>> A year ago I was still building pages for an airport that needed to support IE6 to a functional level. We charged a huge number for that support

Bravo. What you did was rational, explains why the jQuery team is doing this, and gives you your solution.

You and they both recognize that supporting old browsers is expensive. They're dropping that support. You're charging a lot to deal with it, which incentivizes clients to stop asking for it.

With the extra money you are charging, you can, if necessary, pay someone to fix bugs in jQuery that affect those clients' projects. You can contribute those patches back. Everyone wins.

I understand your emotional response to "losing" support for browsers, but this is not a story of open source failing you. You could have been paying for a proprietary library instead of using jQuery. jQuery has already saved you thousands by being free. You don't get to dictate the project's direction, but you have lots of savings ready to patch it as needed.

I'd say that's a pretty good deal.


> You're charging a lot to deal with it, which incentivizes clients to stop asking for it.

On the contrary, clients couldn't care less about how hard something is for us to do. Sure, if you're working for a creative agency and people are held back by the limitations of what they can accomplish when dealing with IE6 you'll notice a drop in morale, and in the quality of work that is produced, but ultimately the client does not care. Would you care if a plasterer said that plastering your ceiling would cost more because of the materials used? You'd still want it done, because the perceived value far outweighs the cost of doing the work.

Some of my employers' clients are large companies, with fairly large budgets and a good idea of what they want and what they need. As a result, despite charging a lot more for legacy browser development (easily over double, last time I checked) the client is fine with this. If the client believes they are earning £2k a month from IE6/7 users then charging £5k extra for a job that originally cost £2k isn't a problem for them.

> With the extra money you are charging, you can, if necessary, pay someone to fix bugs in jQuery that affect those clients' projects. You can contribute those patches back. Everyone wins.

Absolutely, and on occasion I've been lucky enough to contribute my findings from work to Stack Overflow, or directly to a broken open-source project. Hell, one of my best answers on Stack Overflow was as a result of fixing a problem at work that numerous others appear to have with a certain jQuery plugin.

However, this falls apart if you're working towards deadlines. The client often isn't going to wait very long for you to fix an issue in a product you use, and if they know that you're spending their time and money fixing a bug in a product you use the first thing they'll ask is "why don't you use something that works like [competitor]?". The reality of the situation is, like many others, when working towards a deadline with legacy browsers everything is a hack, and not a hack that we are necessarily proud of. I usually don't care what I publish, because work I'm proud of a few months ago looks inefficient or ugly to me now, and frankly I'm quite happy to have people criticise my code if they offer better solutions, but I'm willing to bet that a lot of people either won't publish their fixes, or would risk their jobs if they were found to be publishing code written on company time. I've worked for companies that would probably flip if they discovered that I had patched a plugin with code that I had written for one of the companies projects.

> I understand your emotional response to "losing" support for browsers, but this is not a story of open source failing you. You could have been paying for a proprietary library instead of using jQuery. jQuery has already saved you thousands by being free. You don't get to dictate the project's direction, but you have lots of savings ready to patch it as needed.

A developers emotions are different to the "emotions" of a company or a client. A developer is more likely to understand the rationale of this decision, whereas a company or a client won't care. All they want is a working product as quickly and as cheaply as possible.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: