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.
