DEV Community: SystemGlitch

Go: finally a practical solution for undefined fields

SystemGlitch — Wed, 23 Apr 2025 15:28:17 +0000

The problem

It is well known that undefined doesn't exist in Go. There are only zero values.

For years, Go developers have been struggling with the JSON struct tag omitempty to handle those use-cases.

omitempty didn't cover all cases very well and can be fussy. Indeed, the definition of a value being "empty" isn't very clear.

When marshaling:

Slices and maps are empty if they're nil or have a length of zero.
A pointer is empty if nil.
A struct is never empty.
A string is empty if it has a length of zero.
Other types are empty if they have their zero-value.

And when unmarshaling... it's impossible to tell the difference between a missing field in the input and a present field having Go's zero-value.

There are so many different cases to keep in mind when working with omitempty. It's inconvenient and error-prone.

The workaround

Go developers have been relying on a workaround: using pointers everywhere for fields that can be absent, in combination with the omitempty tag. It makes it easier to handle both marshaling and unmarshaling:

When marshaling, you know a nil field will never be visible in the output.
When unmarshaling, you know a field wasn't present in the input if it's nil.

Except... that's not entirely true. There are still use-cases that are not covered by this workaround. When you need to handle nullable values (where null is actually value that your service accepts), you're back to square one:

when unmarshaling, it's impossible to tell if the input contains the field or not.
when marshaling, you cannot use omitempty, otherwise nil values won't be present in the output.

Using pointers is also error-prone and not very convenient. They require many nil-checks and dereferencing everywhere.

The solution

With the introduction of the omitzero tag in Go 1.24, we finally have all the tools we need to build a clean solution.

omitzero is way simpler than omitempty: if the field has its zero-value, it is omitted. It also works for structures, which are considered "zero" if all their fields have their zero-value.

For example, it is now simple as that to omit a time.Time field:

type MyStruct struct{
    SomeTime time.Time `json:",omitzero"`
}

Done are the times of 0001-01-01T00:00:00Z!

However, there are still some issues that are left unsolved:

Handling nullable values when marshaling.
Differentiating between a zero value and undefined value.
Differentiating between a null and absent value when unmarshaling.

Undefined wrapper type

Because omitzero handles zero structs gracefully, we can build a new wrapper type that will solve all of this for us!

The trick is to play with the zero value of a struct in combination with the omitzero tag.

type Undefined[T any] struct {
    Val     T
    Present bool
}

If Present is true, then the structure will not have its zero value. We will therefore know that the field is present (not undefined)!

Now, we need to add support for the json.Marshaler and json.Unmarshaler interfaces so our type will behave as expected:

func (u *Undefined[T]) UnmarshalJSON(data []byte) error {
    if err := json.Unmarshal(data, &u.Val); err != nil {
        return fmt.Errorf("Undefined: couldn't unmarshal JSON: %w", err)
    }

    u.Present = true
    return nil
}

func (u Undefined[T]) MarshalJSON() ([]byte, error) {
    data, err := json.Marshal(u.Val)
    if err != nil {
        return nil, fmt.Errorf("Undefined: couldn't JSON marshal: %w", err)
    }
    return data, nil
}

func (u Undefined[T]) IsZero() bool {
    return !u.Present
}

Because UnmarshalJSON is never called if the input doesn't contain a matching field, we know that Present will remain false. But if it is present, we unmarshal the value and always set Present to true.

For marshaling, we don't want to output the wrapper structure, so we just marshal the value. The field will be omitted if not present thanks to the omitzero struct tag.

As a bonus, we also implemented IsZero(), which is supported by the standard JSON library:

If the field type has an IsZero() bool method, that will be used to determine whether the value is zero.

The generic parameter T allows us to use this wrapper with absolutely anything. We now have a practical and unified way to handle undefined for all types in Go!

Going further

We could go further and apply the same logic for database scanning. This way it will be possible to tell if a field was selected or not.

You can find a full implementation of the Undefined type in the Goyave framework, alongside many other incredibly useful tools and features.

Happy coding!

Why and how you should rate-limit your API

SystemGlitch — Thu, 27 Jun 2024 14:00:03 +0000

Opening the gates

This is it. Your shiny new product is ready to be released to the public. You worked hard for it, surely it will be a smash hit! A horde of users are impatiently waiting to try it out.

With a confident hand, you click the button. The service is live! Your analytics show that more and more users are coming in. Your advertising campaign and marketing were very effective.

As the numbers grow, you feel overwhelmed, just like your cloud infrastructure. They are simply too many. Your bug tracker starts spitting thousands of reports. Your monitoring goes from green to yellow, to red... You weren't ready for such a huge traffic. You thought you were, but that wasn't the case.

Solving the issue

No time to waste, you need to fix this. You can't let your first user experience remain so miserable. You decide to just shut down the service temporarily while you work on this. But now, nobody can use it anymore. This doesn't feel right.

💡 That's right! You need to open the gate just a little. This way you let in an amount of traffic that is manageable for your infrastructure.

The remainder will at least be informed that there is no room left for them right now. This is better than getting a terribly slow and malfunctioning experience.

Rate limiting

What you just set up is called rate limiting. It is a crucial component of every system exposed to the internet.

The idea is simple: managing traffic by limiting the number of requests within a period. That can be something like "100 requests per minute" for example.

Use cases

Rate limiting solves several problems.

Stability: by limiting the load, your infrastructure's stress is alleviated.
Cost control: one should never auto-scale without limits. You would inevitably receive an invoice from your cloud provider that would single-handedly make you go bankrupt. You know what to expect when you put clear limits on your service usage.
User experience and security: only abusive users will ever hit the rate limit if it's configured properly. This way, honest users won't have to suffer for a handful of malicious ones.
Data control: it is not unusual for any service to be visited by bots or malicious actors trying to extract all the data they have access to. Rate limiting is a great way to hinder scrapers.

Drawbacks

No solution is perfect. Rate limiting also has a fair share of drawbacks.

Complexity: behind this seemingly simple idea lies a ton of complexity. It is not that simple to set it up right. There are multiple policies you can use. You will have to carefully calculate and tweak the rate. Some applications also need to correctly handle request bursts.
User experience: It is a double-edged sword. If a user legitimately reaches the limit, they will get frustrated. It is never fun to have to stop and wait when you're very productive.
Scaling up: rate limiting needs to be constantly monitored and tweaked as you scale up. Limits may need to be increased when new features are rolled out. Do you prefer scaling your infrastructure or trying to squeeze as many users as possible until it degrades?

With that said, I would like to insist that there is no perfect way to do rate limiting. You will have to make your own choices depending on your service and your business.

Going down the rabbit-hole

Things are getting interesting, but more and more complicated. Let's dive into this rabbit hole and hopefully find out what will work best for you.

Proxy vs App rate limiting

Before anything, you should ask yourself at which level you need to setup rate limiting. There are two options here:

The proxy level allows you to rate limit users even before they actually hit your service. This is the most efficient approach when it comes to performance and security. Most cloud providers have built-in solutions to handle this for you.
The application level allows for more fine-grained control over the quotas. You can make it vary depending on if the user is authenticated or not or if it has special permissions. This even allows you to potentially monetize your API by allowing paying customers a higher limit.

Opting for both solutions can be interesting. You would use the proxy level for DDoS protection and to avoid overloading your services. And you would use the application level alongside it where some business logic comes into play.

Policies

There are many different policies that can be used to calculate the users quotas. All of them have their use-cases, so it is again up to you to pick the one that works best for you. Without going to much into details, we will see the four most common rate limit policies.

Fixed window

This policy is the simplest: the rate limit is applied within a fixed time window. Everyone has request counter that is reset every few moments. If the counter exceeds the allowed quota, the request is rejected.

Its main drawback is that it cannot handle burst traffic at all. Imagine you have a quota of 100 requests per minute. When the counters reset for everyone, potentially all your users can send 100 requests all at once.

I can also be very rigid. If the window is too long, users may have to wait a long time before being able to send requests again. If the window is too short, the benefits of rate limiting are reduced.

Sliding window

This policy is an improvement over the fixed window. In short, it tracks the requests made by one user in the last moments rather than resetting all counters all at once.

Let's say we have a window of 1 minute and a quota of 100 requests. If the user has performed less than 100 requests during the last 60 seconds, then the request is accepted. The window is therefore sliding continuously relative to the current time.

This policy is still very rigid but ensures smooth traffic.

Token bucket

The token bucket is a completely different approach. The idea is that every user has a bucket filled with a specified number of tokens. When performing a request, they take one token in the bucket. If the bucket is empty, the request is rejected. The bucket is refilled at a predefined rate until it's full again.

This policy is great for handling short burst traffic and spikes with a long-term smooth rate limiting.

Leaky bucket

The leaky bucket works a bit like a funnel. Every user starts with an empty bucket that has a hole in the bottom. The hole is more or less wide, letting only a fixed amount of requests flow for a unit of time. As the requests come in, the bucket can fill up faster than it can drain. Eventually, the bucket is full and overflows: all new requests are rejected.

In the analogy, the width of the opening at the bottom represents the rate. The depth of the bucket represents the burst.

This policy is the most flexible of all four. It can be adjusted easily depending on the traffic and also smooths out the traffic flow.

HTTP standard

At the time of writing, the closest we have to a standard for rate limiting with HTTP is this expired IETF draft.

In short, this document defines a set of HTTP headers that can be used to inform the clients of their quotas and the policy used.

Unfortunately, it is hard to know where this is going or if this has been dropped completely. This is the best we've got, so let's roll with it.

Implementation

For our example, we will work at the application level. We will use Go, redis and the leaky bucket policy. To avoid having to implement the algorithm ourselves, we will use the go-redis/redis_rate library.

Why do we need redis?

Redis is a key/value store that we will use to store our user counters. In a distributed system that can scale up to a certain number of instance, you don't want counters to be held individually by each instance. That would mean that the rate limiting is done by instance and not actually for your service, making it basically useless.

Rate limit service

Let's start by implementing an agnostic service. This way, we can use it with any framework or library easily.

Let's create a new ratelimit package, import our libraries, and setup the basis for our service:

// service/ratelimit/ratelimit.go
package ratelimit

import (
    //...
    rate "github.com/go-redis/redis_rate/v10"
    "github.com/redis/go-redis/v9"
)

type Service struct {
    limiter *rate.Limiter
    limit   rate.Limit
}

func NewService(redisClient redis.UniversalClient, limit rate.Limit) *Service {
    return &Service{
        limiter: rate.NewLimiter(redisClient),
        limit:   limit,
    }
}

Let's then expose a simple Allow() method.

// Allow checks if the given client ID should be rate limited.
// If an error is returned, it should not prevent the user from accessing the service
// (fail-open principle).
func (s *Service) Allow(ctx context.Context, clientID string) (*rate.Result, error) {
    return s.limiter.Allow(ctx, fmt.Sprintf("client-id:%s", clientID), s.limit)
}

We are using the fail-open principle. It is well suited for high-availability services, where it would be more detrimental to block all traffic than to potentially let it flow a bit too much.

For more resource-intensive operations, it would be smarter to use a fail-close approach to ensure the stability even if the rate limiting fails.

Now, we can also implement a simple method that would update the response headers according to the IETF draft previously mentioned.

// UpdateHeaders of the HTTP response according to the given result.
// The headers are set following this IETF draft (not yet standard):
// https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers
func (s *Service) UpdateHeaders(headers http.Header, result *rate.Result) {
    headers.Set(
        "RateLimit-Limit",
        strconv.Itoa(result.Limit.Rate),
    )

    headers.Set(
        "RateLimit-Policy",
        fmt.Sprintf(`%d;w=%.f;burst=%d;policy="leaky bucket"`, result.Limit.Rate, math.Ceil(result.Limit.Period.Seconds()), result.Limit.Burst),
    )

    headers.Set(
        "RateLimit-Remaining",
        strconv.Itoa(result.Remaining),
    )

    headers.Set(
        "RateLimit-Reset",
        fmt.Sprintf("%.f", math.Ceil(result.ResetAfter.Seconds())),
    )
}

Finally, we need to identify our users. For unauthenticated users, it can be tricky. Usually, you then rely on the client's IP. It's not perfect but sufficient most of the time.

// GetDefaultClientID returns the client IP retrieved from the X-Forwarded-For header.
func (s *Service) GetDefaultClientID(headers http.Header) string {
    // X-Forwarded-For: <client-ip>,<load-balancer-ip>
    // or
    // X-Forwarded-For: <supplied-value>,<client-ip>,<load-balancer-ip>
    // We only keep the client-ip.
    parts := strings.Split(headers.Get("X-Forwarded-For"), ",")
    clientIP := parts[0]

    if len(parts) > 2 {
        clientIP = parts[len(parts)-2]
    }

    return strings.TrimSpace(clientIP)
}

⚠️ This header format is the one used by Google Cloud load balancers. This can be different depending on your cloud provider.

We can now create an instance of our service like so:

opts := &redis.Options{
    Addr:       "127.0.0.1:6379",
    Password:   "",
    DB:         0,
    MaxRetries: -1, // Disable retry
}
redisClient := redis.NewClient(opts)
ratelimitService := ratelimit.NewService(redisClient, rate.PerMinute(200))

Of course, ideally we would not hardcode all those settings. Making them configurable with a config file or environment variables would be best. This is however out of the scope of this article.

Middleware

Now that we are done with the rate limit service, we need to put it to use in a new middleware.

For this example, we are going to use the Goyave framework. This REST API framework provides a ton of useful packages and encourages the use of a strong layered architecture. We'll take the blog example project as a starting point.

Registering our service

The first step is to add a name to our rate limit service.

// service/ratelimit/ratelimit.go
import "example-project/service"

func (*Service) Name() string {
    return service.Ratelimit
}

// service/service.go
package service

const (
    //...
    Ratelimit = "ratelimit"
)

Then let's register it in our server:

// main.go
func registerServices(server *goyave.Server) {
    server.Logger.Info("Registering services")

    opts := &redis.Options{
        Addr:       "127.0.0.1:6379",
        Password:   "",
        DB:         0,
        MaxRetries: -1, // Disable retry
    }
    redisClient := redis.NewClient(opts)
    ratelimitService := ratelimit.NewService(redisClient, rate.PerMinute(200))

    server.RegisterService(ratelimitService)
    //...
}

ℹ️ You can find the documentation explaining how services work in Goyave here.

Implementing the middleware

Let's set up the basis for our middleware. We'll first create a new interface that will be compatible with our rate limit service, and use it as a dependency of our middleware.

// http/middleware/ratelimit.go
package middleware

import (
    "context"
    "net/http"

    "goyave.dev/goyave/v5"

    "github.com/go-goyave/goyave-blog-example/service"
    rate "github.com/go-redis/redis_rate/v10"
)

type RatelimitService interface {
    Allow(ctx context.Context, clientID string) (*rate.Result, error)
    GetDefaultClientID(headers http.Header) string
    UpdateHeaders(headers http.Header, result *rate.Result)
}

type Ratelimit struct {
    goyave.Component
    RatelimitService RatelimitService
}

func NewRatelimit() *Ratelimit {
    return &Ratelimit{}
}

func (m *Ratelimit) Init(server *goyave.Server) {
    m.Component.Init(server)
    ratelimitService := server.Service(service.Ratelimit).(RatelimitService)
    m.RatelimitService = ratelimitService
}

Now let's implement the actual logic of our middleware. We want our authenticated users to have a quota of their own, and our guest users to be identified by their IP.

func (m *Ratelimit) getClientID(request *goyave.Request) string {
    if u, ok := request.User.(*dto.InternalUser); ok && u != nil {
        return  strconv.FormatUint(uint64(u.ID), 10)
    }

    return m.RatelimitService.GetDefaultClientID(request.Header())
}

We just have the Handle() method left to implement:

import (
    //...
    "goyave.dev/goyave/v5/util/errors"
)

func (m *Ratelimit) Handle(next goyave.Handler) goyave.Handler {
    return func(response *goyave.Response, request *goyave.Request) {
        res, err := m.RatelimitService.Allow(request.Context(), m.getClientID(request))
        if err != nil {
            m.Logger().Error(errors.New(err))
            next(response, request)
            return // Fail-open
        }

        m.RatelimitService.UpdateHeaders(response.Header(), res)

        if res.Allowed == 0 {
            response.Status(http.StatusTooManyRequests)
            return
        }
        next(response, request)
    }
}

Finally, let's add it as a global middleware, just after the authentication middleware.

// http/route/route.go

func Register(server *goyave.Server, router *goyave.Router) {
    //...
    router.GlobalMiddleware(authMiddleware)

    router.GlobalMiddleware(middleware.NewRatelimit())
    //...
}

ℹ️ You can find the documentation explaining how middleware work in Goyave here.

One last thing

Wait! There is one problem with this. The rate limit middleware won't be executed if the authentication fails. Let's extend the auth.JWTAuthenticator to handle this case. We just have to make it implement auth.Unauthorizer. This interface allows custom authenticators to define a custom behavior when authentication fails. The idea is to execute the rate limit middleware even if the auth one blocks the request.

Let's create a new custom authenticator that will use composition with auth.JWTAuthenticator:

// http/auth/jwt.go
package auth

import (
    "net/http"

    "goyave.dev/goyave/v5"
    "goyave.dev/goyave/v5/auth"
)

type JWTAuthenticator[T any] struct {
    *auth.JWTAuthenticator[T]
    ratelimiter goyave.Middleware
}

func NewJWTAuthenticator[T any](userService auth.UserService[T], ratelimiter goyave.Middleware) *JWTAuthenticator[T] {
    return &JWTAuthenticator[T]{
        JWTAuthenticator: auth.NewJWTAuthenticator(userService),
        ratelimiter:      ratelimiter,
    }
}

func (a *JWTAuthenticator[T]) OnUnauthorized(response *goyave.Response, request *goyave.Request, err error) {
    a.ratelimiter.Handle(a.handleFailed(err))(response, request)
}

func (a *JWTAuthenticator[T]) handleFailed(err error) goyave.Handler {
    return func(response *goyave.Response, _ *goyave.Request) {
        response.JSON(http.StatusUnauthorized, map[string]string{"error": err.Error()})
    }
}

We now need to update our routes:

// http/route/route.go

import (
    //...
    customauth "github.com/go-goyave/goyave-blog-example/http/auth"
)

func Register(server *goyave.Server, router *goyave.Router) {
    //...
    ratelimiter := middleware.NewRatelimit()

    authenticator := customauth.NewJWTAuthenticator(userService, ratelimiter)
    authMiddleware := auth.Middleware(authenticator)
    router.GlobalMiddleware(authMiddleware)

    router.GlobalMiddleware(ratelimiter)
}

ℹ️ You can find the documentation explaining how authenticators work in Goyave here.

Rate limit in action

We are done! Let's test this.

Before that, we need to add a redis container in the docker-compose.yml:

services:
  #...
  redis:
    image: redis:7
    ports:
      - '127.0.0.1:6379:6379'

Start the application as explained in the README:

docker compose up -d
dbmate -u postgres://dbuser:secret@127.0.0.1:5432/blog?sslmode=disable -d ./database/migrations --no-dump-schema migrate
go run main.go -seed

Let's query our server with our trusty friend curl:

curl -v http://localhost:8080/articles

Result:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Content-Type: application/json; charset=utf-8
Ratelimit-Limit: 200
Ratelimit-Policy: 200;w=60;burst=200;policy="leaky bucket"
Ratelimit-Remaining: 198
Ratelimit-Reset: 1
Date: Thu, 27 Jun 2024 12:47:08 GMT
Transfer-Encoding: chunked

{"records":[...

We can see our RateLimit headers. Success!

Conclusion

You can finally open the gates (a little) once more and let everyone enjoy your awesome new product without issues or slowdowns.

In the process, you learned all you need to know about in order to get started with rate limiting. Despite not being perfect, this solution is greatly effective! Don't forget to closely monitor your services from now on, and make adjustments to your limits accordingly.

Check out the Goyave framework ! It can help you build better APIs faster in so many ways thanks to its many features such as routing, validation, localization, model mapping, and much, much more.

Let's talk! Was this article useful to you? Do you have anything to add or correct? Or maybe you have an interesting experience to share with us. I'll see you in the comments. Thank you for reading!

Goyave v5: the reborn REST framework aims higher

SystemGlitch — Thu, 13 Jun 2024 10:00:05 +0000

Over two years in the making, Goyave’s next major release is finally available. This time, it’s not just about a breaking change: the framework has been entirely redesigned and rewritten. Let’s talk about this rebirth and what it entails.

But first, what is Goyave?

Goyave is an opinionated REST API framework for the Go programming language. Its initial goal was to make backend development easier and concise so applications can be developed fast and cleanly. Using the framework would allow developers to focus on their business logic rather than technical aspects. Despite being filled with powerful tools, it tried to stay as accessible as possible.

That’s a bit too much isn’t it? Indeed, there were contradictions in the design, leading to many shortcomings. Ultimately, the framework failed to deliver on its most important promises. Each of its features both contributed positively to one of the principles while negatively impacting another.

With v5, the design is refocused and takes some important new directions.

New direction

Goyave has new commitments that are now fully assumed. The first is the target: instead of trying to please everyone and suit every need from prototype to real application, the framework now focuses on medium to large enterprise projects with real-world constraints.

The architecture recommendations and related utilities are taken one step further to eliminate dependency coupling, make testing easier, and streamline the development process.
Conciseness is not an absolute requirement anymore, making programs and syntax a bit more verbose, but way more flexible. In other words, the “progressive” aspect is abandoned in favor of a more “clean code” oriented approach, trading simplicity for scalability.

Introducing v5

v5 is an almost entire rewrite of the framework containing all the accumulated ideas for rework and improvements that would introduce breaking changes. This new major version not only aims at fixing the outstanding issues and design flaws, but also improves on existing features by upgrading them to the latest available technology. Expect v5 to feel modern and to neatly integrate with all the new language features such as generics, file systems, structured logging, and more.

This new release is way too large to be discussed in detail here. If you are interested, feel free to read the official changelog.

Building a community

Despite several production applications made and running with it, the framework still has a relatively small community. More efforts will be made to gather and take care of a growing and strong community, which is very important for open-source projects.

You can help! Join the Discord server, give your feedback on Github discussions, create issues, share this article. All contributions are welcome and very valuable.

If you feel like it, you can even help develop the framework further by opening a Pull Request. Plenty of good first issues are available to get you started.

Open source super-charged my career

SystemGlitch — Tue, 11 Jun 2024 15:06:58 +0000

Contributing is more valuable than you may think

At the time of writing, I am less than thirty years old, and I have a tech lead position in one of Europe's fastest-growing startups, according to the Financial Times's FT1000 ranking. This company found me and hired me immediately when I graduated. Yes, it is my first full-time job after being an apprentice. How did I get this far this quickly?

I'll give you that, there is an amount of luck involved, but luck is not enough. I worked hard and made the good decisions without even realizing it. With the benefit of hindsight, I want to share with you today what I think was the key to my success.

That key is my involvement in open source. At first I simply liked the ideology and the ecosystem, so I wanted to participate. I didn't know how important this would become for my future success. With time and contributions adding up, I acquired an extremely valuable experience that got me noticed.

Let's talk about the real value of open source contributions, and how you could benefit from it too.

The value

Having experience with open source development greatly changes how recruiters, tech literate or not, perceive your profile and skills. But it's not just for show! You actually acquire very valuable knowledge and skills by contributing to open source. Let's take a look at how it can help you stand out.

The “big = good” effect

Having contributed to large libraries, or code belonging to big companies will get you a lot of attention. Whether it's true or not, it makes people think of you as more skillful. The effect is justified for several reasons.

Contributing to wide-spread codebases and getting your code merged indicates that you can provide serious and quality work. Usually, these repositories have certain standards of quality. To help maintainers handle a large amount of contributions, these repositories also have quite strict processes and requirements. And they can vary a lot from one community to another. A merged contribution shows that you have the ability to adapt to a workflow. It is a great soft skill to have.

If you contribute to open-source repositories owned by large companies such as Google or Microsoft, the effect is amplified. It feels prestigious, just like telling anyone "you work(ed) at Google" is enough for you to instantly gain their respect. Moreover, it is often thought that these codebases are of exceptional quality because of the prestige associated with the company.

Having a good amount of contributions showcased on your resume has an effect just as important as the rest of your experience.

Experience

To elaborate a little bit more on the previous point, contributing to open source projects gives you a kind of experience that you don't get anywhere else. You acquire knowledge that can be valuable inside a company.

Communication

First, you are able to work with complete strangers you've never spoken to. Open source is always operated asynchronously via text. It is even more important to be able to clearly express yourself and be understood. You can't just take a meeting room for a few minutes with your colleague and clear things up here.

You also are able to justify your changes and decisions. Most maintainers won't blindly merge your changes. You will have to clearly explain use cases, performance implications, and generally why and how you made your changes.

Dependability

If you are a maintainer, it's even better. You are expected to know how to carefully review pull requests. You are considerate and think about all the possible impacts of the proposed changes. You care about your package and you wouldn't want bad or broken code to be added to it. If you can do that for your projects, you can also do it for the company's projects.

Technical skills

Soft skills are great, but let's talk about the hard ones too. Contributions come from many possible situations. Maybe you are using a library and you found a bug or missing feature. Or maybe you noticed an interesting project and wanted to participate. Either way, it means that you have the ability to dig out and understand someone else's code. You have a strong understanding of the underlying mechanisms of everything you are using. It's very likely that you will be very good at troubleshooting.

Workflow

Bouncing back on what's been said in the previous section, the experience with open source processes can also be valued greatly. They are often associated with good practices such as aggressive linters, mandatory tests and coverage, and more. Some elements of open sources processes could be well integrated into internal ones. Having real experience in this field is quite rare and could bring significant technical value to a team.

Personal satisfaction

This one is indirectly valuable to recruiters. The satisfaction is all yours. However, fixing a bug in a library that is used by millions of people around the world is gratifying. This pride can be felt by recruiters during an interview.

I know recruiters can be a bit out of touch with the reality of the job sometimes. But they know that a happy and proud developer is more productive and generally more involved. They are inclined to go further than the bare minimum.

Getting started

Submitting your first contributions can be intimidating. You shouldn't be worried though. There are good ways to get started and begin your open source journey.

Finding a task

The first thing to do is identify which project you want to contribute to. You are using a lot of libraries, tools and software every day. It is very likely a good amount of them are open source.

Next, find something to do. If you found a bug in one of the software you are using, check the issues section and see if it has been reported already. If not, try to fix it! It so happens that most of the developers I know that contribute to open source started with a simple bug fix. It's a great way to break the ice.

You may also have an idea for a new feature for those tools, something that could be very handy. Has it been suggested already? You can probably add it.

Whatever you choose, all those projects will no doubt have open issues. Browse through them and see if you can find one that you could tackle. A lot of projects tag issues with "Good first issue". Those issues usually are quite easy to solve and perfect for new contributors.

Fulfill a need

If you are feeling inspired, create your own tool or library and share it! You're going to need to be creative though, as solutions may already exist. Please don't create another pointless Javascript "calculator" library. For the project to have credibility, you don't want it to look like a toy project.

Try to find a hole in an ecosystem. It happened to me when I started working on my biggest project: Goyave. At the time, I couldn't find anything that suited my exact needs and how I wanted things to be. So I decided to create my own solution, and add this missing piece to the ecosystem. This is the project that allowed me to reach my very comfortable position today. I wish it could benefit other people too, so I created a bunch of good first issues that I invite you to check, and solve if you feel like it.

Conclusion

Contributing to open source is a real asset in your career. The sheer amount of soft and hard skills it brings you are noticeable and actually valued by companies. They will help you find a job and rise to a better position quickly. Talk about all the things open source brought to you on your resume and in your interviews, and I can guarantee you that it will give you an edge.

What's so great about this, is that you also take part in something bigger than all of us in the process. Open source is a fantastic way of benefiting from the skills and experience of each individual, and sharing yours as a return.