Forem: Ashutosh Kumar

Don't chase GSoC, Chase open source

Ashutosh Kumar — Sun, 14 Dec 2025 18:57:14 +0000

✦ If you're doing 𝗚𝗦𝗼𝗖 only for the stipend, 𝗜 𝗵𝗼𝗻𝗲𝘀𝘁𝗹𝘆 𝘄𝗶𝘀𝗵 𝘆𝗼𝘂 𝗴𝗲𝘁 𝗳𝘂𝗰𝗸𝗲𝗱 𝘂𝗽 𝗯𝘆 𝗿𝗲𝗷𝗲𝗰𝘁𝗶𝗼𝗻. Because, GSoC doesn’t make you good at open source.

✦ 𝗢𝗽𝗲𝗻 𝘀𝗼𝘂𝗿𝗰𝗲 𝗺𝗮𝗸𝗲𝘀 𝘆𝗼𝘂 𝘄𝗼𝗿𝘁𝗵𝘆 𝗼𝗳 𝗚𝗦𝗼𝗖.

Most of you haven’t contributed to a single open source organization or open source project, not even built one real world project, and yet people have flooded my 𝗗𝗠𝘀 with:

“How do I crack GSoC?”
“Which org is easiest to crack?”
“Send me your proposal so I can crack it too.”
“How much stipend will I get if I contribute?”
“Any shortcut to get selected?”

I’m tired of this word: 𝗖𝗥𝗔𝗖𝗞.
There is nothing to crack.

Open source is not:
• 𝗔𝗻 𝗲𝘅𝗮𝗺
• 𝗔 𝗝𝗘𝗘 𝗽𝗮𝗽𝗲𝗿
• 𝗔 𝗻𝗼𝘁𝗲𝘀-𝗯𝗮𝘀𝗲𝗱 𝘀𝗵𝗼𝗿𝘁𝗰𝘂𝘁
• 𝗔 𝗠𝗔𝗔𝗡𝗚 / 𝗙𝗔𝗔𝗡𝗚 𝗶𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄

People think GSoC is some shortcut program:
Contribute using AI.
Copy a PR.
Get selected.
Take the money.
Flex the certificate.

That mindset is fucking bullshit.

𝗬𝗲𝘀, 𝗚𝗦𝗼𝗖 𝗵𝗲𝗹𝗽𝘀 𝘆𝗼𝘂𝗿 𝗿𝗲𝘀𝘂𝗺𝗲.
𝗕𝘂𝘁 𝗵𝗲𝗿𝗲’𝘀 𝘁𝗵𝗲 𝘂𝗻𝗰𝗼𝗺𝗳𝗼𝗿𝘁𝗮𝗯𝗹𝗲 𝘁𝗿𝘂𝘁𝗵:

👉 With this “crack mentality”
You probably won’t even get selected and even if you do, you’ll hate the process.

So if you’re aiming for GSoC 2026, pause and rethink:

𝗪𝗵𝘆 𝗱𝗼 𝘆𝗼𝘂 𝘄𝗮𝗻𝘁 𝗶𝘁?
For the badge?
For the fucking LinkedIn validation?
For the stipend?

If you’re doing it just for this,
you’re going to get fucked out, my dear.

𝗕𝘂𝘁 𝗶𝗳 𝘆𝗼𝘂 𝘄𝗮𝗻𝘁 𝘁𝗼:
build real things
solve real problems
learn how real software is made

𝗧𝗵𝗲𝗻 𝗳𝗼𝗿𝗴𝗲𝘁 𝗚𝗦𝗼𝗖 𝗳𝗼𝗿 𝗮 𝗺𝗼𝗺𝗲𝗻𝘁.
Start contributing now, to any open source organization or project.

𝗗𝗼𝗻’𝘁 𝗰𝗵𝗮𝘀𝗲 𝗚𝗦𝗼𝗖. 𝗖𝗵𝗮𝘀𝗲 𝗢𝗽𝗲𝗻 𝗦𝗼𝘂𝗿𝗰𝗲. Everything else follows.
GSoC is just a part of open source, not the whole thing.

𝗜 𝘄𝗮𝘀 𝗮𝗰𝘁𝗶𝘃𝗲 𝗶𝗻 𝗼𝗽𝗲𝗻 𝘀𝗼𝘂𝗿𝗰𝗲 𝗯𝗲𝗳𝗼𝗿𝗲 𝗜 𝗲𝘃𝗲𝗻 𝗰𝗮𝗿𝗲𝗱 𝗮𝗯𝗼𝘂𝘁 𝗚𝗦𝗼𝗖.
• In 2022, I was an intermediate dev, building small projects.
• In 2023, I started building fullstack projects and became active in the open-source community.
• In 2024, I built 35+ real world projects, stayed obsessed, and still didn’t get selected.
• In 2025, I finally became part of GSoC.

So, I survived only because I love building things, I love open source, not because I followed some fucking “crack guide.”

𝗦𝗼 𝗺𝘆 𝗱𝗲𝗮𝗿,
Stop chasing programs.
Stop cracking.

Start just fucking building, building, & building.

Because, 𝗢𝗽𝗲𝗻 𝗦𝗼𝘂𝗿𝗰𝗲 is a way of building and innovating together through collaboration.

https://www.linkedin.com/in/ashutoshkumaraashu/

It’s official ✦ Google Summer of Code 2026 is coming

Ashutosh Kumar — Thu, 04 Dec 2025 11:42:12 +0000

It’s official ✦ Google Summer of Code 2026 is coming

🗓 Key dates:
Applications open: March 16, 2026
Applications close: March 31, 2026

And if you are still planning to “start in March”… you’re already late.

The application period is NOT the preparation period.

As a GSoC 2025 contributor, I’ve seen firsthand how much this program can accelerate your learning, network, and career. It was a turning point for me, and I want more people from my network to experience that.

Here’s what I’d do if I were starting today for GSoC 2026:

1️⃣ Start TODAY, not in March
Don’t wait for the official org list.
Most orgs participate every year.
Pick 2–3 orgs & start exploring their ecosystem and see which ones align with your skills (web dev, systems, ML, security, etc.).

2️⃣ Observe before you contribute
Join their Slack, Discord, IRC, GitHub discussions, whatever they use.
Just watch how they talk, how they solve issues, how PRs are reviewed.
This will teach you more than any YouTube “GSoC roadmap” video.

3️⃣ Start with “small but visible”
Fix a typo.
Improve a README.
Refactor a tiny function.
Add missing documentation.
A “good first issue”
It’s not about “showing skills”…
It’s about showing you can collaborate.
These get your name on the board and show you are active.

4️⃣ Think in terms of a proposal from day one
While you contribute, keep a running document of:
Problems you notice in the project
Possible improvements
Links to your PRs and discussions
Good proposals don’t come from templates.
They come from actually understanding the codebase, talking to mentors, and solving real issues.

✦ If you’re serious about GSoC 2026…
Let's connect on LinkedIn: https://www.linkedin.com/in/ashutoshkumaraashu/
I’ll also be sharing more resources, templates, and my honest learnings from GSoC 2025 very soon.

The One Advice I'd Give My Past Self: Build Boring Sh*t That Sells

Ashutosh Kumar — Thu, 18 Sep 2025 13:22:32 +0000

I’ve been building products and running startups for years now, 50+ production-ready apps, a creative agency, and now my global developer platform & community DevDisplay.

If I could go back and give my younger self one piece of advice, it would be this:
Stop trying to build something “revolutionary.” Start building things people already pay for and make them better.

This sounds boring, right? We all want to be “that founder” - the one who changes the world, disrupts industries, and raises millions. But here’s the harsh truth I learned:

Your landlord doesn’t accept GitHub stars as rent. Your team can’t eat “innovation.”

I learned this the hard way with one of my first startups. We spent months building something no one had seen before. Guess how many paying customers we had after launch? Zero.

Then I started building what I call “boring sh*t that scales” - products in proven markets. The result? Paying customers, clear growth, and a business that could actually survive. That mindset became the DNA of DevDisplay’s business model (Platform + Community + Labs).

Why “Boring” Wins - and Why DevDisplay Exists

When you see 50 project management tools out there, that’s not a signal to stay away. That’s a green light. It means people are already spending money there.

That’s why I built DevDisplay - not as a “new category” but as a better solution for an existing pain:

Developers already join communities.
Developers already look for opportunities, jobs, hackathons, and collaborators.
Developers already showcase projects - just scattered everywhere (LinkedIn, GitHub, Discords).

DevDisplay simply brings all of that together - one platform where developers can discover, connect, collaborate, and promote their work.

This is exactly the advice I wish I gave myself earlier: don’t try to convince the world to behave differently - just build something that fits their existing behavior and solves their frustration better.

The Math Still Works

Let’s be brutally practical.
Want to make \$10K/month?

You can gamble on something no one understands, spend a year building it, and pray.
Or you can find a market where thousands already pay and just get 1-2% of them.

With DevDisplay, even a small slice of the global developer market (20M+ developers worldwide) is enough to build a sustainable, profitable organization - and then invest in DevDisplay Labs, where we can finally experiment with moonshot ideas.

How I Apply This Playbook at DevDisplay

Here’s what I personally do now (and what I’d tell any indie hacker):

Pick Proven Markets – I look for areas where money already flows. Developer platforms, hiring tools, collab spaces. ✅
Find Gaps – DevDisplay didn’t copy LinkedIn or GitHub. We built for indie hackers, students, open-source builders - the ones big platforms ignore.
Ship Fast – Every feature on DevDisplay has an MVP phase. If we can’t build it in 4-6 weeks, we cut scope.
Charge Early – Even with free features, we have real monetization in mind (Labs, Promotion, Community Benefits).
Use Community Feedback as Roadmap – DevDisplay itself is shaped by contributors and users — they literally tell us what to build next.
Double Down – When a feature or campaign works (like hackathon boards or collab requests), we scale it hard.

Final Thought: Stability Before Moonshots

Yes, I still dream about building wild, world-changing products. But first, I need stability. I need to make sure DevDisplay survives and grows before we try to “reinvent” developer collaboration.

So here’s my advice to any builder reading this - and my past self:

✅ Build boring sh*t that sells.
✅ Make it useful for real people right now.
✅ Reach \$10K MRR.
✅ Then - and only then - start changing the world.

That’s exactly how DevDisplay was born.

Awesome Next.js API Routes with next-api-decorators

Ashutosh Kumar — Tue, 03 Jun 2025 19:08:37 +0000

Building a modern Web application can be a complex task - it's likely that if you're looking to build something you'll start thinking about architecture, and how to separate your concerns, and that there are many ways that can be done. Traditionally speaking, this means having a separate frontend and backend, with separate codebases, maybe using different languages, frameworks, or technologies in order to get the job done.

In this article, we'll look at an alternative using something wonderful from the world of frontend development: Next.js. We'll look at how a monolithic architecture can be convenient and powerful, without necessarily suffering from the tight coupling usually linked with this approach. But first, a quick primer on how Next.js works.

How Next Works

If you're new to this tech, Next.js is a Jamstack framework, designed to solve some of the problems associated with building traditional Single Page Apps (SPAs). Not only does it support Server-Side Rendering, but also Static Site Generation, allowing developers to build apps with some static pages (think marketing / about pages!) and some dynamic pages that load super quick and are SEO-friendly. Depending on your use case, you can usually get Next.js to suit your needs, with very few caveats.

To put it briefly, this works because when you "run" a Next.js app, you're actually running a Node.js server (though if you're building a completely static site, you can just export all the static files and host them wherever, but we won't be talking about that approach here). As a result, your app is 'alive', in contrast with e.g. a Create React App, where a JS bundle is hosted somewhere and downloaded to the client where the whole app is rendered only on the client side.

So what?

As a result of this, it's possible to define some code that only ever runs on the server, that the client will never see. It's starting to look like given that we have server-side-only code, we could maybe start doing some stuff that we couldn't (more like shouldn't) do before on the client, e.g. talk to a database directly, perform operations that require several separate calls, etc. Isn't this starting to sound like an HTTP API?

Next.js supports this concept as a first-class citizen in its architecture. Routing is opinionated, and uses the filesystem to determine page routes in your app, using files and folders in a directory called pages to establish this - e.g. if you create a file in pages/todos called mine.tsx you'd be able to find the page in your browser at <your-domain>/todos/mine. Anything under the path pages/api will only run on the server. There we have it! What we refer to as Next API Routes. This now means we can build a full-stack application with a single codebase, a "monolithic" architecture. Right off the bat we get several nice-to-haves for free:

✦︎ Single build process & easy-to-run dev environment for whole app ( just run next dev )
✦︎ Simpler deployments ( next build then next start in any node-compatible environment )
✦︎ No CORS worries by default, the frontend and backend are on the same origin!
✦︎ Monorepo-like sharing by default ( think same tsconfig, jest, eslint ) without having to use monorepo managers like lerna

More experienced developers may see an approach like this as a step backwards, but it's arguable more like a step towards better consolidation of code & resources. Logical concerns can be separated without physical separation itself, and a monolithic architecture is beginning to make more sense for Web apps, most notably with the rise of Incremental Static Regeneration and Server Side Rendering.

API Routes

As listed in the documentation, building API routes with Next looks a lot like building a basic API with Node.js:

Nice and simple. You can use this approach to very quickly and simply build out some server-side functionality!

But what if we wanted to start building a REST API, differentiating between different HTTP methods on the same endpoint, modelling our API in terms of resources? What if we wanted to start composing behavior into our API endpoints?

Our example quickly swells to something like this:

And that's probably the best case, as we've been able to factor out all the actual business logic into the functions doSomething, checkAuth, doSomethingElse and doAThirdThing. It'd likely get worse once we'd start getting request bodies etc. Not terrible, but we can likely make this a little easier to read, and a little easier to maintain.

NestJS

Often, developers opt for a framework when building out APIs, as they offer alternative means of representing resources, and many tools and utilities designed to make this process easier. One such example is NestJS (Not to be confused with Next.js!). This is a batteries-included, powerful "framework for building efficient, scalable Node.js server-side applications". Heavily inspired by Angular, this framework allows developers to use abstractions to represent API routes, including reusable services, controllers, modules and more.

Here is a simple example copied from its documentation:

As we can see, this approach uses OOP ideas and decorators to achieve the goals described previously. We specify only the HTTP methods we intend to make available as methods on a class, instead of control flow paths in a function. A little more declarative, and a great foundation if we're looking build out a REST API.

So how do we make use of this approach for Next.JS API Routes?

next-api-decorators

This library was created by me, Ashutosh Kumar, while building DevDisplay ✦︎ A global vision on a mission to become the next billion-dollar company in the tech industry. I developed this solution to simplify and scale API development in Next.js by applying a more structured, declarative approach. Let’s revisit our earlier complex example, now rewritten using nextjs-api-decorators, to demonstrate how this approach works in practice:

As we can see, we have changed the way we express our resource handler, swapping a function for a class. On top of this, methods of the class are annotated with decorators to express their purpose.

Now, it's up to you which you prefer, as it's not as if this approach makes it much more concise. But it does, as mentioned earlier, transform our approach to describing our resources from an imperative one to a declarative one. I have found while building Next.js APIs out that this approach is a good deal easier to maintain, as eventually each route and each handler can and will get more complex as your application grows.

Custom Decorators

The last thing I wanted to look at from this example is the requiresAuth decorator we see on some of the methods in this handler now. I wrote something like this custom handler for a project recently, and it's proven very useful. This is done using the createMiddlewareDecorator utility provided by next-api-decorators:

Pretty strong stuff 💪

This approach is very flexible and can be applied to both classes and their methods to fit a variety of use cases and declutter your actual business logic.

Wrapping Up

The example I've shown here is very simple and just to give you an idea of the a practical monolithic approach to building a full-stack application using Next.js and its API routes, and how it can be made scalable server-side using next-api-decorators.

If you're interested in learning more, check out the documentation and repo for this amazing library.

Thanks for reading!

💙

Imagine The Space Where All Tech Opportunities Await You!

Ashutosh Kumar — Sun, 06 Apr 2025 12:52:31 +0000

DevDisplay - Paradise For Developers!

One Platform for Global Developers to Fulfill All The Tech Needs!

Imagine The Space Where All Tech Opportunities Await You!

💡Jobs that valid
💡Internships that Launch Careers.
💡Freelancing that fuels freedom.
💡Hackathons that Push Your Limits.
💡Competitions that Challenge the Best.
💡Certifications that Truly Matter.
💡Bootcamps that Build Real Skills.
💡Tech Events that Connect & Inspire.
💡Tech Fests that Spark Innovation.
💡Tech Conferences that Expand Minds.
💡Meetups that Turn Into Collaborations.
💡Open Source Contributions that Get You Noticed.

You're Either On It - Or Behind It. #StayTuned!

𝗗𝗲𝘃𝗗𝗶𝘀𝗽𝗹𝗮𝘆 𝘃𝟮.𝟬 Hits Different - Just Remember The Word "𝗣𝗮𝗿𝗮𝗱𝗶𝘀𝗲"

💡Dropping ON April 17, 2025 at 10AM

DevDisplay - Paradise For Developers!

Ashutosh Kumar — Sun, 06 Apr 2025 12:48:21 +0000

Connect ▸ Collab ▸ Code ▸ Create ▸ Conquer

The First Global Platform for Developers to Fulfill All Their Tech Needs.

⚡Imagine One Platform for Global Developers to Fulfill All The Tech Needs! ⚡

💡Whatever you need as a developer, DevDisplay has it all.

Opportunities
Resources
Project Showcase
Portfolio Ideas
Resume Building
AI Tools Hub
Industry Trends
AI Career Guide
Portfolio Builder
Idea Submission
Journey Showcase
Design Display
Dev Discussions
DevDisplay UI Library
DevDisplay Compiler
DevDisplay Competitions
Developer Marketplace
DevDisplay Ecommerce

💡We believe innovation is limitless...✦

Suggest new features you'd love to see on DevDisplay! As a tech enthusiast and developer, you're encouraged to think beyond—think outside the box. Suggest and add new, innovative features that could revolutionize the tech world and make a difference in the tech ecosystem. If you spot a gap in the tech industry, DevDisplay can be the solution. You can also give us brutal and honest feedback—Roast Us! It helps us improve and make DevDisplay even better. Here, your ideas matter, your code matters—you matter.

Developers let’s enter to the Paradise - DevDisplay

Biggest Open Source Contribution

Ashutosh Kumar — Wed, 18 Sep 2024 10:34:50 +0000

https://devdisplay.vercel.app/

Hello everyone!

We invited you to the Biggest Open Source Contribution.

Contribute on this Open Source project It's easy just add profile here.

I waiting for your pull request on GitHub

Thanks!