Upfront: I'm a co-founder of ApyHub. I am looking to grow the number of APIs and endpoints on the platform. That's my primary interest here, read everything with that in mind.

Some of the best APIs I have seen are built by one person solving one problem extremely well. This can be anything, a holiday data service. A screenshot renderer. A receipt or a cv parser. Technically solid, running for years, and almost nobody knows they exist. The builder is busy maintaining it. Distribution is a different job they never signed up for.

That's the job we took on. We cover the entire layer from API discovery to consumption. Here's what that means for a provider:

• Distribution. One subscription gives our users the whole catalog, so your API is available to every subscriber the moment it goes live. No marketing site, no SEO grind.

• MCP by default. Every endpoint is agent-ready. Claude, Cursor, any agent runtime can discover and call your API without you writing glue code.

• Fair, transparent payouts. You set your own price and change it whenever you want (dynamic pricing). Clean split, monthly payouts, no hidden fees. You keep your IP, no exclusivity.

• Hosting. Keep running it yourself and we route to it, or we host it on our infra and take ops off your plate.

• We handpick and verify every service before it lists. That's the whole point.

Publishing takes under 10 minutes, I swear.

If you have built an API, what would stop you from listing it somewhere like this? Loss of control? The split? Trust?

Something else? I want the objections as much as the signups. :)

How many lines of code does an average Linux kernel developer produce per year?

Based on estimates of the value of the Linux kernel (around 2200 Million Euros in 2011), the size of the kernel (in 2011, version 2.6 was current, with a bit less than 20 million lines of code), and average salary of kernel developers (for Germany, one could estimate 60,000 - 80,000 EUR/year for a mid to senior embedded developer, you can go to kununu.de and look for salary statistics for larger companies like Siemens as a reference), one can estimate the lines of new code that a full-time kernel developer produces - less than 1000 lines per year:

 value=2200000000
 cost_man_year = 60000
 lines_of_code= 20000000

 person_years = value / cost_man_year
lines_per_person_per_year = lines_of_code / person_years

I get to 545 lines per person-year that way.

The interesting question is: You can obviously type that in in half an hour. What do these software developers actually do all day? ;->

Edit: Some people might get it wrong and overlook the 😉 emoticon: I absolutely don't think you should or can measure the productivity or competence of a software developer by counting the lines he or she produces! Myself, I just fixed a bug after searching one whole week for it by uncommenting a single line ... in a two year old unfinished port of a software written 15 years ago to implement and port a niche industrial protocol created 18 years ago.

There's this weird github repository

https://github.com/OOOO00000000OOOO/OOOO00000000OOOO

I noticed there was someone attempting to proxy to this repository on my site, causing it to show up in the logs. It was detected as spam but this repo doesn't look like it's built by some normal spammy company. The owner has gone through great lengths to try to stay anonymous. And I can't make out what the repo is or what it's for. Does anyone know or have any ideas?

Thanks

Why is learning C so much more generally useful than learning React? What I mean by the last point is that learning C tends to develop skills that are useful in a lot of other parts of software and tech work: if you know how to write decent C, you'll have a much easier time of understanding PostgreSQL internals, for example, while if you've learned React, it's anyone's guess as to whether or not that'll actually improve your HTML skills, for example.

I launched my first product on Product Hunt recently, and while it definitely wasn't the launch I'd imagined, it taught me a lot.

Like most first-time founders, I thought the hardest part would be finishing the product.

It wasn't.

The hardest part was getting people to discover it.

Looking back, here are my biggest takeaways:

Building a good product isn't enough. If nobody knows it exists, they can't use it. A launch lasts one day, but an audience takes months (or years) to build. I underestimated how important it is to consistently share what you're building before launch day. Comments were more valuable than upvotes. The feedback I received highlighted things I hadn't noticed while building. Marketing is a skill. I used to think marketing meant "posting a link." Now I realize it's about telling a story that makes people care. The launch wasn't the finish line. It was just another milestone.

I didn't hit the rankings I was hoping for, but I don't regret launching.

It gave me feedback, exposed weaknesses in my product and marketing, and reminded me that building a startup is a marathon, not a single event.

For those of you who've launched on Product Hunt (or any similar platform), what was the biggest lesson you learned from your first launch?

cross-posted from: https://lemmy.blahaj.zone/post/45574613

Hello, I built a CLI that gives you web links for stuff in your repo you might want to link to.

You know the situation. Your coworker checked in some real garbage and you want to politely ask what they were thinking. But now you gotta describe where the code snippet is and they have to open it in their text editor and so on. Alternatively, you could open up your Git forge's webpage and navigate to the file, copy a permalink and send it to them. Also takes quite a bit of time.

With the CLI, you can instead just paste the local file path and it gives you the permalink right away.
Similarly, you can also get a direct link to an issue or PR, which's number you might've found in a commit message.

There's a release available for download for Linux x86_64: https://codeberg.org/trem/forge/releases
And if you've got the Rust toolchain on your system, then you can also install it like so: cargo install --git https://codeberg.org/trem/forge

P.S.: The implementation is somewhat hacky, because a Git repository doesn't really know what webpage it was cloned from. So, please do let me know, if you run into any issues.

Building a small social platform. I want users to post complaints/ideas, upvote the top issues, and have devs tackle the top 3, transparently with tags, milestones or kanban to show what stage each issue is at.

Need one self-hosted FOSS tool (or two that integrate well) for both discussion and voting/prioritization.

What's your recommended stack? Zulip, Fider, Discourse, Forgejo...? Something else?

Thanks!

Somewhere in the last year, a bunch of us who hadn’t shipped real code in years quietly started shipping again. Not reviewing it. Not architecting it in a doc and handing it off. Actually building it. And loving it.

I lead software for a living. That means my days are meetings, roadmaps, hiring, unblocking people, and saying “no” a lot. The last time “writing code” was my actual job was a long time ago. I never stopped being able to code — I stopped having the time to code. At least in my day job. There’s a difference, and every engineering leader reading this feels it in their bones.

One of the main features of my site will be Discourse-style trust levels, the higher your trust level, the more moderation privileges you gain. I'm also considering either a jury system, where multiple users collaborate on moderation decisions, or a meta-moderation system, where users can vote "fair" or "unfair" on moderation actions taken.

Someone mentioned to me in another post that Bluesky also has a very good moderation system, but the best one I've found so far is Discourse. What I really like about it is that you earn trust levels by reading posts, not by taking moderation actions. I definitely don't want to gamify moderation the way Stack Overflow did, that was the worst I've ever seen.