I have really mixed feelings about this. To my mind, the larger outrage is that people were fired over this.
I'm aware of the tendency to try to focus on what it seems like we can control rather than on actual justice. In this case, I'm so far only seeing outrage about the Easter Egg. I'm not seeing outrage about "They fired people over this???!!! People whose only crime was using Ant??!"
I'm not a fan of what Christmas has mostly turned into these days. I'm ambivalent about leaving a remark that could easily be wildly misinterpreted as supporting and encouraging cultural insensitivity by Americans/Westerners.
Anyway, I may seriously regret commenting at all. This seems like a can of worms for various reasons. I just dislike the idea of standing idly by while the developers get lambasted, as if they should have known ahead of time that people would be fired over this because of stuff happening in China. I'm also leery of the possibility that the other answer will be to ignore the seriousness of the situation for some people and act like "not my problem."
Imagine working for the state. Your non technical boss comes in and asked why you have a holiday theme on the page when policy is to not show celebration on state websites.
He asks you why you put this code in. You tell him you didn’t write the code. He asks who did. You tell him it’s open source, many people contributed and someone put this in without telling anyone. At this point, you’ve lost all credibility to you non technical boss and all of his non technical execs. You put a strangers code on the state run website, without reviewing it and without knowing what’s in it.
If your boss can't sell which things are part of their output and which are external, they're not doing a very good job. A default Chrome install might have a Christmas-themed homepage, an ISP might MITM HTTP traffic with a greeting, an OS/hardware manufacturer/ad network/other 3rd-party might do something...
The days where the state run website only runs code written by the guy in the department who knows how to spell HTML are long gone. Everyone is working on a very small subset of the huge stack of complexity that makes someone else's browser on someone else's device made by someone else on someone else's network linked by someone else's CDN to someone else's datacenter that hold someone else's server hardware which runs someone else's OS which hosts someone else's server stack and uses someone else's framework to show the data you actually wrote. If your non-technical boss can't explain that some parts of this chain aren't under their complete control they're just not being honest.
> Thu, 23 Mar 2006 00:52:58 +0000 (Wed, 18:52 CST)
> Jerry A. Taylor submitted the following Information:
> Email xxxxxxx
> Company City of Tuttle
> Location Oklahoma
> Comments
> Who gave you permission to invade my website and block me and anyone else from accessing it???
> Please remove your software immediately before I report it to government officials!!
> I am the City Manager of Tuttle, Oklahoma.
And the response:
> From: Johnny Hughes
> To: Jerry A. Taylor
> Subject: Re: www.centos.org - Contact Us Form
> Date: Wed, 22 Mar 2006 18:59:18 -0600
> I feel sorry for your city.
> CentOS is an operating system. It is probably installed on the computer
> that runs your website.
> We hope you are happy with it, since we produced it for free and you are
> able to use it without paying us ... and are even threatening to have us
> arrested for providing to you free of charge.
> Please contact someone who does IT for you and show them the page so
> that they can configure your apache webserver correctly.
> Thanks,
> Johnny Hughes,
> CentOS 4 Lead Developer
Figured out what happened yet, Encyclopedia Brown?
Yep: The city of Tuttle, OK, had a misconfigured/unconfigured site which was showing the CentOS default page. The City Manager of that August Berg thought "We've been hacked! We've been hacked by hackers with a bland corporate logo who left contact information! I MUST THREATEN THEM USING EMAIL!"
Click the link. It gets stupider.
My point is, you have to take the... uh... "violently ignorant" into account whenever you design things which can be public-facing.
”If your boss can't sell which things are part of their output and which are external”
“Don’t blame my personnel. They didn’t write that; they just chose to run random code downloaded from the internet” isn’t an optimal reply to “why is our web site broken?”.
In China, I can see this go towards a “only use packaged approved by the government”, where such packages are signed, and the government knows who to put in prison when a package contains such a surprise.
Because the Chinese state run website is accessible from, say, an Apple iPhone running iOS/Safari. It is probably intended to be accessible from ISPs outside the country. It is developed on Windows computers and hosted on Linux servers, which probably run a server stack that's a combination of open-source modules and proprietary glue.
Granted, your Chinese state-run website is probably more control-oriented than a hypothetical SV startup which consists entirely of connecting VC money to external microservices with a little copy added in by machine-parsing a slide deck...
"If your boss can't sell which things are part of their output and which are external, they're not doing a very good job."
The world is full of bosses who aren't good at their job. And bosses who are flat-out ignorant, capricious or lazy. None of these factors will protect the technical person mentioned in the grandparent post.
And you'd be shocked at how many state/federal resources have a single point of failure. Add to that small-to-medium sized companies, and suddenly there could be a lot of people taking (possibly irrational levels of) heat from their bosses.
I worked for a corporation for a few years. We had strict rules about not downloading anything to our work computer because they did an internal study and found that 98% of all malware came from employees downloading music apps and that sort of thing. So they forbade it all wholesale. Breaking that rule could get you in trouble, up to and including being fired for it.
So, sure, it's possible that in some cases people were fired because this Easter Egg outed them for violating some rule. And it's entirely possible that some of the cases of "I got fired for this" are that kind of scenario.
But if this is not against the rules and the firing is actually because it is Christmas-themed, that's a different situation.
I'm also aware that it could be a cultural thing where someone has to be the fall guy and heads will roll to prove our innocence. I see that as deeply problematic. If you didn't forbid open source, firing someone for using it as the "first offense" penalty is not a good policy.
I realize we likely have very little information at this point in time about the details behind the firings and it is the norm for early reports to be wildly misconstrued, which is one of the reasons saying anything at all here is potentially something I will regret.
It's very different if you're a developer. Developers are almost always local admins, and unless you work for NASA, you're always going to be using 3rd party code. You simply cannot write everything (or even a fraction of) the things you need for basic applications in the current space. This isn't the 80s and we're not on Commodore64 machines and punch card systems.
Actually this 'very different' aspect is a broken piece of modern development - its a bug, not a feature. There are methodologies which could have caught this entire stack issue and nobody would have lost their jobs - its just that the ethics of "developer who has control over everything else, or else" versus that of "proper operations and support engineering management (i.e. fire burns upwards..)" are out of skew.
We've been putting up with live fixes and direct "developer"-"production system" style methodologies for a long time; only ethically. It just happens to be 'accepted practice' to fold some gargantuan code-base into ones own environment, without a line-for-line proper review. "Its impossible", say the bean counters. "Who would pay for that?"
Technically there is no good reason for the easter egg to have occurred, had someone done a proper code-review, observed full test reports, respected code-coverage rules and principles, and so on.
The easter egg proved that someone wasn't doing their job.
Really? So some team should have inspected the entire Linux or FreeBSD kernel they were running one? Someone should have gone line-by-line through nginx? What about all the shell commands used? They should have had people go line by line through bash, cat and all the other tools needed in the background to setup and environment, all their libraries, all their dependencies?
That's not even getting to a project. Have you looked at a projects node_modules, or the maven/jar dependences pulled in? Even for small projects, it grows to a very non-trivial amount very quickly. Inspect ever single jar and dependency?
Should people write their own web servers instead? Their own frameworks? Their own operating systems?
At some point you have to trust someone enough to actually get your work done. If an OSS project breaks that trust (like we've seen with some node modules) you stop using them, but inspecting every last dependency is often impractical.
Well, you see ... I happen to think that you can use a lot of tools to cover your ass, and .. the fact that this one slipped in is as much a comment on the crud that is promulgating the wild and woolly Node/JS ecosystem as it is anything else. In point of fact, this kind of bollocks is why I eschew Node/JS and use other things [1], instead.
I do believe there are tools and ecosystems which make this sort of thing less likely. I can't recall a Linux easter egg .. nor a Golang one ..
>Should people write their own web servers instead? Their own frameworks? Their own operating systems?
One should at least, audit. As much as possible. It doesn't take much for a competent dev to 'grep -ir "easter egg $CODEBLASE' or, whatever .. not that its an expectation.
But yeah, if you have to have government-level 5-nines on all services, then I would say - fair play. The responsibility for an audit of such things should definitely have been in the requirements. I've seen such expectations for lesser projects, personally, where .. indeed .. code audit and ownership were tightly .. and properly .. managed.
[1] - I don't know for sure, but I think its harder to slip in such an easter egg on a production golang system. I guess I'll tune into that if/when it happens/has happened..
Bullshit. IBM at least takes dependencies very seriously and while the system is not infallible there are persons whose role is to review what the heck people are including in the software, making sure there aren't hidden backdoor or potential licensing issues.
IBM contributes to the Linux kernel, so it might vet that one component, but does it vet every single component in an actual, functional distribution? That would be absurd.
No way they do, I included go packages and npm modules that were not vetted by others or myself. They do have a license review, with many licenses being pre-approved.
I don't know what possesses people to implement moronic surprises like this in software that people use to actually get things done. I remember just about shitting my pants when trying to boot a computer using Super GRUB Disk on April 1st and getting a prompt claiming that my hard drive was being formatted [1], or something along those lines. After wasting over a day with a non-booting machine verifying that I didn't catch something, I did some Googling and found out what my issue was. It is this exact kind of stupid bullshit that convinces people that open-source software is a joke that can't be taken seriously, and in some cases (such as this one), they're right.
Fun (autonomy + mastery + purpose)! Don't forget that most OSS is still developed for fun, and adding things like this are totally fine in that context. Now, if you want to use thousands (millions?) of hours of development from hundreds of developers for free, you might have to put up with them having a bit of fun. The alternatives are to pay them to make very serious software [tm], use proprietary software or review the code yourself (not viable most times).
And I'm not being ironic or anything, really, literally the thing pushing a LOT of OSS is doing it for fun. If people keep complaining and blaming those OSS devs and it stops being fun then they will stop doing OSS, as many have done. Or it will be delegated to big companies like FB, Google, etc. where they get paid for the OSS they make, which is a whooole different can of worms.
(there is a thread saying something about a political stance, but I'm not qualified to have an opinion there and most easter eggs are for fun anyway)
Even if I'm pissed off with this particular incident since I was working on a project using this great library and I was scared by the little snowy button :) ... but I agree with you those people are doing it for fun. I used too but lost interrest in working for free. A lot of companies are making a ton of money using (among many others) my OSS project. Even my current employer (big if not biggest European software vendor) is using it on a major product they're selling for millions the funny thing is that they don't even know and prohabiting employees to work on open source even in their own free time.
This particular experience make me understand that working for free on open source is really a foolish idea. I was tempted by changing the license but since there are many others using it to build their business I thought it's better to just keep it as it is by respect to early adopters and users which any project is nothing without them.
For a healthy open source project the work needed it's not fun at least for me, it's not just about hacking/problem solving/design, you need actually to do issues triage, answer questions, documentation, extensive testing (with whole infrastructure for builds/releases/communication) those are not fun activities and in most cases done better than paid softwares (because people are passionate about their projects) and in addition to that I need to work fulltime on different (shitty) things to pay the bills and have time for familly ...
A lot of FOSS isn't fun. It's funded, by IBM, Google and other big players. Intel has an entire OSS department at their Portland office, and contributes tons of Linux kernel drivers for their products.
Sure there are some projects that are based on peoples' passions and have a few maintainers, but a lot of the bigger projects are big company middleware. It's a big difference from the FOSS movements of the late 90s. I wrote about it before here: https://penguindreams.org/blog/the-philosophy-of-open-source...
I am increasingly of the opinion that free open source software should include fun things like this. It is an easy way to remind people just what "free, but with no warranty" means.
IIRC VLC's icon has a Christmas tree on Christmas. That's cool. Some library having a Christmas day Easter egg, not so cool.
That said the lesson here is probably that if you're doing any serious dev you really should be reading the source before putting the library in your app and, you should be forking the library into your repo or into your own package manager server and only taking updates you've reviewed.
If I was developing such a library, I'd add easter eggs into the code, tie all of them to a single, big switch and disable it by default.
Last, but not the least, I'll document it as follows:
This code contains easter eggs which are disabled by default. If you want to enable them, set easter_eggs_enabled=true. Please note that, the eggs have their own time, and it won't make them enabled all the time.
"What other hidden surprises are in the code?" would be one thought. If you can't trust them to leave the icon alone, what else can't you trust them with?
(Note that I don't necessarily agree with this but it's an obvious path.)
From my perspective, it's the opposite. I think that "If they're smart and fun to implement a Christmas hat on the icon, they're possibly nice guys, and won't do something sinister".
This is coming from my 20+ years of experience with computers and applications. I've seen that programs with easter eggs may have some stupid bugs, but won't have something sinister inside them. OTOH, applications with some very serious and no-nonsense attitude has the most advanced "phone home" mechanisms.
This is my experience though. I'd happily stand corrected if I'm wrong.
> This is my experience though. I'd happily stand corrected if I'm wrong.
I don't think anyone can call your own experience "wrong" per se. I'd point to the Google logograms as a "smart and fun [easter egg]" per your definition but they are definitely one of the more sinister corporations.
> I'd point to the Google logograms as a "smart and fun [easter egg]" per your definition but they are definitely one of the more sinister corporations.
Does it bother you that HN colored the numbers on the left column of the front page red and green today for Christmas? Do all these Firefox easter eggs also bug you?
Read the EULA for Windows; or Chrome; or Firefox; or Word; or ...
The no warranty clause is included in the BSD, MIT, GPL, MPL, and Apache licenses (and many others...)
Sometimes things will work out for you, sometimes it means exactly what it says on the tin: "I don't promise this works"
Your message has really annoyed me, I just wanted to say that. I found the tone quite upsetting, although I hope it's just because our only communication is through this brief chat, and we don't really know each other.
I've never made proprietary software. I've written hundreds of thousands of lines of open source code in dozens of projects. I make releases of those projects, answer bug reports and issues, review PRs, all for free. Often I get annoying demanding emails for support for something I give away for free, which is quite annoying, but I usually answer anyway unless the sender is really annoying.
In a couple of them, there are features which are the because they amused me when I wrote them. Nothing that would lead to a wrong answer. Maybe if someone wants to base their business on my free labor, they have to put up with that.
I’m an open-source author too, and I experience the same frustrations with demands for support and features, so I deeply hear you. That said, your initial comment did come across as pretty flippant without the context in your reply.
I think it was the “should” bit. Just as nobody should be able to tell you whether you can add light hearted features to your software that make you happy, you shouldn’t be telling others authors that it’s not ok for us to write open-source software that aims to be professional, transparent and trustworthy. I’m sure the things you write are these things too, and I agree sometimes it’s good to be light hearted and have fun, but I reject that we “should” inject reminders like this in our open source with the intention of reminding others it’s free. That would take us back to the days of nagware, IMO.
At any rate, if you were just venting, I hear you. Thank you for your contributions to open-source!
you shouldn’t be telling others authors that it’s not ok for us to write open-source software that aims to be professional, transparent and trustworthy
the poster didn't say that. i think you are reading a bit to much into those words. there is no mention of what other authors should do. poster is talking about their own motivations for adding features like that, but in no way suggesting that everyone should do that.
your response suggests that you can't have fun with software that aims to be professional, transparent and trustworthy. i'd disagree with that. pranking others is not the only way to have fun. but if that is what you believe, maybe you shouldn't be telling others that they can't have fun with their software.
a more measured response might be to point out that having fun is ok, but doing so at the expense of others comes across as unprofessional, intransparent and untrustworthy. but if an author doesn't mind coming across like that, it's still their choice. but then, that's my opinion. yours might be different.
Firstly, I'm of course happy for anyone to write their software how they like -- I should say if you want to write "business ready" software, then that's great. Often such things are backed partly by company.
A better phrasing might be, fun Easter eggs, like wishing users Merry Christmas, might be a good way to denote software which is free, but is not designed to be slotted straight into a for-profit business critical situation -- certainly don't come crying if something breaks on IE 11 or whatever.
When I read comments like those in this chain, the message I take away is "users cannot and should not expect to be able to use open source libraries in production unless they've vetted every line of code". This is probably true to some extent, but I'm worried about the consequences of it. Can someone no longer run an emergency services PBX on Asterisk because of the chance that it will start playing Jingle Bells, or that the Linux kernel maintainers will prefix the data in every packet with HOHOHO? If so, what does that mean for the future of open source, and how come it hasn't been a problem until now?
these features would not be a problem if properly documented in the release notes.
you don't need to vet every line of code, but if you don't read release notes then you only have yourself to blame if it breaks.
the problem here is not the feature itself, but the fact that it was hidden and undiscoverable by testing.
had the authors make a "christmas release" with the feature being active unconditionally, then even without it being documented, any user should have noticed the feature in testing.
things like this haven't been a problem until now, and they won't be a problem in the future because generally people are aware that playing pranks is not always nice for the recipients.
Can someone no longer run an emergency services PBX on Asterisk
They shouldn't have been doing this in the first place.
If so, what does that mean for the future of open source, and how come it hasn't been a problem until now?
It means that if you want to pretend you're making safe, reliable software, you (or your company) need to be prepared to accept liability for failures of performance. Actual engineers are actually responsible when their products fail. There's a reason we don't build bridges out of a thousand random packages we downloaded from a not-particularly-secure repository in the name of moving as quickly as possible to try and get the next VC dollar.
To me, your whole attitude to this matter is really annoying. I see you might be frustrated when people expect you to work for free but stupid easter eggs like this are the wrong answer. Or at least you have to communicate them. Like "don't use my software unless you've read and understood every line of code by yourself".
Just because you give away pizzas for free doesn't give you the right to poison some slices because people have to be reminded that nothing in live is free.
The proposed equivalence to poison does not hold and is beneath the standard of proper conversation.
There is perhaps equivalence to arbitrary and unusual pizza toppings on pizza given away for free, and people proceeding to base their livelihood on passing on those slices on without checking what’s on them (knowing that there is no process to determine the bounds of the realm from within which the pizza toppings may come).
Yes, the analogy doesn't fully hold up. Change poison to hot chilli to make it more accurate?
My point is, you should never create bugs intentionally. And you never put easter eggs in libraries. WTF?! Changing random button captions can render an application useless. Thats just a bug, not an easter egg.
Put your easter eggs in an about dialog or something that doesn't break everything.
I would agree. I would contend that the topping here was worse than hot chili. Perhaps poo-flavored if you will pardon the scatological connotation.
I wouldn’t have put that easter egg in. But for me the main point is that the story brings the sense that I ought to steel my resolve to somehow build better and more formal processes and tools to bring clarity and oversight and guarantees to our currently ad-hoc collaborative code sharing and reuse.
Really? I would say the topping here is Christmas Stuffing, or Turkey. Something reasonable to put on a Pizza at Christmas as a fun idea, but which some people might not like.
Of course not. Deciding to switch to a special fun Christmas Pizza recipe however, seems like a perfectly reasonable thing to do, which many people would enjoy, and I'm sure I few would be annoyed by.
I wonder if it's reasonable in the long run for third-party libraries to run under a restricted permissions model with explicitly-granted capabilities. Just like how it's unreasonable to expect an end-user to audit the code of a phone app they install, it seems almost as unreasonable for a developer to need to audit the code of every third-party library they use.
For example, if a library can't access the clock, then it wouldn't be able to implement this sort of "time bomb" behavior. You could also of course limit cookies, XHRs, etc. Certainly a bit hard to know how it would work from a technical standpoint, but I think if done well it would make diligence a lot more manageable.
I really like this idea. Although permissions will have to become a lot more granular. There may be a little bit of call overhead, but this kind of context level permissions would be amazing.
The framework mark itself as enterprise level
Used by many small companies in china, and those companies delivers products to many different customers, include chinese gov/military, and maybe some the middle east customers.
So the problem is that:
1. Chinese gov/military don't allow celebration of Christmas in their office.(CCP members not allowed to have religious belief)
2. It's a critical thing for some customers like The Middle east
3. If it's a hidden Easter Egg hard to trigger, it's ok; but it's not.
Comments from the dev of the Easter Egg:
1. He commented it's a small thing, don't need to include in changelog. So nearly all users don't known this
2. Another his comment: "I have already prepared for the complains"
I call that Darwinism at work: The author of this surprise disqualified itself for any job that requires trust or at least a minimum of cultural sensitivity [1]; the users of this disqualified themselves from any work that requires attention to detail (like actually reading the code of libraries used or at least checking the issue tracker).
[1] I live in a country that is 97% Muslims. For most here, Christmas means at most the beginning of "white, European tourist season". My SO thought until 2 days ago that Europeans simply have a week long warmup to the new year celebrations...
My opinion about people who demand professional perfection from software they neither pay for nor can be bothered to review the source of are probably well-indicated by the tone of this sentence.
I think there's a difference between putting a cosmetic thing like this in an application rather than a library; if you put it in your application, you're not going to change the experience of anything other than your own product, but by putting it in a library, you're changing the experience of other people's applications. From reading other comments here though, it seems like this isn't a universal opinion though.
Yea, and VLC is really just a media player. Sure someone might be using it in production at a Kiosk, but that little icon change literally doesn't affect production use at all.
Another reminder that dependencies are bad. Introducing someone else's code into your production environment without auditing it is a security breach.
This "undocumented code change" could easily have grabbed any login details/session cookies/personal data from the page and sent them somewhere, instead of drawing snowflakes. I doubt anyone would have noticed for a while... clearly there were a large number of people who weren't auditing the latest version of the code to see what changed, and only noticed the change because of the visual effects.
Sorry, but if you deploy a random chunk of third-party code into your production environment without knowing exactly what it does, you deserve to be sacked.
> Sorry, but if you deploy a random chunk of third-party code into your production environment without knowing exactly what it does, you deserve to be sacked.
Have you reviewed all of Linux, glibc, nginx/Apache, bash, all several thousand node dependencies, and so on? Do you do such a review each time you have to update a package?
Don't get me wrong, I think there's a serious problem with the micro-dependency insanity, but every single person on the planet depends on others. "We stand on the shoulders of giants" is more of a truism today than it has ever been. It's not a sacking offense to trust people (because you wouldn't be able to do your job if you spent all of it reviewing other people's work).
Most people have a reasonable expectation that maintainers of a project are reasonable people -- which is why the micro-package insanity is particularly problematic. I trust most kernel maintainers and so I don't check each Linux release to see whether a backdoor was added (I only check if I've noticed a problem). The blame should be on the maintainers here -- it isn't acceptable to add Easter eggs like this to a library used by many people (especially if it's being used for Serious Business™).
Would you blame every glibc user (which is all Linux users) if they decided to make all math functions return 25 on Christmas? Of course you wouldn't -- you'd blame the maintainers for having lost their minds.
I do deliberately try to limit what goes into my production machines, yes. I choose to trust some things, carefully, and choose not to trust others. No, I can't review everything out there. But technically, I should. And if it goes wrong and there's a problem with some code that I put on the production machine, then that's my problem.
I don't really understand why we have "reasonable expectations that maintainers of a project are reasonable people". We absolutely know for a fact that a not-insignificant percentage of our users are malicious. Why do we assume that zero percent of package maintainers are malicious?
The only qualification someone has to be a maintainer is to have written something that someone else wants to use, and to publish that thing on a package repository. Or that they volunteered to take over maintenance of a thing that other people want to use. There's nothing in there about not being malicious.
And yes, I would absolutely blame every glibc user for trusting the glibc maintainers. Glibc is a gift. I don't have any contract with the maintainers of glibc that says they have to act in my interests. I choose to use their work because it saves me time. If that stops being the case, I'll find an alternative (together with everyone else), or roll back to the last known good version of their work that they let me use. If the glibc maintainers really want to make it Christmas Day every day, then that is entirely their right. I do not have the right to demand anything from them or their code. I don't have to use their code, and they don't have to take my needs into consideration when writing it.
> And if it goes wrong and there's a problem with some code that I put on the production machine, then that's my problem.
While I understand this sentiment, it's not practically possible -- and if every business did audits of all code on their production machines (do we include firmware?) they would never get any work done or update anything. Which would lead to objectively worse outcomes (outdated/insecure software or no software developed at all) -- so there needs to be a middle-ground somewhere. In fact, you've already picked one (which is reasonable -- I think limiting dependencies is a good thing):
> I do deliberately try to limit what goes into my production machines, yes. I choose to trust some things, carefully, and choose not to trust others.
I would expect NASA/JPL to audit everything they run in production on a space telescope or shuttle. I wouldn't expect the same from the next "Uber for Dogs", nor would I think it a reasonable standard.
> I don't really understand why we have "reasonable expectations that maintainers of a project are reasonable people".
For a variety of reasons. Maintainers are public entities, so they know if anything they do is malicious they will feel immense backlash (such as is happening here over a somewhat minor issue compared to exfiltrating user data). People have pride in their work -- this is a known psychological effect -- and this is especially true in the free software world, so it's much less likely they'd sabotage something they'd put their time into. Developers that contribute to a project (likely for work or something like that) can become maintainers and thus the most motivated users usually become maintainers (and given that it takes time to become a maintainer of most large projects, doing it to sabotage the project is a long-haul gig).
> And yes, I would absolutely blame every glibc user for trusting the glibc maintainers.
I think this is far from reasonable -- you are talking about literally every single user of any program built on any Linux distribution for the past 30 years. Would you level more blame on the glibc maintainers for betraying their users in this manner? Do you blame websites for CVEs like Heartbleed -- even if they fix them as soon as they can?
> I don't have any contract with the maintainers of glibc that says they have to act in my interests.
Not a legal contract, but a social one. People who are in positions of power have an ethical duty to our society. Those who don't, don't deserve to be in such positions.
Seems to me that they’ve lost credibility by injecting these sort of ‘joke’ into open-source software used in prod in many companies. How would I use it for a new project now?
Is it known whether this was a deliberate political statement in response to recent events in China, or just a festive holiday joke intended to be harmless?
Given the current state of affairs in China, I’m inclined to believe this was political. If that’s true, many of the other comments here debating the need for professionalism in FOSS may be missing the point. It could be argued that this fits into the same category as the malicious hijacking of libraries on NPM, although I agree with the political statement being made here.
A more appropriate debate may be whether it’s acceptable for FOSS libraries to protest human and civil rights violations.
Protest all you want, but use your own productions, not others, can you tell me what would be your feeling getting a call on holidays from an angry client or a manager who might not even be celebrating Christmas?
Chinese politics? alright fair enough... but what if some of these companies got punished because of it? or lost business?
I'm Arabic, can you imagine the shit a dev will get because of this if he/she used Ant for a political figure or party website? imagine a non-christian religious organization finds their site publically celebrating Christmas?
at the end of the day, politics or not the only person that will get all the shit dumped on their head is the poor developer who trusted your product and took you as a responsible person with all the 39k GitHub stars and 692 contributors... if I can't trust that to be mature then eh... good luck reshaping the world with FOSS.
Good luck explaining dependencies to the client/manager and how "someone from outside the company can modify our precious little website" and how can you prevent that in the future lol...
Personally, I'm from Iraq, regular people won't care, but politics, religious figure, government thingy with a stupid manager etc... they will give that dev a hard time, some yelling, and might just fire him
> just a festive holiday joke intended to be harmless
Christmas in China is just a shopping holiday for the most. And no reason to make things this complicated, the author has already stated that all this is intended to be an easter egg.
There are many such frameworks including the three I mentioned. I haven't used Ant, but I've looked at it and didn't find a compelling reason to use it over the others.
"Third world" is a nonsense term that gives a completely misleading picture of global wealth distribution and helps to perpetuate negative stereotypes [0]. China's PPP GDP per capita is almost exactly the global average and higher than many Eastern European countries. They are practically the definition of a middle-income country.
How would American companies react if their website suddenly started showing messages celebrating Eid al-Fitr for no apparent reason? Would you expect them to blithely laugh it off as harmless festive high-jinks?
First and third world country refers to cold war alegiences not development status, the first world is The US and it's allies, second world is USSR and it's allies, and the rest of countries are third world.
To answer your question: if you want your project used by others, it's best not to rock the boat. Which leads me to ask why anyone would muck about with something that could affect other projects' production code?
My response to this little fiasco: why is anyone relying on externally-hosted, malleable code in a production environment? Run a repo, package it with your app ... whatever it takes to have a stable release.
Good advice. Funny thing is, from May I'm working on a big project, where we use ant extensively. We pushed the limits of almost all the available components, found several issues, enhanced it in our custom wrappers. In that time, I was going through the sources of components several times, not only of the ant itself but also through sources of react-components on which the ant is built.
YET I HAVEN'T EVER INSPECTED THE BUTTON COMPONENT. Would be super funny if I would have found that christmas egg this summer...
Now as I'm thinking about it, we have EnhancedButton, which gets 'block' boolean prop to make it full-width. I was used to that from react-bootstrap and even had the idea to open feature request on antd... In that case I would certainly open the button.tsx...
"Third-world countries" is both inaccurate and misses the point. A much better question is, should we cater to autocracies trying to suppress their citizens' religious freedom? I'd say the answer is no, whether it's China, the actual third world, or the USA or Europe. https://www.theguardian.com/world/2018/dec/24/china-cracks-d...
Snow and "ho ho ho" is hardly a religious statement. If anything, this is the capitalistic "buy lots and lots of presents" version of Christmas, not the religious version.
They overlap a lot in the West especially, but they're very different phenomena. Look at Japan, where Christmas is hugely popular, Jesus is nowhere to be seen, and a poll of schoolchildren a few years back showed that most of them thought the holiday was about celebrating the birth of Santa Claus.
For those outside the USA, I regret to inform you there is no such thing as a 'Christmas egg' and no Christmas traditions involving eggs. May I suggest you calling it a Christmas cracker?
USA did not invent Christmas, even if you are right with your statement about 'Christmas eggs', I don't see the point of remarking that you are American as if that will make you some sort of Christmas authority.
“Christmas crackers are festive gifts that make a snapping sound when opened.” For example, a Christmas cracker could contain a paper with jokes on it, a paper crown, and a puzzle where you have to disconnect two linked ring-like metal pieces.
I'm aware of the tendency to try to focus on what it seems like we can control rather than on actual justice. In this case, I'm so far only seeing outrage about the Easter Egg. I'm not seeing outrage about "They fired people over this???!!! People whose only crime was using Ant??!"
I'm not a fan of what Christmas has mostly turned into these days. I'm ambivalent about leaving a remark that could easily be wildly misinterpreted as supporting and encouraging cultural insensitivity by Americans/Westerners.
Anyway, I may seriously regret commenting at all. This seems like a can of worms for various reasons. I just dislike the idea of standing idly by while the developers get lambasted, as if they should have known ahead of time that people would be fired over this because of stuff happening in China. I'm also leery of the possibility that the other answer will be to ignore the seriousness of the situation for some people and act like "not my problem."
So there's my 2 cents.