I looked because I was curious, and on both desktop and mobile, in all browsers, the site's topnav includes their Mozilla logo, a Download Firefox button, and links to a couple of other Mozilla sites about Internet Health and Donate.
I imagine they could still choose to hide the blue button when you're on Firefox, but that wouldn't save you any vertical space, since the topnav menu of links and logo would remain.
EMACS was developed on ITS, a multi user timesharing operating system with no security. I developed a complex init file (in TECO of course) which was a compiled module in my home directory.
One day I changed something in an incompatible way and received complaints. Unbeknownst to me there was a community of people who linked (symlinked) directly to my init file and whose workflows were disrupted by my change.
Were there any interesting consequences? Like did you consequently avoid making disrupting changes to your own init file, or did people agree to make copies instead of rely on links?
It can be (consider that some Emacs power-users used to do most things in Emacs, including email, Usenet, etc.), but this reminded me of something...
Many years ago, some new founder I knew asked to see my elaborate .emacs file. I was reluctant, because it had some slightly sensitive info in it , as well as unreleased bits I might turn into packages. But he reassured me he just wanted to see how I'd done some things, to inform some non-Emacs thing he was about to build, and he'd keep it private.
Sometime later, one of the developers at his startup happened to mention that "everyone" uses my .emacs file.
Today, that person I let see my very personal .emacs has sold the original startup, and is CEO of a different business you've heard of, but I received nothing from the indiscretion. :)
> (consider that some Emacs power-users used to do most things in Emacs, including email, Usenet, etc.)
We still do. Consider that I have coordinates for weather in my .emacs, and yes, I should probably externalize that, but FFS, sharing my own incredibly personalized and personal configuration files was not first on my mind when I did that.
You want snippets, that will be useful to someone other than me? Fine. But there's no contradiction in arguing for openness in infrastructure and privacy in personal affairs.
Wow, send a bill to the company and ask them to renew their site license for the emacs config. Or opensource what you can of it and remove the competitive advantage they have.
As much as I'm a fan of Emacs, I don't think a .emacs file had much to do with that startup's success. He just wanted to see the UX and features that were possible for a particular purpose, for ideas and competitive analysis. But I did opensource a minority of the bits. :) https://www.neilvandyke.org/emacs/
Totally believeable. I had one research prototype that invoked an Emacs process for every Web CGI request. To get that kind of R&D rapid development productivity, I then had to start building out libraries for Scheme. :)
I simply separate user/machine specific things into separate files, and don’t commit them to public repository (https://github.com/alexott/emacs-configs - it wasn’t updated for a long time, and it needs to be rewritten to modern stuff - first line was written 25 years ago)... But this may allow sharing, and even contributions...
I take advantage of the fact that a .emacs file has higher precedence than a .emacs.d/init.el file for this. All the common stuff lives in the .emacs.d directory and is under source control. The little bit of work/machine specific stuff I have goes in the .emacs file, which wraps a
(load "~/.emacs.d/init")
My home machines don't need anything special, so there's no .emacs file and the .emacs.d/init.el file just gets loaded directly.
India has had vegetarian burgers for years, in fact, most people order these veg burgers because they don't eat meat ( culture / religion ). Ive never eaten meat, but I really love burgers.
The UI is somewhat confusing; also, it seems designed to give a view of particular, selected streams and topics of interest, and doesn't always seem to keep up even with those -- but volume on my server is low enough that I want "all messages", and if there's UI which does that reliably... it's not signposted well enough for me to find it before my patience ran out.
Apart from a user, I am also a contributor to the Zulip project, for the last ~7 months.
The community is very helpful and for getting started with open source development, I can't recommend a better place. You get really high quality code reviews, get to participate in meaningful discussions on features and the development goals of the project, and developers constantly share lots of knowledge in streams like #learning about software development, tech, git, best practices and so on.
Also, the documentation is very detailed and the codebase is very high quality. It's really easy to get started.
One of our goals as a project is to have a "teaching-quality" codebase, so this is no surprise. I think this is incredibly important and something every community open source project should strive for.
An analogy I like to use is to think about the experience of contributing to your open source project as a product, so you should:
* Do usability studies where you help a group of people try to get started with your product (I used to do this all the time at events like Python conference sprints pre-pandemic). The first few we did were eye-opening as nobody got anywhere without a lot of handholding, and I suspect that's common.
* Make the development environment tooling Just Work and have a good support experience.
* Write good documentation that thoughtfully explains the ideas one needs to understand to participate on your project. My strategy for this was to avoid explaining how things work to a contributor, and instead meet the need by spending a couple hours writing something like https://zulip.readthedocs.io/en/latest/subsystems/sending-me... and send it to them. That way, even if that contributor bounces (as the vast majority of new people who show up to any volunteer organization do), I still used my time well.
I'm planning a series of blog posts on building a successful open source community, since we've spent a lot of time thinking about how to make contributing to Zulip a great experience, and some ideas are subtle (E.g. the secret to being able to give high quality code reviews is equipping new contributors with the tooling and documentation to help them avoid problems before a reviewer even looks at it!), and I regret not having spent more time sharing that thinking.
Thanks for you comment with interesting points. It’s quite different from the perspective of “scratching an itch” open source code. I look forward to your posts on nurturing open source communities.
As a fellow Zulip user and minor contributor, I wholeheartedly agree.
In addition to coordinating development teams on three continents, we also use Zulip as an integration hub. git commits go in the #commits channel, jenkins build status to #builds, and run-time errors to #errors.
We use errbit (API-compatible Airbrake clone) for error reporting and Zulip didn't have an errbit integration.
So I wrote one, and they integrated it within a few days. The Zulip team was super-responsive and easy to work with. It certainly helped that they had excellent docs on how to write integrations, and tons of examples.
Based on my simple analytics that looks at the time between a contributors first and last commit, I'm getting 50 active contributors, which matches up with many of the other popular open source projects I've indexed.
Also, that's just the server project. There are also clients like the mobile app and the terminal app, which have a whole new set of active contributors.
On the other hand, when it comes to WinRAR, the majority of people use it not because of its unique features (like the RAR format) but because it's considered the mainstream archiving software and they don't know any better.
WinRAR isn't losing much sales because it's easy to use without paying; if it was harder to use without a license, people would simply use alternatives such as 7-Zip and it would become the mainstream archiving software and WinRAR wouldn't have the brand awareness they have now. I'm assuming RarLab knows this because otherwise they would've patched the loophole long ago.
