Kyoto project is moving from GitHub to Sourcehut(github.com)
github.com
Kyoto project is moving from GitHub to Sourcehut
https://github.com/kyoto-framework/kyoto
26 comments
> Why support Github when there is st.ht?
I’m not super opposed, but Drew can be pretty over the top ideological/irritable for my tastes (at least that’s my perception from reading his blog). I’m not sure I want to invest in his platform if he could just boot me over an Internet disagreement or something. Yeah, I can back up my stuff, but at a certain point I may as well self-host.
I’m not super opposed, but Drew can be pretty over the top ideological/irritable for my tastes (at least that’s my perception from reading his blog). I’m not sure I want to invest in his platform if he could just boot me over an Internet disagreement or something. Yeah, I can back up my stuff, but at a certain point I may as well self-host.
In the history of SourceHut, only one person (setting aside spam/crypto-miner bots) has been banned from the platform. They were harassing maintainers and failed to respond to an email inquiry seeking to discuss their behavior before resorting to a ban.
I have strong principles and I stand steadfast by them. However, one of those principles is tolerance for different views. I want SourceHut to be available for everyone, even if we don't see eye-to-eye. You won't be booted off if you and I happen to end up in an argument somewhere online.
I've made myself personally available to users, as a person they can directly reach about problems and concerns with the services, rather than a support ticket answered by a random lackey. I think this is very valuable. Software is made by people. One of the risks that comes with this, however, is that people can start to view SourceHut and my private identity tangled together. Rest assured, they are separate, and I treat SourceHut with a great deal of deliberate professionalism and reverence for our users.
I have strong principles and I stand steadfast by them. However, one of those principles is tolerance for different views. I want SourceHut to be available for everyone, even if we don't see eye-to-eye. You won't be booted off if you and I happen to end up in an argument somewhere online.
I've made myself personally available to users, as a person they can directly reach about problems and concerns with the services, rather than a support ticket answered by a random lackey. I think this is very valuable. Software is made by people. One of the risks that comes with this, however, is that people can start to view SourceHut and my private identity tangled together. Rest assured, they are separate, and I treat SourceHut with a great deal of deliberate professionalism and reverence for our users.
Wondering if SourceHut has a code of conduct, I found its Terms of Service > Permissible Use: https://man.sr.ht/terms.md#permissible-use
Nicely done.
About banning... thinking out loud...
I wonder if a public ban log would reduce food fights. Nothing too fancy. Maybe just date, account name, cite terms violated, optionally cite evidence, admin actions taken. No need for comments, discussion, whatever.
Then whenever the peanut gallery starts concern trolling, you can just link to the ban log entry. Instead of explaining yourself, yet again.
Nicely done.
About banning... thinking out loud...
I wonder if a public ban log would reduce food fights. Nothing too fancy. Maybe just date, account name, cite terms violated, optionally cite evidence, admin actions taken. No need for comments, discussion, whatever.
Then whenever the peanut gallery starts concern trolling, you can just link to the ban log entry. Instead of explaining yourself, yet again.
Maybe. Even if someone is banned, I still care about their privacy, and I would not want to disclose that they were banned. Providing this information also provides useful feedback to malicious actors like spammers, who are ordinarily banned in a means which makes it difficult for them to tell when an account is burned.
SourceHut is not a social network and does not have particularly arduous moderation needs. It's vanishingly rare for us to ban someone at all for this reason. We additionally provide banned users with a complete data export and tools to re-import that data into other SourceHut instances or instances using compatible software, so they are not left without options.
If someone feels slighted by moderation on SourceHut, I would invite them to speak publicly about it. I'm prepared to justify our actions in the court of public opinion with consent from the maligned.
SourceHut is not a social network and does not have particularly arduous moderation needs. It's vanishingly rare for us to ban someone at all for this reason. We additionally provide banned users with a complete data export and tools to re-import that data into other SourceHut instances or instances using compatible software, so they are not left without options.
If someone feels slighted by moderation on SourceHut, I would invite them to speak publicly about it. I'm prepared to justify our actions in the court of public opinion with consent from the maligned.
[deleted]
Well said.
I at one point encountered Drew at a meetup.
He basically ignores anyone who has or currently does work at any company he deems unethical (read: Google/Amazon/Facebook/etc). You're forever tainted in his eyes, and your opinions are always only useful if someone else agrees with you that isn't tainted.
Which really sucks because his entire software stack depends on the work (and opinions) of the people that he discards: Go, Python, and Git for a few.
He basically ignores anyone who has or currently does work at any company he deems unethical (read: Google/Amazon/Facebook/etc). You're forever tainted in his eyes, and your opinions are always only useful if someone else agrees with you that isn't tainted.
Which really sucks because his entire software stack depends on the work (and opinions) of the people that he discards: Go, Python, and Git for a few.
But is he right? At what point is it unethical for an ethical person to continue to work for an unethical company? When should people who work for an unethical face personal negative effects?
He's not unique in this viewpoint. Quoting jwz: "As I've said before, if you work for Facebook, you should quit; it's the only morally defensible thing for you to do."
> his entire software stack depends ...
That sounds like the Mr. Gotcha meme: https://thenib.com/mister-gotcha/ . Again referring to jwz, his nightclub is on Facebook and Instagram because it's not economically viable to avoid them. ... Gotcha!
Similarly, it's hard to avoid all software which doesn't have influence from the big tech companies. I used https://github.com/swenson/sort ('Sorting routine implementations in "template" C"), and even this little indy package has contributors from Google Inc and the main developer worked at Google for a year.
DeVault's working on a new programming language, Hare. You could view that as having the long-term unstated goal of escaping unethical companies.
He's not unique in this viewpoint. Quoting jwz: "As I've said before, if you work for Facebook, you should quit; it's the only morally defensible thing for you to do."
> his entire software stack depends ...
That sounds like the Mr. Gotcha meme: https://thenib.com/mister-gotcha/ . Again referring to jwz, his nightclub is on Facebook and Instagram because it's not economically viable to avoid them. ... Gotcha!
Similarly, it's hard to avoid all software which doesn't have influence from the big tech companies. I used https://github.com/swenson/sort ('Sorting routine implementations in "template" C"), and even this little indy package has contributors from Google Inc and the main developer worked at Google for a year.
DeVault's working on a new programming language, Hare. You could view that as having the long-term unstated goal of escaping unethical companies.
I think the other comment was right to call them out on hypocrisy. There really are people out there who put their beliefs before their own comfort and even productivity (see: Richard Stallman). Now, that doesn't make them right, but if you're going to defend an opinion, you may as well go all the way. Personally, seeing petty behavior like this doesn't exactly fill me with confidence for whatever product they maintain. I wish I could get paid to maintain random OSS projects too, but the lights gotta stay on and $3 GitHub donations only take you so far. There's nothing evil about working at a company like Facebook unless you're an evil person.
I only gave source hut as an example. Maybe there are other projects like source hut that you might like, but are not ethically challenged like GitHub, that you might support?
The larger point still stands though. Instead of consumers simply supporting the biggest players in the market (because of convenience), it would be nice to give smaller players (who are not shady) a chance?
The larger point still stands though. Instead of consumers simply supporting the biggest players in the market (because of convenience), it would be nice to give smaller players (who are not shady) a chance?
> I’m not sure I want to invest in his platform if he could just boot me over an Internet disagreement or something.
There's a wide gap between being irritable and being unprofessional. Nothing I've seen so far in regards to how SourceHut is being managed, indicate that you'd have such problems. (I'm saying this as a long time user of SoutrceHut and as someone that got into arguments with Drew)
There's a wide gap between being irritable and being unprofessional. Nothing I've seen so far in regards to how SourceHut is being managed, indicate that you'd have such problems. (I'm saying this as a long time user of SoutrceHut and as someone that got into arguments with Drew)
> I’m not sure I want to invest in his platform if he could just boot me over an Internet disagreement or something.
Has that happened?
Has that happened?
Self hosting is OK. I self host my personal projects and a few work ones (the ones with a customer that basically doesn't know what code is.) I usually don't want anyone else to look at them though. I let some friends work with me on some of them. If I need strangers or customers to look / work at the code it's been GitHub, GitLab or Bitbucket.
> I’m not sure I want to invest in his platform if he could just boot me over an Internet disagreement or something.
But the FAANGs do that to people all the time.
But the FAANGs do that to people all the time.
That's not a reason to use a small, independent platform with a capricious project leader, though[0]. That's just an argument to use neither.
[0] (I have no idea if Drew DeVault would actually boot someone off his platform for arbitrary reasons, though. I'd hope that's not the case.)
[0] (I have no idea if Drew DeVault would actually boot someone off his platform for arbitrary reasons, though. I'd hope that's not the case.)
[deleted]
The iPhone App Store terms still conflicts with the GPL, right?
If so, isn't that also "over the top ideological"? After all, we know Apple's opposition to the GPL dates back to the early 1990s when NeXT used gcc for Objective C, and their rejection of GPLv3 caused them to ship ancient versions of bash, recently replaced with zsh, so it's not like they weren't aware of the GPL.
Some people use Linux (the moral equivalent to "self-host") to avoid Apple's ideological stance.
Which, from a business standpoint, makes for a marketing opportunity for a FOSS-aligned source code hosting company. Which takes us from an ideological position to an economics one.
(To quote Bill Hicks: “Oh, you know what Bill’s doing? He’s going for that anti-marketing dollar. That’s a good market. He’s very smart.”)
If so, isn't that also "over the top ideological"? After all, we know Apple's opposition to the GPL dates back to the early 1990s when NeXT used gcc for Objective C, and their rejection of GPLv3 caused them to ship ancient versions of bash, recently replaced with zsh, so it's not like they weren't aware of the GPL.
Some people use Linux (the moral equivalent to "self-host") to avoid Apple's ideological stance.
Which, from a business standpoint, makes for a marketing opportunity for a FOSS-aligned source code hosting company. Which takes us from an ideological position to an economics one.
(To quote Bill Hicks: “Oh, you know what Bill’s doing? He’s going for that anti-marketing dollar. That’s a good market. He’s very smart.”)
Last time I checked, sr.ht was mostly an email based workflow, and many teams wanted an issue tracking system that is web based
SourceHut offers an email-based workflow with a web application built on top of it. You can file tickets via email, but you can also file tickets on the web:
https://todo.sr.ht/~sircmpwn/hare
The same goes for patches. You can submit changes directly via email, but you can also use our web interface. We're also working on web-based tools for code review built on top of our mailing lists, which will provide a complete experience similar to GitHub's pull requests, but built on top of the decentralized, standardized protocol that git was designed for.
https://todo.sr.ht/~sircmpwn/hare
The same goes for patches. You can submit changes directly via email, but you can also use our web interface. We're also working on web-based tools for code review built on top of our mailing lists, which will provide a complete experience similar to GitHub's pull requests, but built on top of the decentralized, standardized protocol that git was designed for.
Hello, kinda offtopic, but are there plans for ForgeFed / ActivityPub support?
That really seems the best way to dethrone GitHub, as it's moat is mainly carved via a social network.
The git repo is already decentralized, ForgeFed is a great way to integrate and decentralize the social part.
In the future gitea, srht, and many other implementations could interact with each other's users.
That really seems the best way to dethrone GitHub, as it's moat is mainly carved via a social network.
The git repo is already decentralized, ForgeFed is a great way to integrate and decentralize the social part.
In the future gitea, srht, and many other implementations could interact with each other's users.
No, not at this time. I don't think that ActivityPub is the correct way to address this issue -- some people treat it like a golden hammer.
SourceHut is already federated: via email. Email is a standardized, federated protocol with thousands of implementations and a global fault-tolerant system already working in production for decades, and it's the approach git was designed to use. I think this is a better solution. You can already use SourceHut's tooling to contribute to projects like Linux, which don't use any forge software at all, thanks to this standardization.
SourceHut is already federated: via email. Email is a standardized, federated protocol with thousands of implementations and a global fault-tolerant system already working in production for decades, and it's the approach git was designed to use. I think this is a better solution. You can already use SourceHut's tooling to contribute to projects like Linux, which don't use any forge software at all, thanks to this standardization.
That's unfortunate. It's pretty difficult to run your own email server plus deal with the blacklisting. I see your points, but I also see a possibility to support both email and ActivityPub mediums. A lot of people want a dedicated interface, hence you having to make a web portal. I don't see why the web portal couldn't support ForgeFed in addition to email.
Being able to bridge standalone gitea instances users with repos on your service would be a good step forward for federation.
Being able to bridge standalone gitea instances users with repos on your service would be a good step forward for federation.
ForgeFed is just a protocol, just like email. The interfaces can be essentially identical.
It's pretty difficult to host a fediverse server, too. I want to make SourceHut easier to self-host post-beta, including dealing with email bits, but I also don't think the dream of federation involves everyone running their own servers. One of the advantages of the federation model is that it strikes a balance between total centralization and total de-centralization in that it allows a talented sysadmin to provide services for a large number of users. There are more ways to federate than ActivityPub.
It's pretty difficult to host a fediverse server, too. I want to make SourceHut easier to self-host post-beta, including dealing with email bits, but I also don't think the dream of federation involves everyone running their own servers. One of the advantages of the federation model is that it strikes a balance between total centralization and total de-centralization in that it allows a talented sysadmin to provide services for a large number of users. There are more ways to federate than ActivityPub.
Exactly my point. You could support both ActivityPub and email as protocols. I believe even commits could contain either address as it's a similar format.
As far as hosting difficulty goes, once Gitea supports ForgeFed, you'd be able to spin up your own instance as easy as running one program, and no worries about blacklisting.
I agree not everyone needs their own server, which is where shines sr.ht over Gitea, but a community developing a product sometimes wishes to run their own servers for their users. Sure they could run an email server, and users could use that, but it seems roundabout and outdated.
I agree there's more than one way to federate, but the goal is bridging everyone together. Those two aren't mutually exclusive if you support both protocols.
As far as hosting difficulty goes, once Gitea supports ForgeFed, you'd be able to spin up your own instance as easy as running one program, and no worries about blacklisting.
I agree not everyone needs their own server, which is where shines sr.ht over Gitea, but a community developing a product sometimes wishes to run their own servers for their users. Sure they could run an email server, and users could use that, but it seems roundabout and outdated.
I agree there's more than one way to federate, but the goal is bridging everyone together. Those two aren't mutually exclusive if you support both protocols.
Sorry, but I think we have to agree to disagree.
It sounds like you want to volunteer to add ActivityPub to Sourcehut!
Is the part that would allow this in sourcehut opensource & allowing contributions for this?
From the sounds of things he does not want the feature.
From the sounds of things he does not want the feature.
And that's the caveat with SourceHut and the current discussion around it. While I respect Drew and his work, he isn't exactly the most approachable person in OSS.
If you and several other people happen to have a hard requirement for a specific feature that he (or his buddy Simon) don't see fit for, you won't get that feature, even if you volunteer to implement and maintain it. The only thing you're left with is basically to fork SourceHut, host it yourself and maintain your feature all by yourself, dealing with continuously patching a very much still-in-development (and therefore ever changing) software. That is something you're probably not going to do, especially considering SourceHut's architecture and way of doing things.
SourceHut isn't exactly extensible/pluggable and hosting it as a one man show or even a small company becomes a huge PITA, as soon as you diverge from the holy grail that is Drew's way of doing things (Alpine, no containers, no good config management, no easy way to scale things, and the dedication to invest your blood and tears into maintaining this thing).
Hence I really cannot comprehend the current trend that is "let's all dump GitHub for this, and that, and SourceHut". So far, SourceHut really hasn't made an effort to prove itself worthy of the influx of OSS projects. And while I do see Drew commenting here, reassuring folks he won't ban anyone over any internet disagreement, reading the public mailing lists of the SourceHut repos doesn't really show much of a welcoming behavior either. I mean, he's the person behind what has become one of the most popular Gemini servers, and as soon as that was the case, he began threatening client apps to arbitrary block them for doing things that don't align with his values (in this case, [showing a favicon](https://github.com/makeworld-the-better-one/amfora/issues/19...)). And the cabal of elite internet Amish, that have been on SourceHut since its early days and that makes a large portion of the platform, aren't that different either.
I do agree with GitHub being the wrong place for OSS projects, but I don't agree with SourceHut being the right one. At least for as long as it doesn't become obvious that its founder and the community around him has changed and started to genuinely appreciate people for the work they're doing, regardless of their own ideological beliefs.
If you and several other people happen to have a hard requirement for a specific feature that he (or his buddy Simon) don't see fit for, you won't get that feature, even if you volunteer to implement and maintain it. The only thing you're left with is basically to fork SourceHut, host it yourself and maintain your feature all by yourself, dealing with continuously patching a very much still-in-development (and therefore ever changing) software. That is something you're probably not going to do, especially considering SourceHut's architecture and way of doing things.
SourceHut isn't exactly extensible/pluggable and hosting it as a one man show or even a small company becomes a huge PITA, as soon as you diverge from the holy grail that is Drew's way of doing things (Alpine, no containers, no good config management, no easy way to scale things, and the dedication to invest your blood and tears into maintaining this thing).
Hence I really cannot comprehend the current trend that is "let's all dump GitHub for this, and that, and SourceHut". So far, SourceHut really hasn't made an effort to prove itself worthy of the influx of OSS projects. And while I do see Drew commenting here, reassuring folks he won't ban anyone over any internet disagreement, reading the public mailing lists of the SourceHut repos doesn't really show much of a welcoming behavior either. I mean, he's the person behind what has become one of the most popular Gemini servers, and as soon as that was the case, he began threatening client apps to arbitrary block them for doing things that don't align with his values (in this case, [showing a favicon](https://github.com/makeworld-the-better-one/amfora/issues/19...)). And the cabal of elite internet Amish, that have been on SourceHut since its early days and that makes a large portion of the platform, aren't that different either.
I do agree with GitHub being the wrong place for OSS projects, but I don't agree with SourceHut being the right one. At least for as long as it doesn't become obvious that its founder and the community around him has changed and started to genuinely appreciate people for the work they're doing, regardless of their own ideological beliefs.
I see Drew already weight in on this, but there were a number of debates between ActivityPub proponents (of which I am one, though not in the source forge space) and him regarding this, where he was very explicit that he's not interested. Over time I ended up coming more to his side, and I agree that SourceHut doesn't need any extra social interaction that ActivityPub might bring.
That being said, the devs of Gitea are in the process of adding AP support, and it has been mentioned on HN already: https://news.ycombinator.com/item?id=31934758
That being said, the devs of Gitea are in the process of adding AP support, and it has been mentioned on HN already: https://news.ycombinator.com/item?id=31934758
I'm aware, part of my assertion was to bridge Gitea and Sourcehut projects together via AP, I go into detail in my other replies.
I understand and support his decision, but I will be going with Gitea because I'd prefer AP networking over email. To each their own for sure, but my main suggestion was to support both so the communities aren't fragmented, that would be a bigger threat to Github's network effect. Oh well.
I understand and support his decision, but I will be going with Gitea because I'd prefer AP networking over email. To each their own for sure, but my main suggestion was to support both so the communities aren't fragmented, that would be a bigger threat to Github's network effect. Oh well.
Thanks Drew. I may have been mistaken, or perhaps you added those features after I tried them.
I'll take another look.
I'll take another look.
That is why I said "wherever possible". If your team is going to quit their jobs (I doubt it) because they will only deal with a web based issue tracking, then sure, go for GitHub.
The point I am trying to make here is - by default people spend their money with mega corps, because of brand awareness, convenience etc. Instead, it would be nice if the default is indie/small businesses.
In other words instead of "the mega corps aren't working for me, let me look for smaller/indie options instead", it would be nice if we all did "smaller indie options don't fit my requirements, let me go with Microsoft/Apple/etc instead".
Maybe this is too idealistic?
The point I am trying to make here is - by default people spend their money with mega corps, because of brand awareness, convenience etc. Instead, it would be nice if the default is indie/small businesses.
In other words instead of "the mega corps aren't working for me, let me look for smaller/indie options instead", it would be nice if we all did "smaller indie options don't fit my requirements, let me go with Microsoft/Apple/etc instead".
Maybe this is too idealistic?
There is usually a reason those mega corporations became mega corporations. GitHub, in particular, is the easiest way to collaborate for most developers and they were the first one to get most things right. Absolutely vote with your wallet. If you want to support smaller companies, then do that. But realistically GitHub will be the default option until something comes along that is better. And whatever replaces Github has to be significantly better to justify the switching cost for majority of developers.
At such point it will probably become a large corporation that people will consider ethically challenged.
> If your team is going to quit their jobs (I doubt it) because they will only deal with a web based issue tracking, then sure, go for GitHub.
No but they will quit because an ideology most members of most teams was used to justify a decision that affected their work.
No but they will quit because an ideology most members of most teams was used to justify a decision that affected their work.
Maybe also too optimistic as well.
Let me start by telling you a story about me trying to buy clothes for the first time:
Back then, I have no idea of branding and the symbolism behind, I don't even have the idea of quality.
After many hours of browsing and comparing, I picked what I liked based on showcase pictures and user reviews, completely brand-blindly.
A week later when they arrived, I quickly discovered that few of them are false advertisments, some of them are in the wrong size and one got damaged during shipping. And for the rest items that were "just right", half of them ripped/deformed after half-year of use.
So, as a normal person would do, I created a table which consist of factors such as durability, price and styles etc to help me increase my "success rate". And after few years of iteration, that table ended up points me to just few brands that happens to be well-known and big.
I eventually settled on those brands with membership cards etc, and now whenever I need new clothes, I open their store page.
What I learned from my experience is that discovery itself generates cost, and the cost is nonrefundable. It is reasonable for an user to settle on a trusted brand. It's not brand loyalty, it's just rational decision making.
For most users, choose GitHub is rational, because it's the most trusted platform out there, and it provides good services (including the infrastructures and socials). You already knew what to expect before you even sign on, that's the level of trust GitHub delivers.
It's really hard to ask users to discover and move to the alternatives once their needs are well-fulfilled by the current one, even when the alternative provides the same level of service.
What makes it even harder is that services such as BitBucket, GitLab, SourceHut, Gitea etc can't provide the same level of service that GitHub offers for free. At this circumstances, the megacorp such as GitHub will always win even when the user is pro-indies by default.
But we are not completely dead in the water here. GitHub succeed because they created something new at the time, something better than what SourceForge offered.
I assume if someone wants to beat GitHub, they need to do the same. Don't just create alternatives, create something new that also does old things better.
Let me start by telling you a story about me trying to buy clothes for the first time:
Back then, I have no idea of branding and the symbolism behind, I don't even have the idea of quality.
After many hours of browsing and comparing, I picked what I liked based on showcase pictures and user reviews, completely brand-blindly.
A week later when they arrived, I quickly discovered that few of them are false advertisments, some of them are in the wrong size and one got damaged during shipping. And for the rest items that were "just right", half of them ripped/deformed after half-year of use.
So, as a normal person would do, I created a table which consist of factors such as durability, price and styles etc to help me increase my "success rate". And after few years of iteration, that table ended up points me to just few brands that happens to be well-known and big.
I eventually settled on those brands with membership cards etc, and now whenever I need new clothes, I open their store page.
What I learned from my experience is that discovery itself generates cost, and the cost is nonrefundable. It is reasonable for an user to settle on a trusted brand. It's not brand loyalty, it's just rational decision making.
For most users, choose GitHub is rational, because it's the most trusted platform out there, and it provides good services (including the infrastructures and socials). You already knew what to expect before you even sign on, that's the level of trust GitHub delivers.
It's really hard to ask users to discover and move to the alternatives once their needs are well-fulfilled by the current one, even when the alternative provides the same level of service.
What makes it even harder is that services such as BitBucket, GitLab, SourceHut, Gitea etc can't provide the same level of service that GitHub offers for free. At this circumstances, the megacorp such as GitHub will always win even when the user is pro-indies by default.
But we are not completely dead in the water here. GitHub succeed because they created something new at the time, something better than what SourceForge offered.
I assume if someone wants to beat GitHub, they need to do the same. Don't just create alternatives, create something new that also does old things better.
Let me point out that if you go buying clothes in a physical shop you can easily assess a large part of the quality of the clothes and you have no problems with shipping. This has a cost though and it doesn't solve the discovery part happening when you clean them (shrink, discoloration etc.) I think I never bought clothes online so far.
Email is still the most robust communication medium. But I have also observed that it has also prevented emoji-only replies which is great.
Standard but not robust. In fact it can silently fail.
Email is very robust and does not fail silently -- unless you ignore the "undelivered returned to sender" emails you get. Mail servers are very fault tolerant, with essentially all implementations supporting an exponential backoff on failure. What's more, even if SourceHut is down, everyone in the Cc will still receive your emails, because they're routed around lists.sr.ht anyway. In the event of a lists.sr.ht outage, you might not even notice that we're down.
Unfortunately some of the larger mail providers will "accept" mail they don't like, but then blackhole it.
Yes, you can say "well, your intended recipients shouldn't use mail providers that do that", but in reality that's not our choice.
Yes, you can say "well, your intended recipients shouldn't use mail providers that do that", but in reality that's not our choice.
That's unfortunately just not true. It does, and has, failed silently.
I've had Google silently swallow emails before, both sending and receiving. It's not fun.
I've had Google silently swallow emails before, both sending and receiving. It's not fun.
You may be right generally, but for your specific example that's not email being rubbish it's Google being rubbish. Why not switch to a professional provider?
Yes. Google's implementation of email. One of the most highly used email implementations on the planet.
That was just one example, I've seen corporate Exchange systems do the same. Are they not professional?
If one of the biggest email providers on the planet can silently swallow and not deliver emails, then blanket statements saying emails never fail are just wrong. It's important to understand practical failure modes of the systems we use, and not pretend they're more perfect than they are in reality.
That was just one example, I've seen corporate Exchange systems do the same. Are they not professional?
If one of the biggest email providers on the planet can silently swallow and not deliver emails, then blanket statements saying emails never fail are just wrong. It's important to understand practical failure modes of the systems we use, and not pretend they're more perfect than they are in reality.
It's funny that always when email fails, the next word is gmail, maybe go away from that wannabe email service? And no dont tell me a private server is impossible, i manage more then 150 (from different customers) of them and have zero problems with delivery to gmail ms etc, but yes you need to veryfi your domain @ google and microsoft.
Then those teams are wrong considering email is more robust, efficient and overall a better tool for the job.
> Why support Starbucks when you can support a mom & pop coffee shop
Because small, local is not always better. It's quite common to find coffee shops here in the PNW that make a horrendous espresso. Most roasters here in Seattle are pretty mediocre and only capitalizing on the Seattle reputation. I can rattle off all the "local" and "small-batch" bourbon/gin/vodka distilleries that use sourced alcohol and are over-priced train wrecks powered only by marketing and no skill. At least with Starbucks, I get consistently bad coffee. I'm not risking over paying for coffee that I spit out.
Definitely have been looking at st.ht but if github fulfills my needs better, I'm sticking with that.
Because small, local is not always better. It's quite common to find coffee shops here in the PNW that make a horrendous espresso. Most roasters here in Seattle are pretty mediocre and only capitalizing on the Seattle reputation. I can rattle off all the "local" and "small-batch" bourbon/gin/vodka distilleries that use sourced alcohol and are over-priced train wrecks powered only by marketing and no skill. At least with Starbucks, I get consistently bad coffee. I'm not risking over paying for coffee that I spit out.
Definitely have been looking at st.ht but if github fulfills my needs better, I'm sticking with that.
> I'm not risking over paying for coffee that I spit out.
That's exactly what happened to me at Starbucks. I had to wait for a small cookie shop to open up in order to buy an overpriced decent espresso. They had an Illy logo which helped a bit.
In Italy and Greece you specifically want to avoid big chains as almost every small shop makes better coffee.
That's exactly what happened to me at Starbucks. I had to wait for a small cookie shop to open up in order to buy an overpriced decent espresso. They had an Illy logo which helped a bit.
In Italy and Greece you specifically want to avoid big chains as almost every small shop makes better coffee.
I remember getting a cappuccino from a train station vending machine in Italy and saying, "Hey, this isn't too bad! Much better than Starbucks!"
Problem is that, I would say the majority of, small coffee shops in the US makes horrible espresso. Coffee isn't a craft to your average American no matter they claim, and they'll drink any swill. It's a way to get caffeine in you. Dark roast is the best selling roast.
If I go to a small coffee shop and they ask me what I mean when I order a doppio, that's when I start looking across the street for a Starbucks. At least Starbucks baristas are trained on what doppios are, and I'll get a consistently bad one. There's a very good chance that small mom and pop one will make me cigarette ash juice if they don't know what a doppio is. I'll take bad espresso over ash juice any day.
Problem is that, I would say the majority of, small coffee shops in the US makes horrible espresso. Coffee isn't a craft to your average American no matter they claim, and they'll drink any swill. It's a way to get caffeine in you. Dark roast is the best selling roast.
If I go to a small coffee shop and they ask me what I mean when I order a doppio, that's when I start looking across the street for a Starbucks. At least Starbucks baristas are trained on what doppios are, and I'll get a consistently bad one. There's a very good chance that small mom and pop one will make me cigarette ash juice if they don't know what a doppio is. I'll take bad espresso over ash juice any day.
> They had an Illy logo which helped a bit.
Interesting, does it? Obviously tastes differ, but I'm trying a tin at the moment because I ran out and could get it same day vs. waiting for delivery from my usual roaster subscription - I may as well be drinking any old thing off the supermarket shelf, don't find it superior at all.
Possibly the blend just isn't too my taste, it also doesn't seem to be as fine as I think I would grind it, but I think the main thing is freshness. Despite its vacuum seal it's still months old, vs. I usually receive beans within a few days of roasting and grind on demand.
Interesting, does it? Obviously tastes differ, but I'm trying a tin at the moment because I ran out and could get it same day vs. waiting for delivery from my usual roaster subscription - I may as well be drinking any old thing off the supermarket shelf, don't find it superior at all.
Possibly the blend just isn't too my taste, it also doesn't seem to be as fine as I think I would grind it, but I think the main thing is freshness. Despite its vacuum seal it's still months old, vs. I usually receive beans within a few days of roasting and grind on demand.
Maybe. I'm not a habitual coffee drinker, we buy roasted beans at home/work. It tastes better than Starbucks sludge or vacuum sealed supermarket stuff. Illy was the most decent supermarket brand, but in shops they use beans.
[deleted]
Smaller companies are a much bigger risk as a dependency. Whatever GitHub may do in the future, they are unlikely to disappear in any time frame I care about.
Tell that to the people who relied on Google Wave and Wunderlist. Or to the people who said "Linux will go the way of every other hobbyist OS" in 1994. I knew several orgs who were devastated when Atlassian shut down Hipchat.
If you want the only guaranteed probability about the future: its that most predictions about the future are wrong. Everything dies eventually; the things you least expect last longer than you expect them to; or sometimes much shorter. I do feel pretty confident that both Github and sr.ht will be operational tomorrow. But, not 100%; and even less than that next Tuesday; and even less by September.
Actually, Github has had 12 public incidents since May. So... maybe I shouldn't be so bold with my predictions about Github's operational status.
When people say "something is unlikely to happen" what they really mean is: I really hope that thing doesn't happen. Me, personally; I hope both Github and sr.ht continue to see success. As you say; me choosing to pay Github $5/mo won't change anything for the better or worse; but paying that to sr.ht, now that impact is much bigger. If you distil it down to the manifestation of your own hopes: I think the choice of who to support is obvious.
If you want the only guaranteed probability about the future: its that most predictions about the future are wrong. Everything dies eventually; the things you least expect last longer than you expect them to; or sometimes much shorter. I do feel pretty confident that both Github and sr.ht will be operational tomorrow. But, not 100%; and even less than that next Tuesday; and even less by September.
Actually, Github has had 12 public incidents since May. So... maybe I shouldn't be so bold with my predictions about Github's operational status.
When people say "something is unlikely to happen" what they really mean is: I really hope that thing doesn't happen. Me, personally; I hope both Github and sr.ht continue to see success. As you say; me choosing to pay Github $5/mo won't change anything for the better or worse; but paying that to sr.ht, now that impact is much bigger. If you distil it down to the manifestation of your own hopes: I think the choice of who to support is obvious.
Google and Microsoft are not even remotely similar in culture or product support.
Say what you want about Microsoft, they do more than just search or advertising. If anything you are interested in from Google isn't search or advertising related, don't count on it lasting. The only people surprised by Wave and/or Wunderlist getting canned are people who haven't been realistically looking at who Google is and how they operate. The worst IT contracts I have ever had to administer are with Google - they are a complete joke.
As for "incidents" - lol - who doesn't have them? What's more important is how does the org in question respond to them. You seriously think sr.ht is going to have the same resources as github/Microsoft? Then again it's a dramatically simpler platform so that's a huge advantage as far as that goes - but just look at this thread; as they add more features the chances for incidents goes up.
Say what you want about Microsoft, they do more than just search or advertising. If anything you are interested in from Google isn't search or advertising related, don't count on it lasting. The only people surprised by Wave and/or Wunderlist getting canned are people who haven't been realistically looking at who Google is and how they operate. The worst IT contracts I have ever had to administer are with Google - they are a complete joke.
As for "incidents" - lol - who doesn't have them? What's more important is how does the org in question respond to them. You seriously think sr.ht is going to have the same resources as github/Microsoft? Then again it's a dramatically simpler platform so that's a huge advantage as far as that goes - but just look at this thread; as they add more features the chances for incidents goes up.
You're aware that Wunderlist was purchased and shut down by Microsoft, correct?
You’re aware that Microsoft To Do is effectively the new Wunderlist, correct?
What about codeplex?
https://killedbymicrosoft.info/
https://killedbymicrosoft.info/
Google Wave is a bad example. I went to the first hackathon and knew it was doomed. It never had any real traction.
Github has massive market share and may get expensive but is unlikely to die.
Github has massive market share and may get expensive but is unlikely to die.
Yeah exactly, GitHub would be sold, not turned off.
And that would worry people, sure, new owners may not look after it, etc., but there'd be plenty of time and warnings to move off it.
And that would worry people, sure, new owners may not look after it, etc., but there'd be plenty of time and warnings to move off it.
Google Wave was also a looong time ago. People were still thinking of them as the "do no evil" company.
This is why we take pains to be transparent about things like finances:
https://sourcehut.org/blog/2022-04-08-2021-financial-report/
SourceHut is profitable and sustainable, thanks in no small part to the fact that we expect users to pay if they have the means. Small companies providing free services with investor subsidies are much more likely to disappear than a company with a service you're paying for which isn't beholden to any investor demands for infinite growth.
https://sourcehut.org/blog/2022-04-08-2021-financial-report/
SourceHut is profitable and sustainable, thanks in no small part to the fact that we expect users to pay if they have the means. Small companies providing free services with investor subsidies are much more likely to disappear than a company with a service you're paying for which isn't beholden to any investor demands for infinite growth.
> “ we expect users to pay if they have the means”
Hi Drew
I’d encourage you to start charging then based on your comment above.
Because sourcehut pricing page currently says “payment is currently optional”.
You’ve been in alpha for a few years now and I’m sure many of us would agree it’s totally appropriate for you to start officially charging based on the quality of your service.
https://sourcehut.org/pricing/
Hi Drew
I’d encourage you to start charging then based on your comment above.
Because sourcehut pricing page currently says “payment is currently optional”.
You’ve been in alpha for a few years now and I’m sure many of us would agree it’s totally appropriate for you to start officially charging based on the quality of your service.
https://sourcehut.org/pricing/
I should have been clearer: the expectation is only in force following the beta. We have a specific set of goals we would like to meet first. In the meantime we expect users to pay but are understanding of those who would prefer not to pay for incomplete software, even if our definition of "complete" exceeds industry standards.
But is it really profitable and sustainable?
IIUC your report, you are paying developers (and yourself) only USD $30,000/year. The typical software developer would make at least three time that much elsewhere. With 3x salary, I'd say SourceHut would no longer be profitable or sustainable. Or am I missing something?
IIUC your report, you are paying developers (and yourself) only USD $30,000/year. The typical software developer would make at least three time that much elsewhere. With 3x salary, I'd say SourceHut would no longer be profitable or sustainable. Or am I missing something?
We pay out base salaries well below market rates, but we supplement them with the FOSS consultancy at each individual employee's discretion. With these sources combined, our total compensation is similar to market rates, and often more -- one of our engineers made over $150,000 last year. We also set aside 3 months base salary for all developers so that even in the worst case scenario of our revenue dropping to zero, they have security. I explained how some of this works the last time we posted a job ad:
https://sourcehut.org/blog/2021-08-23-work-at-sourcehut/
The sustainability metrics are based on revenue covering the small base compensation plus operating expenses, as well as having a large enough standing balance to weather any unexpected events. We seek to make models which guarantee the longevity of the platform, and prioritize making sure that our cash flow will always provide for operating expenses. If our revenue dropped to zero today, we would be able to run the platform for several years.
Ultimately, everyone involved in SourceHut is there because they believe in free software and believe in the model we've designed to further its cause. Our non-negotiable ethical standards calls for a creative business model to make this thing work.
The work experience and impact we offer is something that is, in my opinion, completely unmatched in the industry. It's not for everyone, but we believe in what we're doing, and it's worth taking a gamble on an unproven business model.
https://sourcehut.org/blog/2021-08-23-work-at-sourcehut/
The sustainability metrics are based on revenue covering the small base compensation plus operating expenses, as well as having a large enough standing balance to weather any unexpected events. We seek to make models which guarantee the longevity of the platform, and prioritize making sure that our cash flow will always provide for operating expenses. If our revenue dropped to zero today, we would be able to run the platform for several years.
Ultimately, everyone involved in SourceHut is there because they believe in free software and believe in the model we've designed to further its cause. Our non-negotiable ethical standards calls for a creative business model to make this thing work.
The work experience and impact we offer is something that is, in my opinion, completely unmatched in the industry. It's not for everyone, but we believe in what we're doing, and it's worth taking a gamble on an unproven business model.
[deleted]
They're less likely to disappear, sure, but they're way more likely to permaban you and lock you out of your stuff, with no way to get ahold of a human who can undo it for you.
Having dealt with many local small businesses owners I'm not sure there is any significant difference in their propensity for ethically dubious behavior vs mega corporations.
> Why support Github when there is st.ht?
Github is about 1000x more user friendly?
Github is about 1000x more user friendly?
I would argue, that depends on the user.
If it's more user friendly for 1000x the number of users, I would say that counts.
What proportion of GitHub users has tried SourceHut?
If by “user-friendly” you mean “slow”…
Are you kidding me? Smaller companies will use you to make mistakes and learn. And when they can't support something because of resources then you bear the consequences. Nice notion but not a rule of thumb in my opinion. Mega corps like google are terrible as well. Newish companies that have been in the industry a few years are the rule of thumb unless you can afford to be their guineapig/stepping-stone.
> Smaller companies will use you to make mistakes and learn.
And the big ones don't ever do this? You're probably shielded from the jira ticket backlogs that are thousands deep.
While there's no hard and fast rule, small companies tend to care more, as they're closer to the pain. A loss of a customer isn't just "churn".
We should strive to have at least four to six alternatives for every type of system. It keeps pricing competitive, gives users lots of alternatives, and prevents single players from strong arming behavior.
Right now there are too many monopolies and duopolies in tech.
And the big ones don't ever do this? You're probably shielded from the jira ticket backlogs that are thousands deep.
While there's no hard and fast rule, small companies tend to care more, as they're closer to the pain. A loss of a customer isn't just "churn".
We should strive to have at least four to six alternatives for every type of system. It keeps pricing competitive, gives users lots of alternatives, and prevents single players from strong arming behavior.
Right now there are too many monopolies and duopolies in tech.
I agree with the last part of your post but I think you misunderstood what I meant by smaller, I meant small because they are new not because they haven't grown yet. It is unavoidable for new companies to have growing pains, doesn't matter how much they want to please customers. Once they have developed some maturity with their staff the "jira backlogs" will be prioritized right because their staff has learned from outages they caused because they did not understand what different aspects of your product mean to each customer.
On the B2B and B2G side economic patriotism is strong in Germany and France, but it seems that as a result local companies don't have to try as hard. Why bother if they will choose you based on nationality, not necessarily merit?
Remember OVH server room fire? Was there any failure of such magnitude in AWS/Azure/GCP?
Remember OVH server room fire? Was there any failure of such magnitude in AWS/Azure/GCP?
OVH is not playing in the same market as the big cloud providers - its primary business is doing commodity dedicated servers with the primary selling point being low cost.
It's hardly surprising that low cost options are more prone to failures in many markets.
It's hardly surprising that low cost options are more prone to failures in many markets.
[deleted]
I don't follow what you've taken for granted.
Why not buy the best product at the price you're willing to pay for it, even from a company with the values you share? Where does company size take precedent?
Why not buy the best product at the price you're willing to pay for it, even from a company with the values you share? Where does company size take precedent?
Two reasons.
If you don’t make an effort to try smaller company’s products, you’re going to be biased towards bigger companies by virtue of them having better marketing and network effects. Some conscious preference to smaller companies can help counteract this.
And even if the smaller company has a worse product initially, some people using it anyways can help keep them alive in order to fund innovation. Smaller companies tend to be more willing to experiment or innovate, but that can’t happen if no one is willing to make a long-term bet.
If you don’t make an effort to try smaller company’s products, you’re going to be biased towards bigger companies by virtue of them having better marketing and network effects. Some conscious preference to smaller companies can help counteract this.
And even if the smaller company has a worse product initially, some people using it anyways can help keep them alive in order to fund innovation. Smaller companies tend to be more willing to experiment or innovate, but that can’t happen if no one is willing to make a long-term bet.
Who shares Microsoft’s “values”, and what are they?
Microsoft? from what the flowing winds tells me, they seem to be,
> A very rich, multi-trillion dollar asshole-ish corporation, that feels lonely on it's birthday and goes on a bender buying less rich and asshole-ish companies to successively kill them, to calm it's mood.
Not sure how true that is, but something tells me it might just be the reality.
> A very rich, multi-trillion dollar asshole-ish corporation, that feels lonely on it's birthday and goes on a bender buying less rich and asshole-ish companies to successively kill them, to calm it's mood.
Not sure how true that is, but something tells me it might just be the reality.
I think it's more nuanced than that. I'm happy to buy from a smaller producer that may not have the absolute best product, as long as it meets my needs. I think consolidation and concentration of capital is one of the worst features of capitalism, and we should patronize smaller producers when it's reasonable to do so.
Having said that, I still buy a lot of things from Amazon because it's much more convenient than the alternatives. It's a habit I've been trying to kick, but I have a ways to go.
Having said that, I still buy a lot of things from Amazon because it's much more convenient than the alternatives. It's a habit I've been trying to kick, but I have a ways to go.
Consolidation is efficient. It frees up capital to be used elsewhere. No need for 10x accounting and marketing and sales department when 10 companies exist instead of one.
Of course a homogeneous world is less interesting. And anti-competitive behaviors are net bad and need to be disincentivized. Big company hate just seems misplaced.
Of course a homogeneous world is less interesting. And anti-competitive behaviors are net bad and need to be disincentivized. Big company hate just seems misplaced.
Another generic rule that is worth following is to not depend on software or services self labeled as alpha, beta, or any other pre-release.
It's a useful shorthand, certainly, but what is it shorthand for? Sophistication of the software, availability, performance, sustainability, security? We have many of these things and we offer transparency and data to back it up. SourceHut has a proven record of better uptime than GitHub and GitLab over its entire lifetime and is the highest performing forge platform available. We can offer many guarantees, backed by public data, which many platforms which label themselves as production-ready cannot.
We hold ourselves to a higher standard than most and we have a specific and documented set of goals to accomplish before we declare the alpha complete. However, any potential user who wants to use SourceHut today can find a wealth of information to secure peace of mind in their choice.
We hold ourselves to a higher standard than most and we have a specific and documented set of goals to accomplish before we declare the alpha complete. However, any potential user who wants to use SourceHut today can find a wealth of information to secure peace of mind in their choice.
You're alienating the vast majority of devs by choosing sr.ht, who don't have accounts there and don't want to set up yet another account, don't want to use mailing lists, etc.
In the end it's an ideals tradeoff. Are you going to prioritize the growth of your project ecosystem but give into megacorps, or are you kneecap contributions by choosing esoteric ethical workflows.
In the end it's an ideals tradeoff. Are you going to prioritize the growth of your project ecosystem but give into megacorps, or are you kneecap contributions by choosing esoteric ethical workflows.
I'm not here to defend any one service specifically. But I would like to let anybody with an aversion to Github know that they are not alone. And you are not some pariah. For that matter, it's ok if you don't even use git. If you have an interesting project, people will still be interested if you're willing to work with them.
Many a would-be contributor has lost interest when a project was entirely dependent on github, too. It's pretty telling when a contributor uses git, but can't contribute to a project that also uses git.
Many a would-be contributor has lost interest when a project was entirely dependent on github, too. It's pretty telling when a contributor uses git, but can't contribute to a project that also uses git.
> Why support Github when there is st.ht? Why support Starbucks when you can support a mom & pop coffee shop?
Small businesses usually treat their employees worse than chains do (because "we're all a family"). Also… coffee shops seem to have big opinions of themselves but the farmers do all the work. Baristas just have value unfairly credited to them by the customers because the product is addictive.
Small businesses usually treat their employees worse than chains do (because "we're all a family"). Also… coffee shops seem to have big opinions of themselves but the farmers do all the work. Baristas just have value unfairly credited to them by the customers because the product is addictive.
FWIW, just as Amazon and SalesForce are already doing their version of CoPilot, there is nothing to prevent GitHub from training its models off open source that is hosted on sr.ht or GitLab or anywhere else. If it is open source then the source is going to be available to be used for the models.
> there is nothing to prevent GitHub from training its models off open source that is hosted on sr.ht or GitLab or anywhere else
I disagree. I think that GitHub is training Copilot on only repos currently on GitHub, because they can easily do so due to the Terms of Service [1] which allow them to "parse [user content] into a search index or otherwise analyze [user content] on our servers". They can reasonably show that an ML model fits the definition of "otherwise analyze content", regardless of the license.
If code that was never hosted on GitHub to begin with starts showing up verbatim in Copilot suggestions, it might be a more legally challenging position for them. It is unfortunate grey area if people decide to upload copies of free software repos to GitHub anyway, but perhaps future versions of the GPL or other free/libre licenses could be explicit about usage in training ML models.
I have no idea what Amazon or Salesforce are doing, but it would be interesting to hear what they are using for training data and how they justify compliance with the software licenses.
----------------------------------------
[1] https://docs.github.com/en/site-policy/github-terms/github-t...
I disagree. I think that GitHub is training Copilot on only repos currently on GitHub, because they can easily do so due to the Terms of Service [1] which allow them to "parse [user content] into a search index or otherwise analyze [user content] on our servers". They can reasonably show that an ML model fits the definition of "otherwise analyze content", regardless of the license.
If code that was never hosted on GitHub to begin with starts showing up verbatim in Copilot suggestions, it might be a more legally challenging position for them. It is unfortunate grey area if people decide to upload copies of free software repos to GitHub anyway, but perhaps future versions of the GPL or other free/libre licenses could be explicit about usage in training ML models.
I have no idea what Amazon or Salesforce are doing, but it would be interesting to hear what they are using for training data and how they justify compliance with the software licenses.
----------------------------------------
[1] https://docs.github.com/en/site-policy/github-terms/github-t...
That's an interesting take but there's not really any protection in current open source licenses to stop someone else from agreeing to GitHub or any other hosting's terms for their clone of your repo.
Not a lawyer but there’s something incredibly subtle here. By only using content on GitHub, GitHub can ensure that every user has agreed to this term specifically:
> If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users.
https://docs.github.com/en/site-policy/github-terms/github-t...
And those users indemnify GitHub, too.
So code that has been uploaded to GitHub by non-GitHub employees does have a “color” to it (to quote a great blog post on IP law that I can’t find right now) that other instances of the repository under identical licenses on other hosting services do not - because in theory the uploader assumes some responsibility for any dispute!
Whether this “color” has significant legal merit is beyond my understanding, but I have no doubt it is a factor in their approach.
> If you are uploading Content you did not create or own, you are responsible for ensuring that the Content you upload is licensed under terms that grant these permissions to other GitHub Users.
https://docs.github.com/en/site-policy/github-terms/github-t...
And those users indemnify GitHub, too.
So code that has been uploaded to GitHub by non-GitHub employees does have a “color” to it (to quote a great blog post on IP law that I can’t find right now) that other instances of the repository under identical licenses on other hosting services do not - because in theory the uploader assumes some responsibility for any dispute!
Whether this “color” has significant legal merit is beyond my understanding, but I have no doubt it is a factor in their approach.
Not clear to me how it’s supposed to immunize Copilot from copyright claims, though I can see how it’ll justify its training process.
There is a vague supposition widely believed that NN weights do no longer contain training data, and thus the trainee holds full copyright, but that won’t stand when the NN returns excerpts from said training data. Then it just becomes an unattributed copy, and should be subject to takedowns.
There is a vague supposition widely believed that NN weights do no longer contain training data, and thus the trainee holds full copyright, but that won’t stand when the NN returns excerpts from said training data. Then it just becomes an unattributed copy, and should be subject to takedowns.
But "these permissions" are listed there explicitly:
> you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking)
There is no mention of making derivations or anything that looks like it could cover for CoPilot.
> you grant each User of GitHub a nonexclusive, worldwide license to use, display, and perform Your Content through the GitHub Service and to reproduce Your Content solely on GitHub as permitted through GitHub's functionality (for example, through forking)
There is no mention of making derivations or anything that looks like it could cover for CoPilot.
If M$ can parse and index code, they are able to do the same with sofware licenses and skip the projects that forbid this behaviour in robots.txt fashion.
A lot of open source licenses require numerous things including attribution, at the very least. So when copilot barfs out someones code verbatim, or nearly verbatim, after having memorized that code and it doesn't say who it's referencing, suddenly there's a problem.
IANAL, but still no.
The user who uploaded the code did provide attribution. They could have uploaded that code as part of a vendoring. There is not some flag that says they are not the copyright holders.
Copilot trains on that code just the same.
More importantly, the fair use they are claiming seems to bypass attribution and licensing requirements. It need only access to the code.
That is to say that it can 100% train on code hosted elsewhere. Until this fair use gets challenged by lawsuits, it will hold true.
The fact that we have not heard of these lawsuits yet, at least to me, shows that lawyers agree it is legal.
The user who uploaded the code did provide attribution. They could have uploaded that code as part of a vendoring. There is not some flag that says they are not the copyright holders.
Copilot trains on that code just the same.
More importantly, the fair use they are claiming seems to bypass attribution and licensing requirements. It need only access to the code.
That is to say that it can 100% train on code hosted elsewhere. Until this fair use gets challenged by lawsuits, it will hold true.
The fact that we have not heard of these lawsuits yet, at least to me, shows that lawyers agree it is legal.
Just saying what you want to be true, doesn't make it so. Attribution is required for all licenses that require it. Microsoft is laundering intellectual property.
A license is describing how you want to reassign rights given to you by copyright. AFAICT Microsoft believes they are within fair use granted by copyright law itself.
If they are correct they don't have to follow individual license terms, if they are incorrect it makes no difference if they scrape or receive code because any complex project is a mix of many past authors not all of whom must be on GitHub.
If they are correct they don't have to follow individual license terms, if they are incorrect it makes no difference if they scrape or receive code because any complex project is a mix of many past authors not all of whom must be on GitHub.
Unfortunately, they're not since it barfs out code verbatim sometimes and gives no attribution. So again, they can say whatever they want, it doesn't make it so.
Just because you say it's violating copyright and licensing doesn't make it so.
If the courts don't agree then there is no penalty. It would legally be fair use. It does not matter what you or I think.
You are arguing that it is wrong, but very clearly many lawyers disagree with you.
If the courts don't agree then there is no penalty. It would legally be fair use. It does not matter what you or I think.
You are arguing that it is wrong, but very clearly many lawyers disagree with you.
Just because it hasn't been tested in court yet doesn't mean it's legal, my friend. It's an easy fix. Ask each dev for permission or provide attribution as per each license when the same code comes out of the model. Easy peasy.
>That is to say that it can 100% train on code hosted elsewhere.
I'm not sure if this is true. The US isn't the only jurisdiction in which GitHub/Microsoft operates in.
I'm not sure if this is true. The US isn't the only jurisdiction in which GitHub/Microsoft operates in.
Anyone could just push the repos to GitHub, including GitHub employees.
Here are links to Amazon and Salesforce
https://aws.amazon.com/codewhisperer/ https://blog.salesforceairesearch.com/codegen/
Here are links to Amazon and Salesforce
https://aws.amazon.com/codewhisperer/ https://blog.salesforceairesearch.com/codegen/
Agreed, that's an unfortunate loophole which I already acknowledged; and as I said, it will probably be resolved in the future by software licenses that explicitly prohibit or accept the possibility of a hosting platform that automatically incorporates that code into ML model training.
> including GitHub employees
It would probably be different if GitHub's employees do it at GitHub's direction, since in that case they'd be explicitly taking an action on behalf of their employer to pull in that code.
> including GitHub employees
It would probably be different if GitHub's employees do it at GitHub's direction, since in that case they'd be explicitly taking an action on behalf of their employer to pull in that code.
Showing a reaction is very important in my book. I’m also moving to Source Hut.
Not hosting my code in servers of a company which is openly hostile to open source and Linux is a good move.
Lastly, you can try to prevent scraping. It’s a cat and mouse game, but at least your servers can’t be directly accessed by the training code itself.
Not hosting my code in servers of a company which is openly hostile to open source and Linux is a good move.
Lastly, you can try to prevent scraping. It’s a cat and mouse game, but at least your servers can’t be directly accessed by the training code itself.
Perhaps the licenses just need to be amended to explicitly say “you may not train AI models with this source code” and then get ready for a court battle.
I think Microsoft gives back to open source almost as much as they take, so I’m fine with them.
I think Microsoft gives back to open source almost as much as they take, so I’m fine with them.
[deleted]
The loss of attribution, for example, is going to become an issue. Especially since copilot barfs out code chunks verbatim at times.
And either way, it's time to yet again to step around Microsoft's interference in the beautiful world of open source.
And either way, it's time to yet again to step around Microsoft's interference in the beautiful world of open source.
Wait Amazon? what are they training it on? code hosted on AWS? what kind of mess are we in...?
Honestly all this is fine but train it on your own code, you have the money to do that, and the scale, why bother us the small fish. What's the worse that can happen, you will have to maybe pay people to write code, maybe start open source sponsor program to get rights to do such things, like based on need of project you might give them free hosting, free services, free etc... for project owners of smaller projects give them all some small grants. If every company did that for such models we will have much better OSS.
Also still IMO there really doesn't seem to be much we can do against it in the OSS space atleast, all code is open-source is hence code that's all openly readable, if a model is assumed to be a system that doesn't do 1:1 copy, the grounds seem shaky for legal process. Though honestly I very much want to be wrong, can we like file a lawsuit against such AIs in general, I see a similar problem with DallE looking at copyrighted art... What's next copyrighted music? Can't believe I am saying this but I feel bad for people who have copyrights. Music labels, entertainment empires, big services companies(like Accenture) and such will probably somehow survive, but the smaller people will get crushed.
And I say that as someone who primarily pursued Machine Learning in academics until graduation.
Maybe getting some "justified" compensation would be achievable...!?
Honestly all this is fine but train it on your own code, you have the money to do that, and the scale, why bother us the small fish. What's the worse that can happen, you will have to maybe pay people to write code, maybe start open source sponsor program to get rights to do such things, like based on need of project you might give them free hosting, free services, free etc... for project owners of smaller projects give them all some small grants. If every company did that for such models we will have much better OSS.
Also still IMO there really doesn't seem to be much we can do against it in the OSS space atleast, all code is open-source is hence code that's all openly readable, if a model is assumed to be a system that doesn't do 1:1 copy, the grounds seem shaky for legal process. Though honestly I very much want to be wrong, can we like file a lawsuit against such AIs in general, I see a similar problem with DallE looking at copyrighted art... What's next copyrighted music? Can't believe I am saying this but I feel bad for people who have copyrights. Music labels, entertainment empires, big services companies(like Accenture) and such will probably somehow survive, but the smaller people will get crushed.
And I say that as someone who primarily pursued Machine Learning in academics until graduation.
Maybe getting some "justified" compensation would be achievable...!?
It's called signalling. The chimp troupe has a wide variety of chimps with different needs. How do you find the ones where needs align? You send out such signals.
In another of the get-off-GitHub discussions recently, I mentioned to another FOSS project leader that they should consider taking their projects off GitHub to a forge that respects FOSS licenses. Sourcehut was one of the suggestions in addition to GitLab.
I'm glad to see that some projects are leading the way in this direction. To me, this move shows that the devs are competent and not afraid of migrations away from legacy forges if necessary; similar to how people moved from Sourceforge to GitHub 10 years ago.
I'll keep Kyoto framework in mind if need an SSR frontend framework in the future! I suggest others do the same.
----------------------------------------
[1] https://news.ycombinator.com/item?id=31941568
I'm glad to see that some projects are leading the way in this direction. To me, this move shows that the devs are competent and not afraid of migrations away from legacy forges if necessary; similar to how people moved from Sourceforge to GitHub 10 years ago.
I'll keep Kyoto framework in mind if need an SSR frontend framework in the future! I suggest others do the same.
----------------------------------------
[1] https://news.ycombinator.com/item?id=31941568
https://www.ycombinator.com/companies/gitlab
it's public, whatever their investor will ask, they'll comply, github is their competitor, they'll want the same product
unless you self host, in that case it is debatable but for how long
we need more services like sr.ht, and less like github/gitlab
it's public, whatever their investor will ask, they'll comply, github is their competitor, they'll want the same product
unless you self host, in that case it is debatable but for how long
we need more services like sr.ht, and less like github/gitlab
I think people should do the opposite and move their code to GitHub if it helps Copilot. It's the single most important invention of my lifetime. Its existence trumps any ideological or legal hurdles.
Why should we provide free data sets for github just to let them privatize gains?
It could be easily argued that nuclear bombs are one of, if not the, most significant inventions in the past century, and their existence continues to have a singnificant geopolitical impact. I think it's safe to say that the vast majority of humanity is ideologically opposed to their use.
BUT, they're one of, if not _the_ most important technological invention that currently effect us. So, that trumps ideological and legal hurdles, and thus we should use them.... right?
I would like to presume you would disagree with that assertion.
With that in mind, would you like to reconsider your justification for continuing to use GitHub?
To be clear, I'm not arguing that you shouldn't use GitHub. I'm arguing that the importance, or impact, of an invention is irrelevant to its continued use.
What's important is the short, and long term _effect_ of continuing to use it.
BUT, they're one of, if not _the_ most important technological invention that currently effect us. So, that trumps ideological and legal hurdles, and thus we should use them.... right?
I would like to presume you would disagree with that assertion.
With that in mind, would you like to reconsider your justification for continuing to use GitHub?
To be clear, I'm not arguing that you shouldn't use GitHub. I'm arguing that the importance, or impact, of an invention is irrelevant to its continued use.
What's important is the short, and long term _effect_ of continuing to use it.
> trumps any ideological
I don't think that word means what you think it means.
The word "ideological" gets bandied about a lot here as a pejorative drop-in for "things I don't support".
Perhaps we could be a bit less dramatic when considering the plurality of values people hold.
I don't think that word means what you think it means.
The word "ideological" gets bandied about a lot here as a pejorative drop-in for "things I don't support".
Perhaps we could be a bit less dramatic when considering the plurality of values people hold.
I use the word 'ideological' all the time here (https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...). Your comment got me thinking about what I mean by it.
I guess I mean something like: a fixed cluster of ideas that people apply to quickly make good/bad judgments, often accompanied by strong emotions.
Ideology tends to be generic (the same ideology gets applied to lots of things), predictable (a fixed idea lets one know where one stands in a predictable way), emotional (the need to know this is strongest on high-stakes issues), and binary (each ideology organizes itself in opposition to an opposing one).
I use the term in moderation comments because these qualities are bad for HN discussion. The 'fixed' aspect makes discussion predictable, the 'generic' aspect makes it shallow, and the binary/emotional aspect makes it inflammatory. A bad trifecta for curious conversation.
I guess I mean something like: a fixed cluster of ideas that people apply to quickly make good/bad judgments, often accompanied by strong emotions.
Ideology tends to be generic (the same ideology gets applied to lots of things), predictable (a fixed idea lets one know where one stands in a predictable way), emotional (the need to know this is strongest on high-stakes issues), and binary (each ideology organizes itself in opposition to an opposing one).
I use the term in moderation comments because these qualities are bad for HN discussion. The 'fixed' aspect makes discussion predictable, the 'generic' aspect makes it shallow, and the binary/emotional aspect makes it inflammatory. A bad trifecta for curious conversation.
These are very good parameters for encouraging positive discourse.
and averting dull discussion that descends into a game of Top-Trumps -
I play my ideological card, you play your idealogical card... ad
nauseum.
I'm not sure whether predictable, emotional and polar qualities are necessarily intrinsic to "ideologies" in the broad sense. Novel, calmly reasoned and nuanced commentary could be offered in support of positions so labelled. But I get your drift on "touchy topics that people are prone fly off the handle over". FWIW I think this has more to do with stated identity than abstract modes of thought these days. As a moderator I guess one gets a sense of the dynamics of a thread and when it's going to tip in a bad direction.
As I see it, we've come through, and remain in, an interregnum for perhaps 50 years, in which the word has become dirtied by the failures of political and religious practices. And also by incessant and needy "wars" on <the next terrible thing>. A thematic analysis of news from the past 20 years would surely place "ideology" in close proximity to words like "radicalised" or "extremist". That is parochial.
As a sceptic I'm possessed of a meta-ideology - that ideologies in themselves are healthy. We can have ideologies like economics, belief in space-faring exploration, benevolent technological society, self-determination in health and preventative medicine, and other powerful ideas which, in this forum, would be inarguably deemed positive. Perhaps, unless we propose abandoning thought as a way of being (in a Buddhist sense) ideology is just the inescapable waters in which we swim.
I guess what bugs me is if people use "ideology" as a bare, dismissive accusation that attempts to cut-off further dialogue. If everything and anything, including scientific method, can be an "ideology" it ultimately adds nothing to the conversation.
respects
I'm not sure whether predictable, emotional and polar qualities are necessarily intrinsic to "ideologies" in the broad sense. Novel, calmly reasoned and nuanced commentary could be offered in support of positions so labelled. But I get your drift on "touchy topics that people are prone fly off the handle over". FWIW I think this has more to do with stated identity than abstract modes of thought these days. As a moderator I guess one gets a sense of the dynamics of a thread and when it's going to tip in a bad direction.
As I see it, we've come through, and remain in, an interregnum for perhaps 50 years, in which the word has become dirtied by the failures of political and religious practices. And also by incessant and needy "wars" on <the next terrible thing>. A thematic analysis of news from the past 20 years would surely place "ideology" in close proximity to words like "radicalised" or "extremist". That is parochial.
As a sceptic I'm possessed of a meta-ideology - that ideologies in themselves are healthy. We can have ideologies like economics, belief in space-faring exploration, benevolent technological society, self-determination in health and preventative medicine, and other powerful ideas which, in this forum, would be inarguably deemed positive. Perhaps, unless we propose abandoning thought as a way of being (in a Buddhist sense) ideology is just the inescapable waters in which we swim.
I guess what bugs me is if people use "ideology" as a bare, dismissive accusation that attempts to cut-off further dialogue. If everything and anything, including scientific method, can be an "ideology" it ultimately adds nothing to the conversation.
respects
I'd rather keep my code away from a company and feature which disregards the licenses I prefer for my codebases, thank you.
You might be surprised about the limitations of your copyright claims!
https://en.wikipedia.org/wiki/Idea%E2%80%93expression_distin...
https://en.wikipedia.org/wiki/Abstraction-Filtration-Compari...
https://en.wikipedia.org/wiki/Idea%E2%80%93expression_distin...
https://en.wikipedia.org/wiki/Abstraction-Filtration-Compari...
Copilot is using GPL licensed code snippets as starting points or for adding to other snippets as derivations. As a result, it's injecting GPL code inside to another code, or providing GPL code as is.
At that point the code needs to be GPL licensed, or it's a breach of license. It's plain and simple.
Triviality cause is hard to argue, because you can code a nice "trade secret", or an algorithm worthy of its paper in ~25 lines (at least I did).
So Copilot's use of GPL licensed code is not fair use in my eyes.
BTW, all my public code is (A)GPLv3+ licensed. I want my code to stay open, not closed.
At that point the code needs to be GPL licensed, or it's a breach of license. It's plain and simple.
Triviality cause is hard to argue, because you can code a nice "trade secret", or an algorithm worthy of its paper in ~25 lines (at least I did).
So Copilot's use of GPL licensed code is not fair use in my eyes.
BTW, all my public code is (A)GPLv3+ licensed. I want my code to stay open, not closed.
Beyond notions of de minimis is the important distinction that copyright does not apply to utilitarian features! There are also notions of expressions that were already in the public domain and some copyright cases even refer to this as prior art.
You boldly assume that all GPL code is trivial and all the functions included in these codebases can be claimed to be on public domain.
There are many GPL licensed codebases (e.g. Linux Kernel, GNU Octave, GNU R, etc.) which contains serious research and novel ideas and implementations. These codebases are esp. licensed that way to keep that research in the open.
I have such a codebase which I was planning to open source with a GPL3.0 license, but I postponed that plans because of GitHub's Copilot shenanigans.
As I said, the code contains many novel, yet short snippets which are worthy of their own research paper.
Downplaying the research embedded in open codebases is just harmful to the discussion.
There are many GPL licensed codebases (e.g. Linux Kernel, GNU Octave, GNU R, etc.) which contains serious research and novel ideas and implementations. These codebases are esp. licensed that way to keep that research in the open.
I have such a codebase which I was planning to open source with a GPL3.0 license, but I postponed that plans because of GitHub's Copilot shenanigans.
As I said, the code contains many novel, yet short snippets which are worthy of their own research paper.
Downplaying the research embedded in open codebases is just harmful to the discussion.
Is looking at GPL code and rewriting it from scratch in your own style a license breach? For me, Copilot always uses the context and writes new code based on your own code as input. It uses the same patterns and code style as your own code.
Yes. When you write the same algorithm, even with a different style, it's a direct derivation of the code at hand. Derivative works of GPL licensed code are still GPL licensed.
Moreover, Copilot doesn't always derive code, but provides the code as-is, reproducing it comment by comment [0], and with a wrong license while at that.
[0]: https://twitter.com/mitsuhiko/status/1410886329924194309
Moreover, Copilot doesn't always derive code, but provides the code as-is, reproducing it comment by comment [0], and with a wrong license while at that.
[0]: https://twitter.com/mitsuhiko/status/1410886329924194309
Only the expressive elements of an algorithm fall under copyright. Generally speaking math equations and algorithms can’t be restricted by copyright.
Expressive, non-technical comments in code are most definitely protected by copyright.
Expressive, non-technical comments in code are most definitely protected by copyright.
So, I can use a code from a leaked source code as I wish, and duplicate all the algorithms and methods for achieving something.
Nice.
Well, we're so naive for making clean room development for so long, and writing EULA's with sentences all in caps stating that this is a trade secret and you can't do anything with it.
BTW, I want to reiterate that I'm trying to keep things open, not closed. So I'm not trying to copyright and protect it from being modified. This is what GPL is actually. So, the research is already there, in the form of a paper. You can re-implement that. But, my implementation is under GPLv3. So I'm not copyrighting/patenting the algorithm. It's certain expression I've implemented as a code, and opened under GPL.
As a result, if you derive anything from my implementation, that's GPL too. If you want that algorithm, it's on paper. Go implement that. I don't care.
Nice.
Well, we're so naive for making clean room development for so long, and writing EULA's with sentences all in caps stating that this is a trade secret and you can't do anything with it.
BTW, I want to reiterate that I'm trying to keep things open, not closed. So I'm not trying to copyright and protect it from being modified. This is what GPL is actually. So, the research is already there, in the form of a paper. You can re-implement that. But, my implementation is under GPLv3. So I'm not copyrighting/patenting the algorithm. It's certain expression I've implemented as a code, and opened under GPL.
As a result, if you derive anything from my implementation, that's GPL too. If you want that algorithm, it's on paper. Go implement that. I don't care.
Note that the controlling framework here is copyright law, hence the term "copyright license".
A lawyer will tell you that reimplementing code you have read, even if you change around the functions and rename the variables, is inviting a lawsuit. A general defense to a copyright lawsuit is to document that you have never viewed the copyrighted work, e.g. by having one person/team document the function of the code and having another person/team implement the function using that documentation (a.k.a. "clean-room reverse-engineering").
In this case, it would be up to the courts, but having a piece of copyrighted code reproduced verbatim in your project without a license is not a good look, and I highly doubt usage of Copilot would be an affirmative defense.
A lawyer will tell you that reimplementing code you have read, even if you change around the functions and rename the variables, is inviting a lawsuit. A general defense to a copyright lawsuit is to document that you have never viewed the copyrighted work, e.g. by having one person/team document the function of the code and having another person/team implement the function using that documentation (a.k.a. "clean-room reverse-engineering").
In this case, it would be up to the courts, but having a piece of copyrighted code reproduced verbatim in your project without a license is not a good look, and I highly doubt usage of Copilot would be an affirmative defense.
If you look at NEC v Intel we get an affirmation that verbatim similarity is often a sign that it was the only way to implement a given function.
And in Sony v Connectix we get a ruling that even non-clean room implementations are not in violation if there is no way to reverse engineer otherwise.
And in Sony v Connectix we get a ruling that even non-clean room implementations are not in violation if there is no way to reverse engineer otherwise.
Yes, actually. That's why clean-room design is a thing.
All I see when I look at Copilot is code written by the most stupid coworker that could ever exist - and now, my job is to review it. I really hope we had better inventions in your lifetime than that.
Although I don't agree with you I up-voted the comment because I think you're raising an important point.
Automating code generation is part of the self-accelerating process of the techno-singularity, eh?
Automating code generation is part of the self-accelerating process of the techno-singularity, eh?
Thanks, but I don't want a huge company to sell my code without giving me anything back.
It would be useful to know what this project is. Lots of projects are on other code hosting services. Is this is a particularly important project? Go has been my daily driver for almost a decade and this is the first I've heard of it.
The move is more of interest to commenters than the project itself, as an instance of an explicit action to move code away from GitHub, which seems to have gained the general status of "place where source code on <any project> is found" over the past decade.
> Lots of projects are on other code hosting services.
Yes, and they usually tend to stay there, unless the code hosting service starts doing unusual things with your code. The README of the linked project is quite explicit about all this.
> Lots of projects are on other code hosting services.
Yes, and they usually tend to stay there, unless the code hosting service starts doing unusual things with your code. The README of the linked project is quite explicit about all this.
Just click through to their new readme on sourcehut:
https://sr.ht/~kyoto-framework/kyoto-framework/
https://sr.ht/~kyoto-framework/kyoto-framework/
I did. Do lots of people use this library? I guess I'm wondering what the relative "newsworthiness" of this announcement is, because, like I said, people move things off Github all the time.
Well, it had 515 magic GitHub popularity points before the move, if that matters to you. There's no notoriety condition on HN -- it's newsworthy if HN voters decide it is. I figured you'd know better than to drag out the old "why is this on the front page" standard.
That's not at all what I'm doing. I don't care whether things move off Github, but I am a Go programmer, and this is a Go library, and I'm curious if I missed out on some important library. That's all.
As the guidelines say: "assume good faith".
As the guidelines say: "assume good faith".
That doesn't tell us how important this project is. I am not a Go dev, all I can see is it's some template-rendering lib, 500 stars on GitHub, 3 contributors on opencollective.
The discussion on this thread is great but I am not sure that this project is that significant.
The discussion on this thread is great but I am not sure that this project is that significant.
I left Codeplex many years ago. I could easily leave Github as well, in fact I'll do that over the weekend.
This article was pretty eye-opening. https://sfconservancy.org/GiveUpGitHub/
This article was pretty eye-opening. https://sfconservancy.org/GiveUpGitHub/
Just had this thought: are there any decentralized code hosting services?
To me, I don't really see a difference between GitHub and sr.ht. Companies can start out with these "friendly" attitudes towards FOSS, but when they reel in many paying customers, they can pretty easily, and without consequence, change their policies to be more aggressive (geared towards profit) and greedy. It just seems inevitable to me.
However, decentralized hosting and governance might make it so that there can't be a hostile takeover and incorrect (relative to license) usage of FOSS code. I'm thinking something akin to IPFS but more specialized towards e.g git repository hosting.
Not sure how such hosting would be feasible in terms of breaking even between hosting costs, but a decentralized service hosting distributed VCS databases seems more along the lines of the philosophy of DVCS's in general. DVCS's in general do not have timeliness requirements (i.e your "git push" most of the time doesn't have to propagate worldwide immediately) and the other goodies that come with being on GitHub (e.g CI/CD) seem orthogonal to the actual code hosting itself, and I don't see why that can't be built separately without being part of the service.
To me, I don't really see a difference between GitHub and sr.ht. Companies can start out with these "friendly" attitudes towards FOSS, but when they reel in many paying customers, they can pretty easily, and without consequence, change their policies to be more aggressive (geared towards profit) and greedy. It just seems inevitable to me.
However, decentralized hosting and governance might make it so that there can't be a hostile takeover and incorrect (relative to license) usage of FOSS code. I'm thinking something akin to IPFS but more specialized towards e.g git repository hosting.
Not sure how such hosting would be feasible in terms of breaking even between hosting costs, but a decentralized service hosting distributed VCS databases seems more along the lines of the philosophy of DVCS's in general. DVCS's in general do not have timeliness requirements (i.e your "git push" most of the time doesn't have to propagate worldwide immediately) and the other goodies that come with being on GitHub (e.g CI/CD) seem orthogonal to the actual code hosting itself, and I don't see why that can't be built separately without being part of the service.
Founder of sr.ht here. I understand these fears, and I have gone to great lengths to give users tangible assurances in this regard. Trust is something that has to be earned, and it is incredibly important to me that we are worthy of yours.
For a start, the company is bootstrapped and we have no private investors. The revenue to maintain the platform comes directly from users, and all users are expected to pay if they have the means for this reason. We are accountable only to them and we do not have to find "creative" ways to monetize them (or their work) because they are already footing the bill themselves. Every cent paid by users stays in open source, either supporting the platform or the dozens of projects our engineers maintain or contribute to in the FOSS ecosystem.
We also seek to be as transparent as possible. Our financial reports, monitoring system & alarms, security reporting, operational documentation, backups, and so on, is all publicly available. We have hard data that you can use to understand our platform's sustainability, security, performance, uptime, and more.
And, unlike GitHub (and GitLab), SourceHut is 100% bona-fide free software, mostly AGPL. You can run it on your own servers, and we make it easy to import and export your data, in standard, interoperable formats that you can use to move between instances or even between software stacks, such as GNU Mailman or other solutions. SourceHut is also not an ivory tower -- we elevate our users to peers, and many parts of our system are officially maintained by independent volunteers.
I work really hard for our user's trust and I'm proud to know that I have it. If anyone has questions or concerns, I'm always prepared to listen to them and do what it takes to make sure our users are confident in the platform. FOSS is my life's passion and I am committed to doing it right.
For a start, the company is bootstrapped and we have no private investors. The revenue to maintain the platform comes directly from users, and all users are expected to pay if they have the means for this reason. We are accountable only to them and we do not have to find "creative" ways to monetize them (or their work) because they are already footing the bill themselves. Every cent paid by users stays in open source, either supporting the platform or the dozens of projects our engineers maintain or contribute to in the FOSS ecosystem.
We also seek to be as transparent as possible. Our financial reports, monitoring system & alarms, security reporting, operational documentation, backups, and so on, is all publicly available. We have hard data that you can use to understand our platform's sustainability, security, performance, uptime, and more.
And, unlike GitHub (and GitLab), SourceHut is 100% bona-fide free software, mostly AGPL. You can run it on your own servers, and we make it easy to import and export your data, in standard, interoperable formats that you can use to move between instances or even between software stacks, such as GNU Mailman or other solutions. SourceHut is also not an ivory tower -- we elevate our users to peers, and many parts of our system are officially maintained by independent volunteers.
I work really hard for our user's trust and I'm proud to know that I have it. If anyone has questions or concerns, I'm always prepared to listen to them and do what it takes to make sure our users are confident in the platform. FOSS is my life's passion and I am committed to doing it right.
HN believes this comment is spam and I cannot reply to it:
https://news.ycombinator.com/item?id=31963630
So I'll reply here instead.
> This is somewhat off topic, but I'm wondering if you've considered offering a pre-paid lifetime plan. sr.ht looks great, and I've considered moving my project over from github, but the thing holding me back is that I don't want the obligation to maintain a subscription into perpetuity. Github's killer feature isn't that it's free, but rather, that I can get hit by a bus (or just become busy with other things in life), and my project will remain hosted indefinitely.
There are currently minimal penalties for non-payment, and in the future, they will remain conservative. We will place your account into a read-only mode after a grace period, but will not remove data without consulting you first. We are people first, free software second, and a business third. We would be honored to set profit aside in the interest of maintaining our users' legacies after they're gone.
https://news.ycombinator.com/item?id=31963630
So I'll reply here instead.
> This is somewhat off topic, but I'm wondering if you've considered offering a pre-paid lifetime plan. sr.ht looks great, and I've considered moving my project over from github, but the thing holding me back is that I don't want the obligation to maintain a subscription into perpetuity. Github's killer feature isn't that it's free, but rather, that I can get hit by a bus (or just become busy with other things in life), and my project will remain hosted indefinitely.
There are currently minimal penalties for non-payment, and in the future, they will remain conservative. We will place your account into a read-only mode after a grace period, but will not remove data without consulting you first. We are people first, free software second, and a business third. We would be honored to set profit aside in the interest of maintaining our users' legacies after they're gone.
Thanks for the reply. I guess the combination of a new account, a link, and talk about plans and payments was enough to set off HN's spam filter.
You're doing such a great job that I subscribed for a year even though I had no need for the service at the time. I just wanted to financially support what I see as a really inspiring project. Not to mention that it is an objectively good product.
I will likely buy another subscription (and actually use it) at some point in the future but until then I'll be recommending sr.ht to anyone in need of lightweight and open development platform.
Keep up the good work!
I will likely buy another subscription (and actually use it) at some point in the future but until then I'll be recommending sr.ht to anyone in need of lightweight and open development platform.
Keep up the good work!
Thank you :)
This is somewhat off topic, but I'm wondering if you've considered offering a pre-paid lifetime plan. sr.ht looks great, and I've considered moving my project over from github, but the thing holding me back is that I don't want the obligation to maintain a subscription into perpetuity. Github's killer feature isn't that it's free, but rather, that I can get hit by a bus (or just become busy with other things in life), and my project will remain hosted indefinitely.
What if I wanted to try this out?
In the sense that at the moment I don’t pay for Github and my projects remain there hosted for free.
What would happen in sr.ht jf for whatever event I stopped paying for the service?
In the sense that at the moment I don’t pay for Github and my projects remain there hosted for free.
What would happen in sr.ht jf for whatever event I stopped paying for the service?
Right now, there are no consequences for non-payment. In the future, your account may be put into a read-only mode following a grace period. Your projects won't disappear overnight.
I always got the impression that sr.ht was not intended to be social software, but simply a git frontend.
To me, this makes it unsuitable as a frontend for community-focused projects that cater to involving and attracting strangers, and much more something for single-committer repos.
Ultimately, building large software ends up being a team sport, and I never got the impression that your product had the express goal of facilitating (and causing) collaboration; in fact quite the opposite: that those are explicitly out of scope for the project.
To me, this makes it unsuitable as a frontend for community-focused projects that cater to involving and attracting strangers, and much more something for single-committer repos.
Ultimately, building large software ends up being a team sport, and I never got the impression that your product had the express goal of facilitating (and causing) collaboration; in fact quite the opposite: that those are explicitly out of scope for the project.
SourceHut is designed to facilitate collaboration, of course, but it's done differently from platforms like GitHub and those that seek to emulate it. And of course it is more than a git frontend, providing tools specifically to facilitate collaboration such as mailing lists and bug trackers. SourceHut is an engineering tool, not a social network. It is designed to get your work done and then get out of your way.
GitHub is explicitly designed like a social network, and this is a design that we reject. Counting stars and scrolling through feeds is a distraction from getting work done, not to mention an unhealthy relationship to have with your work. Popularity is not a metric we think that people should be optimizing for, or one that can even be effectively measured.
So our design deliberately skews away from what we think of as "dopamine dispensers" and instead focuses on getting the work done. We make it easy to onboard new collaborators by skipping the account requirement to send patches or file tickets. The UI is simple and accessible for users with any accessibility needs, and free of distractions. Colors are used deliberately to attract your eye to the action items on each page, not to dazzle you with information overload. These are the kinds of motivations which guide the design of the platform.
For the social aspect, we encourage you to branch out. Talk about your project on Hacker News. Maintain a fediverse presence. Put up a marketing page and documentation on SourceHut pages. Cultivate welcoming mailing lists. There are many ways to crack an egg.
GitHub is explicitly designed like a social network, and this is a design that we reject. Counting stars and scrolling through feeds is a distraction from getting work done, not to mention an unhealthy relationship to have with your work. Popularity is not a metric we think that people should be optimizing for, or one that can even be effectively measured.
So our design deliberately skews away from what we think of as "dopamine dispensers" and instead focuses on getting the work done. We make it easy to onboard new collaborators by skipping the account requirement to send patches or file tickets. The UI is simple and accessible for users with any accessibility needs, and free of distractions. Colors are used deliberately to attract your eye to the action items on each page, not to dazzle you with information overload. These are the kinds of motivations which guide the design of the platform.
For the social aspect, we encourage you to branch out. Talk about your project on Hacker News. Maintain a fediverse presence. Put up a marketing page and documentation on SourceHut pages. Cultivate welcoming mailing lists. There are many ways to crack an egg.
> So our design deliberately skews away from what we think of as "dopamine dispensers" and instead focuses on getting the work done.
What about the case where getting the work done involves doubling the number of people involved in the project, and not a single line of code?
Nobody's on the fediverse, and email is not taken seriously by most modern developers. These interactions still happen on the web.
What about the case where getting the work done involves doubling the number of people involved in the project, and not a single line of code?
Nobody's on the fediverse, and email is not taken seriously by most modern developers. These interactions still happen on the web.
Hundreds of thousands of people are on the fediverse, and many large projects use email every day for their work - Linux, GNU, Postgres, Debian, etc. It might not be for you, but it works for many people.
I don’t think your first assertion is true. Hundreds of thousands of accounts have been created. I think the DAU is in the low thousands.
It’s the only social media I use, and it’s a ghost town. We have to live in the world that is, not the one we wish were.
I used to have a Twitter follower count on my niche little tech/privacy account that is higher than the DAU count of the entire fediverse.
It’s the only social media I use, and it’s a ghost town. We have to live in the world that is, not the one we wish were.
I used to have a Twitter follower count on my niche little tech/privacy account that is higher than the DAU count of the entire fediverse.
I haven't been on Mastodon in a while, but when I was, it was far from a ghost town. You see what you federate with, and following or engaging with more people will fill your timeline up more. If you don't use it much, then you won't get much out of it.
No, it's nothing like Twitter in terms of DAU. However, your Twitter account compared to your Fediverse account is not a good representation of the entire state of the Fediverse. And: it's not necessary to capture 100% of the market share on attention. It's simply necessary to capture enough that your project is successful.
No, it's nothing like Twitter in terms of DAU. However, your Twitter account compared to your Fediverse account is not a good representation of the entire state of the Fediverse. And: it's not necessary to capture 100% of the market share on attention. It's simply necessary to capture enough that your project is successful.
You can automatically send these patch e-mails with "git send-email" command. So there's no friction involved. It only works differently.
Moreover your mailing list can facilitate discussion, so nothing is lost.
Moreover your mailing list can facilitate discussion, so nothing is lost.
Git itself is decentralized. It is entirely agnostic from a centralized/decentralized point of view. We tend to centralize things to make life easier. Who wants to pull updates from each contributor as opposed to a hub?
So the real question is — what are the features of GitHub would you like to see decentralized? CI? Issues? Wikis? Because, you can self host many of these with gitea, GitLab, or sr.ht. That’s the best kind of decentralization, but it does add to your own personal overhead (maintenance, backups), and really limits discovery.
I think what you might be asking for is if there is a federated code repository that supports git. That’s an interesting question, and I don’t know if such a thing yet exists.
So the real question is — what are the features of GitHub would you like to see decentralized? CI? Issues? Wikis? Because, you can self host many of these with gitea, GitLab, or sr.ht. That’s the best kind of decentralization, but it does add to your own personal overhead (maintenance, backups), and really limits discovery.
I think what you might be asking for is if there is a federated code repository that supports git. That’s an interesting question, and I don’t know if such a thing yet exists.
> I think what you might be asking for is if there is a federated code repository that supports git. That’s an interesting question, and I don’t know if such a thing yet exists.
Sourcehut itself is fully federated if you are willing to learn email workflow. You don't need to register an account anywhere to collaborate on sourcehut. That include feature requests, bug reports, discussions, submitting patches and even pull requests from any public repository anywhere [1]. The discussions also exist on mailing list archives and personal mailboxes. They are not lost even if you decide to change host.
But developers are extremely resistant to email workflows. When I suggest it, people react as if I am suggesting black magic. But in my experience, email workflow isn't that unpleasant. Most of the problems with email workflow are due to poor email clients (issues with plain text, composing, rendering and threaded displays). Setting up git and a good but simple email client for git is not a hard task. The rest of the workflow is actually very pleasant.
[1] https://git-scm.com/docs/git-request-pull
Sourcehut itself is fully federated if you are willing to learn email workflow. You don't need to register an account anywhere to collaborate on sourcehut. That include feature requests, bug reports, discussions, submitting patches and even pull requests from any public repository anywhere [1]. The discussions also exist on mailing list archives and personal mailboxes. They are not lost even if you decide to change host.
But developers are extremely resistant to email workflows. When I suggest it, people react as if I am suggesting black magic. But in my experience, email workflow isn't that unpleasant. Most of the problems with email workflow are due to poor email clients (issues with plain text, composing, rendering and threaded displays). Setting up git and a good but simple email client for git is not a hard task. The rest of the workflow is actually very pleasant.
[1] https://git-scm.com/docs/git-request-pull
- Code review aka pull requests.
- Issues.
- CI.
- "Home page" with the readme.md rendered.
Easy discoverability is a large concern. Easy discussion with fast round-trips and a trail is important (email or NNTP can help here though). CI is a thing that may need a serious effort to get running smoothly.
These things are centralized because it's easy to implement them once in one place instead of reinventing. But if there'd be an obvious and bullet-proof way to have them replicated (like in Fossil), the need for strict centralization would wane.
Discoverability would still be an issue though. It's like torrents: completely decentralied, but without a directory like TPB it's really hard to find them.
- Issues.
- CI.
- "Home page" with the readme.md rendered.
Easy discoverability is a large concern. Easy discussion with fast round-trips and a trail is important (email or NNTP can help here though). CI is a thing that may need a serious effort to get running smoothly.
These things are centralized because it's easy to implement them once in one place instead of reinventing. But if there'd be an obvious and bullet-proof way to have them replicated (like in Fossil), the need for strict centralization would wane.
Discoverability would still be an issue though. It's like torrents: completely decentralied, but without a directory like TPB it's really hard to find them.
Is it possible to decentralize "I know about package X -> Find Package X online -> Git Clone"?
While keeping the property of very high availability? And making it convenient.
I think the first two steps could be covered by a source search engine that spans different repository providers, and includes self-hosted git instances.
That source search engine will probably be centralized, although if we are just searching names and descriptions (and not code) the engine could be a fairly small .zip file that anyone can install. So comes down to "passing around lists".
While keeping the property of very high availability? And making it convenient.
I think the first two steps could be covered by a source search engine that spans different repository providers, and includes self-hosted git instances.
That source search engine will probably be centralized, although if we are just searching names and descriptions (and not code) the engine could be a fairly small .zip file that anyone can install. So comes down to "passing around lists".
That’s the idea with pkg.go, npm, pypi, CRAN, (CPAN?!?), etc… discovery of packages. I think each of these has a wider record for the package showing where individual code repositories are hosted. But I wouldn’t necessarily call them “convenient.”
But that isn’t helpful for cross-language searching, or a code search engine (which I think is a great idea).
But that isn’t helpful for cross-language searching, or a code search engine (which I think is a great idea).
> To me, I don't really see a difference between GitHub and sr.ht. Companies can start out with these "friendly" attitudes towards FOSS, but when they reel in many paying customers, they can pretty easily, and without consequence, change their policies to be more aggressive (geared towards profit) and greedy. It just seems inevitable to me.
But with sourcehut you can just host it yourself or find someone else who hosts that as everything is FOSS.
If you don't want to use the built-in CI, wiki and issue tracker, then Git is already decentralized. You can push and pull easily from and to multiple sources. Git is already built for that exact use case.
But with sourcehut you can just host it yourself or find someone else who hosts that as everything is FOSS.
If you don't want to use the built-in CI, wiki and issue tracker, then Git is already decentralized. You can push and pull easily from and to multiple sources. Git is already built for that exact use case.
> If you don't want to use the built-in CI, wiki and issue tracker, then Git is already decentralized. You can push and pull easily from and to multiple sources. Git is already built for that exact use case.
Git is a great protocol. You can pull/push to HTTPS servers, SSH servers, even directories (so via NFS if you so wish). Really, Git is really awesome in that way.
But Git itself is not a "code hosting service" that parent asked for. That requires more. Something like Fossil SCM would probably fit better, or git-ssb as I mentioned in another comment here.
Git is a great protocol. You can pull/push to HTTPS servers, SSH servers, even directories (so via NFS if you so wish). Really, Git is really awesome in that way.
But Git itself is not a "code hosting service" that parent asked for. That requires more. Something like Fossil SCM would probably fit better, or git-ssb as I mentioned in another comment here.
I don’t know Drew DeVault personally, but I feel from his blog that he’s fairly transparent and not interested in attempting to squeeze out every possible cent of profit from sourcehut. I may be proven wrong in the future, but for now I’m happy with the service and hopeful that it will remain affordable, friendly, and fast.
I think there is a 10 year "we can have nice things" expiry date on stuff like this. Think Google / Github / Facebook etc.
After 10 years, the thing dies, or grows so big it becomes a corporation, run by suits, hungry for new revenue. There are probably exceptions (HN is one, as it is more of a well kept and groomed "pet" than a business in itself. Meant in a nice way as I love pets).
Death is an interesting one. Reading that Prince's estate is trying to color troll [1], means that regardless of what Prince wanted (not sure what he wanted either way), some other heads with different ethics can take over and do something different from the ethos you thought you were buying into.
[1] https://news.ycombinator.com/item?id=31925423
After 10 years, the thing dies, or grows so big it becomes a corporation, run by suits, hungry for new revenue. There are probably exceptions (HN is one, as it is more of a well kept and groomed "pet" than a business in itself. Meant in a nice way as I love pets).
Death is an interesting one. Reading that Prince's estate is trying to color troll [1], means that regardless of what Prince wanted (not sure what he wanted either way), some other heads with different ethics can take over and do something different from the ethos you thought you were buying into.
[1] https://news.ycombinator.com/item?id=31925423
HN is maintained at least in part to promote YC startups and the reputation of YC itself. The monetization is indirect. (Maybe some posts are sponsored? I would be mildly surprised.)
This suggests the incentives for YC are more aligned to users’ goals than, say, Reddit.
This suggests the incentives for YC are more aligned to users’ goals than, say, Reddit.
git-ssb is really nice for decentralized hosting between friends. Uses Secure Scuttlebutt (https://scuttlebutt.nz/) and I've used it for over a year to collaborate on projects with people over ssb.
I'm a bit scared of putting this link here, as the gateway is not super reliable, so I'll ask people who are curious, to get ssb running locally and pull down the data if they want to look into it deeper.
But regardless, here is the link for the curious minds who can't wait, it's the repository for git-ssb itself: https://git.scuttlebot.io/%254Dsh92G6zkkLnR3%2Fys%2Fv42MD0jK...
If you get server errors, jump on ssb yourself, or wait some seconds/minutes and refresh. Be kind to the poor server.
I'm a bit scared of putting this link here, as the gateway is not super reliable, so I'll ask people who are curious, to get ssb running locally and pull down the data if they want to look into it deeper.
But regardless, here is the link for the curious minds who can't wait, it's the repository for git-ssb itself: https://git.scuttlebot.io/%254Dsh92G6zkkLnR3%2Fys%2Fv42MD0jK...
If you get server errors, jump on ssb yourself, or wait some seconds/minutes and refresh. Be kind to the poor server.
> I don't really see a difference between GitHub and sr.ht. Companies can start out with these "friendly" attitudes towards FOSS
You are really comparing DeVault with, of all companies, microsoft?
You are really comparing DeVault with, of all companies, microsoft?
I don't know the backstory with the sr.ht founder or anything, but I think there is a difference. GitHub always started out as a for-profit company, albeit targeting the market of FOSS developers/communities, and had a closed-source product sold for on-prem use. Sourcehut is itself FOSS software from the beginning and has its own developer community, so it is a little different.
sr.ht is the vision of one extremely stubborn man who loves free software. I wouldn’t host my material there, but if your worry is that he’ll go corporate, you’re probably pretty safe.
> I wouldn’t host my material there
Why?
Why?
Not OP but IMO the UX is really bad. It's removed almost everything that github/gitlab popularized for a plain, unstyled, email driven workflow. HN often states that git is too complex for most users and source hut pushes that to the extremes by using all the internal concepts and terminology in the UI rather than the more modern and understandable names.
I wouldn't want to use any decentralized system for code if there's no discovery, code search, cross instance logins, AND BACKUPS.
It'd suck to end up in a situation like you see with torrents, where there are tons of references, but no access to the data.
I can imagine tons of useful code being lost over time that way.
It'd suck to end up in a situation like you see with torrents, where there are tons of references, but no access to the data.
I can imagine tons of useful code being lost over time that way.
Git is great because every clone is a backup: if you want public backups, push to multiple upstreams (or setup mirroring): e.g. sr.ht, self-hosted gitea on AWS and self-hosted gitolite on Hetzner
Radicle is a decentralised Github alternative to the point it does not have any centralised servers. However, because of ”web3” many people here on HackerNews might not take it seriously, even thought it might deserve a closer look.
https://radicle.xyz/
https://radicle.xyz/
It's not that we don't take it seriously, it's what we condone. Web3 is a scam and destroys the environment.
Yes.
Moving to Radicle would completely eliminate the issues the maintainers had.
Moving to another provider seems like they just "hoping" for the best.
Moving to Radicle would completely eliminate the issues the maintainers had.
Moving to another provider seems like they just "hoping" for the best.
As long as it's P2P without involving any cryptocurrencies, I don't see why you'd label it "Web3"?
Edit: seems Ethereum is a opt-in optional part of Radicle, so I see how people could believe it to be a part of the whole "Web3" effort.
Well, as long as I can run it without Ethereum, I'm happy.
Edit: seems Ethereum is a opt-in optional part of Radicle, so I see how people could believe it to be a part of the whole "Web3" effort.
Well, as long as I can run it without Ethereum, I'm happy.
It literally says Web3 on the second heading of the landing page.
As my edit mentions, seems at least that part is opt-in rather than a core of the protocol. So you can use it without "Web3" if you want.
Web3 is the decentralized web.
Cryptocurrencies are just an extra. No wonder, people here hating on Web3 all the time, if they don't understand that.
Cryptocurrencies are just an extra. No wonder, people here hating on Web3 all the time, if they don't understand that.
...no, the decentralized web is just the web.
Web3 is utterly synonymous with cryptocurrency. Plenty of people here understand what it is and what is discussed when the term is brought up.
Web3 is utterly synonymous with cryptocurrency. Plenty of people here understand what it is and what is discussed when the term is brought up.
If you think that while using HN, Twitter, FB, GitHub, Google, or anything like that, then bless your heart.
You appear to have completely missed the point of my comment, but given that you ended this comment with a bad attempt to be condescending I suppose I'm not surprised.
Come on, you really wanna the high road here?
Your comment was basically "I know better and people who are my opinion know this too".
I'm not that long in the Web3 space, but from what I read I got the impression it's about decentralization, self-sovereign identity and permissionless infrastructure. These are fundamental building blocks, which happen to allow the creation of cryptocurrencies, but, as systems like IPFS or Radicle show, they also allow the creation of different things.
Your comment was basically "I know better and people who are my opinion know this too".
I'm not that long in the Web3 space, but from what I read I got the impression it's about decentralization, self-sovereign identity and permissionless infrastructure. These are fundamental building blocks, which happen to allow the creation of cryptocurrencies, but, as systems like IPFS or Radicle show, they also allow the creation of different things.
>Come on, you really wanna the high road here?
I wasn't taking the high road. It was not necessary nor conducive to good discussion for you to end your comment the way you did.
>Your comment was basically "I know better and people who are my opinion know this too".
No, it was not.
I wasn't taking the high road. It was not necessary nor conducive to good discussion for you to end your comment the way you did.
>Your comment was basically "I know better and people who are my opinion know this too".
No, it was not.
Crypto hype projects continuously obscure the facts with confusing marketing hype. One thing I couldn't work out from the page is how much it costs to use. It was my understanding that pretty much all web3 projects are hit hard with transaction fees for any change.
Cryptocurrencies are a way to get funding for web3 infrastructure in a decentralized way. Sadly, it's not the only way cryptocurrencies can be used.
I think, IPFS and Radicle did good here by not making these type of payments mandatory.
They said: if you don't want to run all that stuff yourself, pay someone to host your node. If you want that someone to host nodes in a decentralized matter, you can pay them with crypto.
I think, IPFS and Radicle did good here by not making these type of payments mandatory.
They said: if you don't want to run all that stuff yourself, pay someone to host your node. If you want that someone to host nodes in a decentralized matter, you can pay them with crypto.
Shameless plug: https://staticadventures.netlib.re/blog/decentralized-forge/
I wrote this article about decentralized forging and the different approaches to it, P2P and federated. It's not exactly an in-depth analysis but i believe it's a good high-level overview of the ecosystem which has changed little since then.
I wrote this article about decentralized forging and the different approaches to it, P2P and federated. It's not exactly an in-depth analysis but i believe it's a good high-level overview of the ecosystem which has changed little since then.
[deleted]
Drew Devault is /g/ incarnate. He won't ever do any bullshit to people using the services. If anything he would just as well burn it all to the ground.
Well, there was the Mastodon instance that just disappeared on me one day.
I wasn't paying for it though, or using the account much.
I wasn't paying for it though, or using the account much.
The thing is, I’ve said this about many many people that eventually sold out.
I wouldn’t trust anyone that claimed it, not even myself.
I wouldn’t trust anyone that claimed it, not even myself.
He never claimed it, and never said it - it's just his actions are the actions of a typical /g/ poster. So he is the real deal.
Recent and related:
Give up GitHub: The time has come - https://news.ycombinator.com/item?id=31932250 - June 2022 (544 comments)
Give up GitHub: The time has come - https://news.ycombinator.com/item?id=31932250 - June 2022 (544 comments)
I wish Sourcehut displayed code on the repo's primary page (as opposed to a separate "tree" tab) like most mainstream services such as GitHub or GitLab.
If there's a big migration away from Github then I really worry what I'll do about discovering interesting stuff. I spend an hour or so a week looking through my Github feed. Something genuinely valuable will be lost once that is no longer a rich seam of new repos.
The likely solution to that problem is ForgeFed, a kind of ActivityPub for federated source-control systems: https://github.com/forgefed/forgefed
Unfortunately this suffers from compounded niche-ness. Even with huge interest and constant public f-ups from social media companies, the Fediverse has failed to gain any real traction (likely due to the unintuitiveness of cross-server identity).
GitHub is already niche for the general populace, most people haven’t heard of it. Among programmers, alternative SCM platforms outside of GitLab and Perforce are niche. When we multiply the two together we get an incredibly small set of potential users (and the UX challenges of ActivityPub are still there).
GitHub is already niche for the general populace, most people haven’t heard of it. Among programmers, alternative SCM platforms outside of GitLab and Perforce are niche. When we multiply the two together we get an incredibly small set of potential users (and the UX challenges of ActivityPub are still there).
This doesn't compound though - are we trying to get the general populace who doesn't use GitHub to use something that supports ForgeFed/ActivityPub?
On the other hand, it seems significantly easier - instead of trying to convert the general populace to ActivityPub, we're trying to convert technically literate developers and related peoples to use ActivityPub.
Also, for what it's worth, I quite enjoy my self-hosted Mastodon account and long since stopped using Twitter and Facebook.
Also, for what it's worth, I quite enjoy my self-hosted Mastodon account and long since stopped using Twitter and Facebook.
ActivityPub does not address or solve the problem of discoverability, which is what the parent comment is talking about. So it's not a solution to that problem.
Is there any working implementation of ForgeFed at the moment?
I quite enjoy looking at the sr.ht project listings myself: https://sr.ht/projects
Usually I find at least one or two new things that are interesting.
Usually I find at least one or two new things that are interesting.
These things are like "Why I left Google" from 2010s.
Questions for whoever was involved with this decision or might know:
Why was Sourcehut chosen? Any specific appealing features?
Any alternatives considered?
Why was Sourcehut chosen? Any specific appealing features?
Any alternatives considered?
The fact that it's not intended to be a free service (only free during alpha [1]) is a non-starter. Asking people to change their workflow is bad enough, asking them to stop getting it for free is a joke.
[1]: https://sourcehut.org/pricing/
[1]: https://sourcehut.org/pricing/
If you don't pay, someone else will. GitHub is funded by private investors demanding a return, which incentivizes behavior like repurposing your code to facilitate mass license infringement. SourceHut is entirely funded by its users and is therefore only accountable to their needs.
SourceHut's fees are very cheap ($2/mo) and users who cannot pay for any reason are offered free service.
If you will only use services that you don't need to pay for, that's your choice, but you should respect the choices of others who consider these incentives and their outcomes more important.
SourceHut's fees are very cheap ($2/mo) and users who cannot pay for any reason are offered free service.
If you will only use services that you don't need to pay for, that's your choice, but you should respect the choices of others who consider these incentives and their outcomes more important.
If a user stops paying (excepting free service for those unable to pay), will their repositories be deleted? My main concern is link rot: if a project was created on GitHub in 2012, links to it will almost certainly point to the same code today, even if the owner has long forgotten about it, so long as they haven't actively deleted their account. I've found that the same is rarely true for bespoke self-hosted Git servers. Many disappear within 3 years or less, without any redirects to a new location; I've had to copy many of these repos to my GitHub account from a local copy. So how worried do I need to be about the longevity of sr.ht links?
We will place your account into a read-only mode following a grace period if you don't pay up. I hate link rot and I have no intention of contributing to it with SourceHut.
This is the tragedy of the commons all over again, and all of us in the open source space know very well how that goes.
I agree with you that the world where open source code is not hosted by private companies is a better one. However if our plan is to rely on the already-insufficiently-supported/rewarded maintainers changing their workflow, changing tools, and paying their own money (however low), we won't get there.
Just like I think a world where all important software is open source is a better one. To get there, we just need corporations to give maintainers some of their own money. We are not getting there.
I agree with you that the world where open source code is not hosted by private companies is a better one. However if our plan is to rely on the already-insufficiently-supported/rewarded maintainers changing their workflow, changing tools, and paying their own money (however low), we won't get there.
Just like I think a world where all important software is open source is a better one. To get there, we just need corporations to give maintainers some of their own money. We are not getting there.
We think the workflow is better, and no one was born knowing how to use GitHub, either. SourceHut is very affordable and the price is well worth the cost. If you want FOSS to be sustainable, FOSS platforms have to be sustainable, too.
SourceHut is a corporation that donates to FOSS projects, by the way. We sponsor many projects and we're planning on building more tools to get maintainers paid for their work.
SourceHut is a corporation that donates to FOSS projects, by the way. We sponsor many projects and we're planning on building more tools to get maintainers paid for their work.
Again, I am not saying this isn't the right way or that you are doing anything wrong. I just think that if we are asking people giving away their code for free to do a migration and learn another tool for the greater good, for free, and before that they also have to put in their credit card number and pay their own money... people won't do that, righteous as it may be.
A call for action is all the more effective if that action is easy. The Software Freedom Conservancy's call has a lot of background but if the proposed action is "host it yourself" or "pay money for SourceHut", I worry that we will not move forward.
A call for action is all the more effective if that action is easy. The Software Freedom Conservancy's call has a lot of background but if the proposed action is "host it yourself" or "pay money for SourceHut", I worry that we will not move forward.
I'm not sure that we'll be moving forward if we're not willing to answer to the fact that our indulgence in free services is putting our freedoms in jeopardy. What use is it if you jump ship from GitHub to another service which is letting investors foot your bill? It'll just be the same story in a few years. SourceHut is designed for long-term sustainability and an ethical operating model.
If you feel differently, perhaps Codeberg is for you instead? SFC recommends them as well and I am just as happy to see projects move there as I am to see them on SourceHut -- we're a paying (but non-voting) member of Codeberg ourselves. Diversity is healthy for the ecosystem, but the proprietary platforms ought to be expelled.
If you feel differently, perhaps Codeberg is for you instead? SFC recommends them as well and I am just as happy to see projects move there as I am to see them on SourceHut -- we're a paying (but non-voting) member of Codeberg ourselves. Diversity is healthy for the ecosystem, but the proprietary platforms ought to be expelled.
> I'm not sure that we'll be moving forward if
I totally agree with you! This is why I think we will not be moving forward, with things as they are.
I totally agree with you! This is why I think we will not be moving forward, with things as they are.
Why do you pay Codeberg and what is your role with them?
We use them to host our status page on independent infrastructure:
https://codeberg.org/ddevault/pages
We started paying as soon as we started relying on them for this purpose. We pay one euro short of the minimum contribution for voting rights, to support them while respecting their independence. Codeberg is doing wonderful work that we (and the community at large) are depending on and we're prepared to support that without hesitation. Diversity is good for FOSS.
https://codeberg.org/ddevault/pages
We started paying as soon as we started relying on them for this purpose. We pay one euro short of the minimum contribution for voting rights, to support them while respecting their independence. Codeberg is doing wonderful work that we (and the community at large) are depending on and we're prepared to support that without hesitation. Diversity is good for FOSS.
> Codeberg is doing wonderful work
how are they different, or better, than any other floss instance (disroot, framagit, gitgud, savannah, NotABug, pagure, etc)?
how are they different, or better, than any other floss instance (disroot, framagit, gitgud, savannah, NotABug, pagure, etc)?
They're backed by a member-owned organization, are in good financial standing for the long term, and it is run by good people that I trust. The others may be good as well but I think that Codeberg has really got it nailed.
> people won't do that, righteous as it may be
On the contrary, it means only people that really want to be on Sourcehut will do so.
Which is probably for the best, certainly while it’s still in an alpha state.
Slow and steady wins the race.
On the contrary, it means only people that really want to be on Sourcehut will do so.
Which is probably for the best, certainly while it’s still in an alpha state.
Slow and steady wins the race.
Something I've been unclear on for a while, and I'd be grateful if anyone can explain it.
The project points to [0] as its rationale for leaving Github. One of that document's complaints about Github is that they do business with the US's ICE department. It's not the only group from which I've heard such thorough contempt for ICE.
I understand why people might have problems with some aspects of ICE's activities, e.g. charges of inhumane treatment of people crossing the border without authorization. So it makes sense to me that they'd protest those particular behaviors.
But protesting all of ICE makes no more sense to me than un-nuanced calls to entirely defund the police, or abolish the entire DoD. I.e., it seems obvious that totally eliminating any of those government functions would cause problems that almost nobody would find acceptable.
Is there something I'm missing?
[0] https://sfconservancy.org/GiveUpGitHub/
The project points to [0] as its rationale for leaving Github. One of that document's complaints about Github is that they do business with the US's ICE department. It's not the only group from which I've heard such thorough contempt for ICE.
I understand why people might have problems with some aspects of ICE's activities, e.g. charges of inhumane treatment of people crossing the border without authorization. So it makes sense to me that they'd protest those particular behaviors.
But protesting all of ICE makes no more sense to me than un-nuanced calls to entirely defund the police, or abolish the entire DoD. I.e., it seems obvious that totally eliminating any of those government functions would cause problems that almost nobody would find acceptable.
Is there something I'm missing?
[0] https://sfconservancy.org/GiveUpGitHub/
People want a spectrum of things. Often, “defund the police/ICE” means “replace them with something better”, not eliminating them and forgetting about their original purpose. A few (or many, depending who you ask) bad apples spoiled the batch.
> As far as a go packaging system makes host changing painful enough, there is no chance to keep old versions on the new host.
> If you're using version 0.x, please, make a fork, or create a local project copy.
I feel like an official mirror on GitHub would be cleaner, as the old URLs could still work, but I suppose that doesn't match the vision.
> If you're using version 0.x, please, make a fork, or create a local project copy.
I feel like an official mirror on GitHub would be cleaner, as the old URLs could still work, but I suppose that doesn't match the vision.
If you're starting a new Go project, I strongly recommend using a custom import path- I host go.bbkane.com with GitHub Pages and it was easy and free to set up with vangen and GitHub Pages (I already own bbkane.com).
https://github.com/bbkane/go.bbkane.com
https://github.com/bbkane/go.bbkane.com
Any good reason(s) why SourceHut and not Gitlab?
SourceHut is missing a lot of features from GitHub, I'm not even sure if SourceHut has a file tree. It's interface is also much different than GitHub's.
Meanwhile GitLab is almost an exact clone of GitHub. It has discussion boards, pull requests ("merge requests"), even CI which replaces GitHub actions.
I figure SourceHut is more FOSS-friendly than GitLab. But GitLab still supports self-hosting, and AFAIK is open-source and FOSS-freindly itself. The KDE and GNOME project even have their own hosted GitLab versions. All-in-all I just think migrating from GitHub to GitLab seems much easier than migrating to SourceHut.
SourceHut is missing a lot of features from GitHub, I'm not even sure if SourceHut has a file tree. It's interface is also much different than GitHub's.
Meanwhile GitLab is almost an exact clone of GitHub. It has discussion boards, pull requests ("merge requests"), even CI which replaces GitHub actions.
I figure SourceHut is more FOSS-friendly than GitLab. But GitLab still supports self-hosting, and AFAIK is open-source and FOSS-freindly itself. The KDE and GNOME project even have their own hosted GitLab versions. All-in-all I just think migrating from GitHub to GitLab seems much easier than migrating to SourceHut.
Can't speak for others but I would choose sourcehut over gitlab any day; having used gitlab at work, it's a hot mess of JavaScript that tries to replace command line workflows that work-- it's terribly slow, and once even used 60GB of memory on my machine.
On the other hand, sourcehut promotes better workflows, in favor of a really snappy web interface.
For those who are attached to forks and PRs there's also a web UI for submitting a "patch set" which basically walks you through the process the same way as a pull request.
On the other hand, sourcehut promotes better workflows, in favor of a really snappy web interface.
For those who are attached to forks and PRs there's also a web UI for submitting a "patch set" which basically walks you through the process the same way as a pull request.
Recently I contributed to a new project which needed repository hosting, and I was excited to suggest Sourcehut. But when we learned of the email-only collaboration, it was too uncomfortable for this particular group (and I include myself). Most devs are used to pull requests, it seems awkward that Sourcehut doesn't support them.
> But when we learned of the email-only collaboration, it was too uncomfortable for this particular group
What makes using email or certain technologies uncomfortable, but using a new language or framework comfortable?
> (and I include myself)
The link with the associated comment threads we are paticipating in could have easily been an email and every comment could have been a direct reply to that email or a reply to one of the comments. Would that be more or less comfortable compared to just having this discussion on the web interface on https://news.ycombinator.com?
What makes using email or certain technologies uncomfortable, but using a new language or framework comfortable?
> (and I include myself)
The link with the associated comment threads we are paticipating in could have easily been an email and every comment could have been a direct reply to that email or a reply to one of the comments. Would that be more or less comfortable compared to just having this discussion on the web interface on https://news.ycombinator.com?
As John McEnroe said, you cannot be serious. Are you trying to claim that Reddit, HN, and perhaps Facebook and Stack Overflow would work just as well if they were isolated to email and had no website? If email is so great, why are Slack, Trello, Discord, Notion, Basecamp all so popular?
Usenet, IRC, and the chat clients that were around 20 to 30 years ago were very popular and none of them ran on a website.
But your comment doesn't answer my original question about level of comfort. Why is learning how to write programs, run them, and learn frameworks considered a comfortable activity, but using email is not? The former is orders of magnitude more difficult compared to the latter, so ease of use doesn't seem to be the reason.
But your comment doesn't answer my original question about level of comfort. Why is learning how to write programs, run them, and learn frameworks considered a comfortable activity, but using email is not? The former is orders of magnitude more difficult compared to the latter, so ease of use doesn't seem to be the reason.
> Usenet, IRC, and the chat clients that were around 20 to 30 years ago were very popular and none of them ran on a website.
And they all died out quickly as soon as web-based platforms stole their audience.
And they all died out quickly as soon as web-based platforms stole their audience.
Neither of your comments answer my question about level of comfort. I would be interested to hear your answer to that question.
Tough shit. You made a dumb point and now you're doubling down on it, and challenging me to get into an argument about it with you. All of which is typical trolling behavior.
So you don't have an answer and replied with an ad hominem instead.
You've already provided an answer, troll:
In my experience, any Microsoft Exchange/O365 server will most likely mangle the email server side (introducing quoted-printable encoding characters or changing the message-id field. Gmail will require that you enable insecure application access in order to use git-send-email. If you don't do that, then using git-send-email will result in a authentication failure error (which you can see if you use the --debug flag).
So this email-only workflow doesn't work with the two most popular email clients. Where do I sign up?
https://news.ycombinator.com/item?id=19579649
In my experience, any Microsoft Exchange/O365 server will most likely mangle the email server side (introducing quoted-printable encoding characters or changing the message-id field. Gmail will require that you enable insecure application access in order to use git-send-email. If you don't do that, then using git-send-email will result in a authentication failure error (which you can see if you use the --debug flag).
So this email-only workflow doesn't work with the two most popular email clients. Where do I sign up?
https://news.ycombinator.com/item?id=19579649
> doesn't work with the two most popular email clients
Clearly you don't understand the difference between a MUA and a MTA. Perhaps you should spend some time learning the difference instead of engaging in any more name calling. There's no use continuing this discussion when you outed yourself as someone who has no idea what they're talking about.
Clearly you don't understand the difference between a MUA and a MTA. Perhaps you should spend some time learning the difference instead of engaging in any more name calling. There's no use continuing this discussion when you outed yourself as someone who has no idea what they're talking about.
Less comfortable, way less. Email chains that become trees are a nightmare to deal with when they happen in practice.
How is an email thread with multiple branches any different than the comment tree in this post? What makes it less comfortable and why is it a nightmare compared to how the comments are rendered?
The only difference is that you could have to click on each comment to read the body of the message, but the tree structure would be the same as it is now.
The only difference is that you could have to click on each comment to read the body of the message, but the tree structure would be the same as it is now.
sourcehut in particular was designed with email based collaboration in mind, and I like they've stuck to it. There are so many alternatives out there for Github like pull requests.
There are projects like linux that don't accept PRs on github and swear on sending patches. Obligatory Linus Rant: https://github.com/torvalds/linux/pull/17#issuecomment-56546...
There are projects like linux that don't accept PRs on github and swear on sending patches. Obligatory Linus Rant: https://github.com/torvalds/linux/pull/17#issuecomment-56546...
Yikes. Mailing list development might work for Linus and the kernel team but the PR approach on GitHub is so much easier for developers to discover and use and even for senior or more seasoned devs I’d rather do this in the open on a PR than in some mailing list. Ugh.
To be honest; I think something the creator (?) commented elsewhere here is really apt: no one is born knowing how to use Github. We get used to what we're used to.
I'm not asserting that as an argument for email, or PRs, but rather just that I'm certain there's people who feel, and are, extremely productive in vim, or collaborating over email, or programming in PHP, or whatever tech the younger people in the industry would claim is Yikes or Big Oof.
Unless we're talking about Bitbucket. No one is productive in Bitbucket.
I'm not asserting that as an argument for email, or PRs, but rather just that I'm certain there's people who feel, and are, extremely productive in vim, or collaborating over email, or programming in PHP, or whatever tech the younger people in the industry would claim is Yikes or Big Oof.
Unless we're talking about Bitbucket. No one is productive in Bitbucket.
There's a huge middle ground of running your own instance of Gitlab/etc. versus going to the mailing list style of development (even that could be a lot easier with a more readable web interface and web posting support).
Yeah, I was reading this and thought "Have fun!":
> I don't know much about it, but I'm going to dig into it in the near future (https://man.sr.ht/lists.sr.ht/). For now, those who want to contribute, I'll just add read/write permissions to the project.
> I don't know much about it, but I'm going to dig into it in the near future (https://man.sr.ht/lists.sr.ht/). For now, those who want to contribute, I'll just add read/write permissions to the project.
I think the mailing list approach would work for giant projects that have many bullshit PRs and issues, and you want to deter the “hello please fix it on my pc” stuff. Not really for small projects where each PR is usually helpful.
I have no idea what is kyoto and if it fits there.
I have no idea what is kyoto and if it fits there.
Personally, it took me a long time to understand how pull requests work.
Copilot shouldn't be paid service of it's based on someone else work
For what it's worth, none of the reasons listed for switching away from Github in that SFC article are persuasive to me, but that's my choice. Kyoto project is free to choose what's best for them.
I approve the move, congrats!
Does Kyoto license explicitly forbid the code from being cloned to GitHub? If not, seems like at best buying time until someone else does.
this makes me want gitlab to focus more on the software development side instead ci cd devops
git-remote-gcrypt + rclone + s3.
The title confused me at first, "they are moving from sr.ht to GitHub?", but then I realized I'm just used to reading migrations like that in a "from $serviceB to $serviceA" manner and "to $serviceA from $serviceB" made it all wrong in my brain. Funny how that works.
I like “from A to B” because B happens after A temporally and in the text. It also serves to emphasize A as opposed to B, which is nice because we usually wouldn’t leave A unless there was really a problem with it even if B is better in some way.
Had the same reaction - skipping prepositions and mashing the nouns into a trained interpretive mold. Guess I need to slow down.
You will love the Intel assembly dialect.
Was just going to say this. Although, it's not specific to Intel assembly. Many assembly languages use the syntax: move destination,origin
So does the assignment statement in almost all languages I know.
But assignment in most languages doesn't use a word that's commonly used with a particular order.
[deleted]
The NYT uses this style (to … from …) deliberately as well. It’s a little bumpier, as you mention, but avoids confusion with describing a range.
We've changed it above now. (Submitted title was "Kyoto framework is moving to sr.ht from GitHub")
last night I checked my billing page on sr.ht and there was a line chart that had "11.2%" to indicate that currently 11.2% of users are paying...there was also a redline at 13% which I assume is some sustainability threshold
if you want viable alternatives to github, pay up!
sr.ht is a nice service that allows some premium features like ssh'ing into ci instances to check failures...there is plenty worth paying for
if you want viable alternatives to github, pay up!
sr.ht is a nice service that allows some premium features like ssh'ing into ci instances to check failures...there is plenty worth paying for
The red line is at 13.37 percent, so I assume it's a semi-joke.
You can read about the 2021 financials here; it seems that the project is pretty successful overall: https://sourcehut.org/blog/2022-04-08-2021-financial-report/
You can read about the 2021 financials here; it seems that the project is pretty successful overall: https://sourcehut.org/blog/2022-04-08-2021-financial-report/
Yeah, it's just a joke. SourceHut is already profitable & sustainable. But, I think that it is important that we establish the expectation that users should be paying for the service. It keeps our interests aligned directly with theirs and we are accountable to no one else.
Isn't this moving from proprietary repo provider to proprietary repo provider (albeit a smaller one)?
SourceHut is not proprietary. It is 100% free software (mostly AGPL) and provides tools to migrate your data between hosted or self-hosted instances.
There's no guarantee that sr.ht (the "repo provider") is running upstream SourceHut (the AGPL software). I do believe that it is, but there's simply no way to guarantee it, so it would be reasonable to consider a non-self-hosted SourceHut instance as proprietary.
(Again, to be clear I'm just playing devil's advocate with the semantics. I personally don't believe that sr.ht is doing anything nefarious.)
(Again, to be clear I'm just playing devil's advocate with the semantics. I personally don't believe that sr.ht is doing anything nefarious.)
I don't think that's a reasonable take. We are legally obligated to publish the source code running on our servers because we have incorporated code from others under the terms of the AGPL, without asking for them to assign copyright to us. This take also seems especially outlandish considering that the context is comparing SourceHut to GitHub, which is very clearly more proprietary even in this awkward sense.
>We are legally obligated to publish the source code running on our servers
This is not a guarantee until it is challenged in court or audited by some trusted auditor.
>This take also seems especially outlandish considering that the context is comparing SourceHut to GitHub, which is very clearly more proprietary even in this awkward sense.
No disagreement there.
This is not a guarantee until it is challenged in court or audited by some trusted auditor.
>This take also seems especially outlandish considering that the context is comparing SourceHut to GitHub, which is very clearly more proprietary even in this awkward sense.
No disagreement there.
I still find the insinuation quite ridiculous, to be entirely honest.
Why support Github when there is st.ht? Why support Starbucks when you can support a mom & pop coffee shop? Why buy books from Amazon when you can buy from a Indie book store? Granted, not everyone has the patience, time and money to vote with wallet, but we can try wherever possible. I hope more people ditch Github