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.
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.Disabling it is easy enough but I have other things to do.
(Note that I don't necessarily agree with this but it's an obvious path.)
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.
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.
That's a fair angle :)
https://blog.mozilla.org/firefox/easter-eggs-come-from-foxes...
Which is what? "Untrustworthy, avoid"?
Sometimes things will work out for you, sometimes it means exactly what it says on the tin: "I don't promise this works"
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 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!
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.
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.
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.
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.
Because that doesn't sound like having fun to me, that sounds like you're trying to create controversy.
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.
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).
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 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.