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.
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.
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!
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?
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.
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.
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.
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.
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.
Moreover your mailing list can facilitate discussion, so nothing is lost.
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.
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.
- 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.
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".
But that isn’t helpful for cross-language searching, or a code search engine (which I think is a great idea).
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.
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.
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.
This suggests the incentives for YC are more aligned to users’ goals than, say, Reddit.
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.
You are really comparing DeVault with, of all companies, microsoft?
Why?
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.
Moving to Radicle would completely eliminate the issues the maintainers had.
Moving to another provider seems like they just "hoping" for the best.
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.
Cryptocurrencies are just an extra. No wonder, people here hating on Web3 all the time, if they don't understand that.
Web3 is utterly synonymous with cryptocurrency. Plenty of people here understand what it is and what is discussed when the term is brought up.
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.
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 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 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 wasn't paying for it though, or using the account much.
I wouldn’t trust anyone that claimed it, not even myself.
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.