I don't know if I've had my head under a rock, but Github's README[0] is the bigger news to me -- Are we going to finally see the end of technical posting on Medium in ~5 years? I never even knew README existed until seeing this post.
It doesn't look like an alternative to Medium to me – its a collection of posts by nominated open source developers, as opposed to a technical blogging platform
Yeah you're right -- this is very much a curated selection, but the amount of social-ish features that github has taken on lately like the customizable profile pages[0][1] suggests that they might want to occupy this space...
Adding an offering of developer blogging seems like a slam dunk if they want to continue being a fixture of developers world wide. Arguably it's not so great for other alternatives (GitLab, BitBucket, etc) and more lock-in is probably not great, even if the garden aren't locked around us right now.
I fully expect Github to go down the dangerous path of becoming a walled garden. Big companies like Microsoft just can't help themselves. Give it 10 years absolutely max. I'm going to enjoy it while it lasts, but don't expect it to last forever. Google Code, Sourceforge, etc. Been there done that. These things rise and fall constantly.
Yeah I agree, but can you blame them? They've almost single-handedly borne the cost of supporting open source in the most tangible way you can (hosting the code, supporting "remixing" and innovation) for so long. As you say, these things never last, but this is what happens when you don't have a Stallman-esque BDFL/figure involved in some product. People (myself included) might under-estimate how insane the free software movement was/is -- it just isn't normal to find something that is free and stays free.
Whether I/we can blame them or not, it does feel good that there are some other business models in the space, I personally am a huge fan of GitLab[0] (I pay for an upgrade membership though it's nothing crazy), and on the more home-brewed front there's HN darling sourcehut[1]. Honestly if I was a GitLab project manager that browses HN... I might try and shark this idea -- you already "pay" for Gitlab Pages, why not streamline it, offer a netlify-like experience on top of it and try to get there ahead of Github?
[EDIT] - the "them" in "can you blame them" is intended to be the early Github team and/or their Microsoft equivalents. People like to put out good PR releases, but selling means something. The people who sold are aware of the the risks of selling and the loss of control/vision. Along with that realization/knowledge I think it's expected for them to have felt some fatigue/been expectant of some recompense for supporting open source as much as they have over the years.
I just started posting to HashNode this week as an alternative to Medium. So far so good. Can write posts in markdown and even sync them to a git repo.
Probably a lame answer, but just general buzz about it on Twitter.
I was moving from Medium (not a fan of their paywall practices and medium.com posts tend to fare poorly on HN). Didn't know dev.to existed until after I tried out HashNode. Didn't consider self-hosted as I just couldn't be bothered.
So they're definitely in the space (I just read a fantastic rust post on there[0] today, thanks to This week in rust[1]) but you can't beat the staying power/massive bags of money/developer goodwill that is already heaped on Github. Github entering this space would be a death sentence for a site like dev.to, unless they massively fuck it up (or dev.to adapts and provides some extra value-add/integration).
imho it looks like dev.to is a cross between twitter and a full blog (seeing it for first time today). Github readme looks more like a magazine where the content is curated.
The difference between user generated content and curated content is a big enough differentiator that I don't think it'd be a death sentence.
Same! It'll be interesting to follow this and see what happens. But in the long run I think we need something distributed but also connected (like diaspora or mastodon maybe, concept wise). And as always, it'd be probably hard to establish.
True -- but I wonder if Github would be willing to do the "on your own server" bit -- they already let you host Github Pages for free, and you can bring your own RSS support.
Certainly you can have RSS-enabled blogs of Github or Gitlab. I think Netlify (also free for a single-user instance) makes it a bit easier, but isn't strictly necessary.
So I can say I've personally never read the RSS spec, but all you need is a functioning feed.xml/index.xml right? I use Hugo[0] for my statically hosted site[1] and I honestly have never even thought about it (which address is the RSS feed) much until now.
I think this battle could be won in the tooling -- if all/most of the static website tools that you'd use support RSS, you can expect that it will show up (Hugo, Gatsby, VuePress, etc).
With the (text) sources in Git so they can be easily archived, distributed and indexed for the future.
I've fired up and taken down multiple attempts at blogging, I don't know if anything I've written was worth keeping but still, the information is lost.
A great article - and lines like this really resonate with me "More than project management skills or technical expertise, empathy is the most important skill in open source."
However, the article doesn't address the most obvious question, how does Henry fund this activity?
> I currently host two podcasts studio_microphone: Hope in Source and Maintainers Anonymous.
This isn't very typical of open source creators, but for people who want to live off donations, it's a big help, because it helps building a fanbase of people, of which a subset then donates to you. Basically the same model as of a youtuber, who also creates content and uses patreon because youtube's unilateral and weird decisions to demonetize people or change their compensation on a whim.
Furthermore, it really depends on which area you work in. It seems that in the js ecosystem, it's possible to live off donations, but the js ecosystem is gigantic, and many people make money building js stuff.
IDK the people who can live off donations are an extremely tiny subset of all open source maintainers. For most people it's as unattainable as living from your proceedings of being a youtube star, and even then lots of people want to become youtube stars.
That being said, for the 99%, being in open source is still beneficial, as it opens doors into the jobs world, helps building a portfolio as well as a network, both useful for getting a job.
Exactly, I was wondering the same. In fact, about half way in I started to fast forward to find where he gives details but I never found them. This is sad, as many others considering the leap would need this cruicial information. And just talking how greatly this decision connects him to people can't really compensate..
What was also missing was if he is a 1-man WFH show, or whether they are a team with an office. I don't know Babel really, maybe it's obvious to others. But it would provide context.
I also wondered why NYC. If you are low on funds, or at least your economic base for your project is fragile, why choose such an expensive place to live? If you are WFH anyway (is he?) then some cheap place in the midwest would instantly multiply the buying power of the availabe funds. How to explain to donors that half of their donations go straight into the pockets of the landlord for an overprized tiny apartment?
True, both were mentioned in passing - but it would be good to hear about how sustainable this is?
If an open source maintainer relies on GH sponsors, Patreon, Open Collective then they are going to have to invest time in marketing themselves to the community. It's an odd dynamic.
The main problem with emojis (usage of them aside) is that while they are characters, they do not work in the same way as other characters. Smileys are composed of symbols right at your fingertips. Native emoji keyboards are severely lacking - typing them is a lot different than text. The worst part is that while fonts exist since forever, the emoji generation forgot all the engineering put into it and no font tooling works with emojis. Whatever font setup you have, it goes down the drain once emojis are in the text, because emoji glyphs come not from your font setup, but from within the rendering application.
I'm not sure what you mean by "emojis come from the rendering application". Some applications (particularly web applications) forcibly replace emoji characters with inline images because they don't trust every user-agent to have a sufficiently-complete emoji font installed, or because they want to use their own custom emoji designs rather than the platform-native ones. That's not a fault of emojis or the font setup, though - that's just paranoid developers.
Most UI toolkits will render emoji characters according to whatever emoji font you have installed, just like they'll render Cyrillic characters according to whatever Cyrillic font you have.
I'm not sure if you imply that the emoji glyphs are not from a font, because they usually are. To display emojis well, you should have your normal font setup, plus one font for emojis (like [Noto-Emoji]. All desktop applications I use display these glyphs and don't interfere with it. The only example of something overriding your selected font is Slack, which uses small images if it knows the emoji.
At least, that is true on my Linux. What Windows does, I have no idea.
Here's a question I've vaguely wondered but never mustered the effort to actually look up: how does IRC work? Like, if two people want to talk to each other over IRC, do they need to be connected to the same same IRC server at the same time?
If so, does that mean that IRC is basically like instant messaging along the lines of AOL Instant Messanger, or Google chat? Or is there something that makes IRC very different?
IRC at its core is really simple: there's a server that relays messages between currently connected clients (i.e.: the server does not store messages ever).
To whom does each message get sent? This is where channels come in: a "channel" is just a list of currently connected people, and the server relays every message sent to the channel to all the people who's in it.
You can also open "private consversations" (i.e.: channels between only you and another person in the server).
From this very simple model, new features where added over time. Most notably:
- Very early on people realized that trolls are annoying. So... whenever a chanel is created, the first person to join gets "operator" status and can kick other people from the channel, silence them, etc. They can also make other people operators.
- Some severs are federated to form an "IRC Network" (like freenet). These servers are relaying messages between them. For end-clients, it should not matter to which of the servers in the network you are connected to. Federation only works between servers on the same network (there's no federation between networks!).
- Some networks created a small layer of authentication. You can "register" your nickname so the network won't allow other people to use it. Furthermore, you can "register" channels so when they get created the first person to enter doesn't get operator status. The network will only grant such status on that channel to whatever (registered) nicknames you specify, etc.
On this basis, people started creating bots to:
- Build archives of conversations (remember that all of this is ephemeral!)
- Auto-reply to certain "messages" in certain channels.
- Whatever else crosses your mind it has probably been done at some point. IRC is old ;)
You have it backwards. AOL-brand Instant Messaging and Google-brand Chat are like IRC, only in the latter cases commercial interests recognized the value in IRC and built walls around the commons in an attempt to extract rent.
For standalone IRC servers, yes. But many IRC servers are collected together into networks (Undernet, Freenode, EFnet, and so on) and in that case all you need to be is in the same channel on the same network.
IRC is "very different" in the sense that it's more open and more freewheeling than, say, Slack. Slack is basically IRC with a slicker coat of paint and more monetization.
Never tried Slack, so that comparison doesn't help too much :)
But I think I'm getting the idea now. It's a similar idea to a typical instant messenger, except that since the protocol is standard, you have federation that actually works, much like someone who uses gmail can email someone else who uses yahoo.
Plus you have the concept of a channel, which seems to have no direct analog in a typical instant messenger, but seems to be essentially a persistent chatroom that doesn't vanish even if nobody is in the channel at the moment.
Most of IRC is on those 'channels' (#whatever). and most channels (at least back in the day) were public, so you could just go to #books or whatever. For example, I spent my formative years on #uiuc, where there was a healthy community of 50-100 people from the university I was at. Newcomers would stop by on a regular basis and ask a question or just start chatting or troll or even grief--there were kickbans and scripts and bots to help manage larger communities.
Also these persistent channels are created just by joining the channel with that name; they disappear when the last person leaves. Notably, the first person to join a chatroom gets "operator" status, and thus the rights to change channel settings and kick/ban people etc. So there evolved a culture of bots, who would sit in channels with op status and 'occupy' it in case someone came along; these bots had op status themselves, and were programmed to auto-ban certain users or even domains, and auto-op their owners and their owners' friends. slap me summa dat +o.
And of course, there were the bot wars and the attempts at deliberate netsplits to try and steal op status, which were fun games for the script kiddies, but would really take the piss out of your evening chat when they would come by.
Fun fact: slap was a client command that just sent "action" over the channel/privmsg, which would get rendered as something like:
* <nick> <action text>
More generally, on most clients you could use "/me <text" command to do the same thing. And on the protocol level, it was done by a mini-protocol on top of IRC, called DCC (direct client-connection), that would look like:
PRIVMSG #channel :^AACTION text^A
(where "PRIVMSG #channel :text" was a way to send a normal message, and ^A is Ctrl-A).
DCC was also used as signalling for file transfer. Clients wishing to send files would open a high-end port on their machine and send a DCC message with the file name, IP and port to connect to (similar to active FTP).
(yes, I spent an inordinate amount on time on IRC...)
Fun fact indeed! I knew all these things but never how they actually worked. When I was deep into IRC I was a bit too young to understand the technical side of it but I sure knew how to download a lot of warez over DCC!
As far as typical user-experience goes, you shouldn't think of IRC as "an instant messenger with channels as a kind of extra thing on the side". The public multiple-participants ongoing conversations in channels are the primary thing an IRC user is involved in. Direct private messages to a single other user are the extra-thing-on-the-side.
Yes, typically all your communications on IRC go through a server.
But depending on your client, and server, there's a lot of room for extensions around the native features.
For instance, you can use DCC to send messages directly to an other user
[0]: https://github.com/readme