The prevalence of OpenSource software is undeniable. If a software developer tells us that he/she has never do anything involving OpenSource Software (OSS), we’re probably looking at a time traveler from when the Internet didn’t exist!

Time and time again, the benefits of adopting and contributing to Open Source Software are highlighted. Nevertheless, there’s little to no literature to how an organisation can properly adopt and contribute to Open Source Software. A quick Google search would mainly show guides on how individuals can get started contributing to Open Source projects without anyone mentioning how we can do it efficiently at an organisational level and build a culture around Open Source.

This post will outline our attempt at Xendit so far trying to build a model, and in turn — a culture, around Open Source contributing.

Challenges at Xendit

We didn’t started building a model of contributing to InnerSource out of the blue. It actually came from a real need for us to deal with legacy code.

It all started with Xendit’s usage of micro-service architecture with the best of intentions: We want folks to be able to “move fast and break things”, to develop and deliver more features, more payment channels without stepping on one another’s toes.

Under this ownership model, there were a lot of common “utils” repositories born out of necessity, without much thoughts and considerations in place, as folks need a quick way to share code across different codebases.

Fast forward to the next growth stage of our engineering organisation, we have evolved to have proper teams with clear responsibilities and boundaries over specific codebases depending on the product

But this also mean that we end up with a bunch of “orphan” utilities repositories, which are ironically used by almost everyone in their codebases and capable of bringing about critical system issues if errors seep in. We actually got bitten by these problems more than a few times and decided to do something about it.

Tackling the “everybody’s business” problem

As the saying goes — “Everybody’s business is nobody’s business”, it’s natural, however detrimental and painful, for our folks to leave these critical pieces of our system unattended and only patch them when they break down our systems.

So we took a step back and a good bird-eye-view look of the whole system. These common modules play somewhat a similar role to external libraries like ExpressJS. This inspired us to figure out what we were lacking that made all the difference. We identified 2 missing pieces of the puzzles:

• There’s a lack of recognitions and rewards: Usually for Open Source projects, especially ones that are widely used, to which contribution gives developers “street cred” and respect from their peers. And with recent push in Open Source funding like Github Sponsors, there’re actual monetary incentives to writing free softwares.
• There’s also a lack of ownership: It’s common for Open Source libraries to be started by someone with a rather personal and specific need for their projects, then slowly evolve into a proper maintainer group and sometimes even an entire foundation. In any cases, the projects hit close to home.

So how can we emulate the same incentives for Xendit common codebases? How should we adapt the Open Source model into our organisation structure.

Open Source @ Xendit

To solve the above two problems, we came up with a system to reward engineers for their effort and a clear structure for taking on maintainer’s responsibilities.

Incentivising contributions

Developers are essentially humans and we all respond to incentives. Our current situation means that there’s only an incentives on the negative side — fix common libraries so our applications stay up, and that’s definitely not how quality softwares are built.

We decided that there must be positive incentives to motive our engineers. The first step to creating rewards is to measuring contributions so we came up with a formula to point the karma for each Github issue. This is the current version after multiple refinements:

According to the model outlined in previous section, Open Source rewards come in two forms — street creds and monetary. We have titles for top contributor of the month — Wizard of OSS, and for top contributor of the year — Lord of the OSS, both of whom pictures will be up on our internal OSS contribution leaderboard. On top of that, folks can redeem karma points for educational purchases in a progressive manner with the more points accumulated, the more each point worths.

Distributed ownership

The second piece of the puzzle for our program to be effective is ownership. We started by forming core maintainer groups based on historical contributions to each of the existing common repositories with their own slack handles and responsibilities (with great handles come great responsibilities):

• Answer all questions, concerns about the repositories that they are overseeing
• Code reviews for contributions
• Review feature requests
• Initiate new feature discussions towards project vision
• Maintain and publish new versions of the repository
• Nominate, assess and onboard new core maintainers

This mirrors the same structure that we often observe in Open Source projects out in the wild, with small groups of core maintainers keeping the projects in line with the directions and purposes they were created for. This also means that new common projects within our organisation will have proper ownership (which we initially had a few years back before all the problems) and succession plan (which was what we lack that is the main cause for ownership diminishing).

Small wins & future ambitions

Ever since its inception, our internal OSS program has:

• Grown our contributions to the organisation’s common codebases from happy-go-lucky to frequent grooming and maintenance by over 30 enthusiastic engineers (about 15% of the total engineering head-counts).
• Helped us cut down the turn-around for bug-fixes and feature releases of our common libraries to within a single week.
• Given us a proper platform to have discussion about organisational standards and move towards more widely accepted industry standards like OpenTelemetry instead of coming up with and maintaining our own.

With these foundations set up within our own internal operations, we’re looking to be involved more in Open Source work with the public communities, to be able to give back to whom we’ve benefited so much from.

We hope that our journey so far could be an inspiration for other organisations to develop Open Source culture with a less steep learning curve.

Last but not least, if you would like to join us in our Open Source adventure, don’t hesitate because Xendit is always looking for awesome people!

Applying Open Source contribution model at Xendit and building a better engineering culture was originally published in Xendit Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.

I have never been a fan of vegan food no matter how much information I read, heard, absorbed via social media, or from friends on how vegan products is a more efficient method of converting energy from sunlight for humans. I’m aware of global warming and generally concerned about it. I would not use straws and would bring my own bags to the supermarket, however, completely leaving meat out of my meals and stopping myself from enjoying non-vegan food is something that I’m just not ready to give up.

So the folks at Impossible™ made “meat” from plants so that people like me can — in their own words — “Eat meat while saving Earth”. I have heard about them for quite some time but haven’t tried one until I noticed that my favourite take-away kebab joint offers Impossible™ kebabs on their menu.

That moment I knew that I had to have Impossible™ kebab for lunch and beef kebab for dinner with the same complement vegetables and condiments so I could compare them.

Verdict: Impossible™ meat tastes pretty much the same as beef with a slightly different texture that’s easier to disintegrate (definitely would have it again but not every day 😂). This made me question myself why I’d never tried it until then, and in turns, kickstarted my thought into a rabbit hole of modelling our purchasing decision of green products.

The simple answer to the above mentioned question of why I had never tried Impossible™ and why I decided I would have this again is:

• Availability: I had never seen any of my frequent choices of food offering Impossible™ on their menu until now
• Taste: If it tastes and feels the same as animal-based meat, why not?
• Price: The small difference in price is something I wouldn’t mind compromising on (but an equal or lower price would make me buy more often probably?)

These factors mentioned above contribute and can be consolidated into a dimension of my model, namely, “convenience”. The other dimension of my model, since we’re talking about green products, can’t be anything else but “eco-friendliness”. I’m hypothesising that these are the 2 major dimensions on which people make a purchasing decision of green products.

As humans, we have certain limits to our decisions and actions. I wouldn’t pay 10 times the usual price of my kebab nor travel 2 hours away from my place to do my part in curbing food with high carbon footprint. Same goes to eco-friendliness, I wouldn’t eat something that tastes like rainbow 🌈 if it immediately raises Earth’s temperature by a degree. Let’s add these limits to our models using these dotted lines.

However, as we don’t make our decisions based on these limits alone, being in the top right quadrant doesn’t guarantee we would buy these products. So if it’s not the limit lines, what is our boundary for action vs non-action then? How do we combine both aspects of purchasing decisions into a single function? Which mathematical model would take into account both factors without letting either one overpower the other (i.e. not letting something with extremely high convenience value and extremely low eco-friendliness enter the buy zone)? Our answer is product function of convenience and eco-friendliness. Something like

In the above function, we have x as the variable for eco-friendliness, and y for convenience. lx and ly, respectively, are the limits for these variables (represented by the green dotted line and the red dotted line in our graph previously). C is a constant that represents how hard a buyer we are. The higher C is, the more it takes for us to make a buy decision (And as human we’re, each one of us would have a different C value based on our personal ideologies)

With lx and ly as bounds for eco-friendliness and convenience values (i.e. x > lx and y > ly), we can plot the boundary of the action zone like so — with the boundary (purple line) approaching the limit lines as we go further up or right the graphs but never converging with them (checkout this Wiki if you’d love to find out more).

Now let’s apply this model to my meals and see where them kebabs are. Since both of my kebabs are definitely in the buy-zone, for demonstration purpose, I would add in raw beef for cooking — something which would hardly make it to my buy zone as I find cooking too much of a hassle.

As we can see from the graph, Impossible™kebab is less “convenient” compared to my normal beef kebab with its higher price but its higher value of eco-friendliness kept it in the buy-zone for me. Raw-beef-for-cooking, despite being in the top-right quadrant — beating both my limits for convenience and eco-friendliness — didn’t make it to the buy zone as its combined value of convenience and eco-friendliness is not enough to get me to action.

The case study of electric cars

Now rewind back to the year 2001, when GM released their electric car model EV1, Stan decided to buy one and was getting all pumped up to amaze his friend Joe about this car and how eco-friendly a person he was.

Stan didn’t even manage to tell Joe that it’s environmentally friendly! And GM EV1 did really prove to be pretty impractical (50mph top speed and 80 miles range full charge) and too expensive to be commercially viable.

Fast-forward to 2012, this time our environmentalist Stan managed to be one of the first people to get himself a newly delivered Tesla model S. Here he is showing Joe his new car.

Stan finally had his chance to proudly show off his eco-friendly car with curves as sexy as any other gasoline-powered cars. Going beyond our imaginary story of Stan and Joe, Tesla cars actually compete heads-on with gasoline-powered cars, racking in practical numbers for top speed and range while having eye-catching designs (fun fact: Tesla’s first 4 models’ names combined is “S3XY” if you know what Elon means 😉). On top of that, Tesla managed to build a dense network of supercharger stations, making it a breeze to charge their cars. These are the reasons why Tesla cars sell like hotcakes. So which EV is more likely to save the planet? A model with eco-friendliness as a secondary selling point or one with the major (or sole?) selling point to be environmental friendliness?

Let’s apply our model on these EVs with the additions of a normal gasoline-powered sedan from Ford (white colour) and a hybrid car model from Toyota (grey colour). We should get something like this

From the rough graph that I plot above, doesn’t it look like Tesla is clearly winning the race against less eco-friendly counterparts because it’s not much less “convenient”? However, Tesla EVs (or other commercial EVs on the market) are not yet clearly superior to their gasoline-powered alternatives. Hence, for some people with a higher convenient limit (i.e. due to a smaller budget, or living in a country where there’s no supercharger station, etc), they might still opt for a gasoline-power car — scoring one point for team “Global Warmers”.

Messages to the green economy influencers

Although this is just a fun and random thought experiment of mine (mathematicians and economists please spare my mistakes if there’re any 😅), I hope that it can prompt the influencers of our future green economy to think in multi-dimension.

My hope and encouragement are with product designers and engineers who love to pave the way to a sustainable future to not be discouraged if your green products has not been accepted by consumers. Keep refining, reiterating and pushing the convenience scores of your products up.

My hope is with environmental activists to be more multi-dimensional in your advocacy, instead of advocating to push a single dimension of the equation to a ridiculously off-limit point for a majority of people because that won’t be effective as no one is able to listen to your advice (Just like how sensible people wouldn’t listen to Donald Trump on climate change). Explore alternatives, learn about sustainable solutions if you have to and advocate with the right mission.

My hope is with the mass consumers to adapt to the uncertain future, to adjust your limits, to go beyond our pampering habits of unsustainability, and be more accepting of green products and green lifestyles. The only way out of global warming is a global effort.

My Impossible™ kebab and the economics of green products was originally published in Age of Awareness on Medium, where people are continuing the conversation by highlighting and responding to this story.

Because who doesn’t want good boys to show up whenever they push?

The long awaited GitHub Action feature is finally out of beta and ready to be present in every repositories. GitHub even organized a Hackathon through out March to encourage folks to create more awesome and useful actions. While browsing through the submissions, I found a cool GitHub Action that posts cat gifs on pull requests. Shout out to Ruairidh with his cool idea 👏👏👏.

It’ll only do justice to dogs if there’s an action that deliver them good boys to our PRs. That moment I knew exactly what my next Github Action project would be. Time to get to work.

The Gist of Creating a GitHub Action

GitHub actions are basically premade (with ❤️) units of work to be used GitHub workflows (think Travis’s builds). Github actions can be either built with Docker containers or JS/TS scripts. An advantage to creating a GitHub action with JS/TS is readily available modules from GitHub toolkit. With such integration support, it’s much easier to connect with GitHub services (C’mon 🙄 Who wanna write curl commands to make API calls). It's obvious to go with TypeScript action template. With that decision made, let's get down to writing action-dogs.

The Main Run File

In a JS/TS GitHub action, workload will be started out from a main entrypoint (think running node src/index.js to start a Node process for web applications, etc). For action-dogs, this is my basic setup for the main program

import * as core from "@actions/core";
import * as github from "@actions/github";
import { generate } from "./doggo/generator";

(async function run(): Promise<void> {
  try {
    const ctx = github.context;
    if (!ctx.payload.pull_request) {
      throw new Error("Not in the context of a PR!");
    }

    const ghCli = new github.GitHub(core.getInput("github-token"));
    const doggo = generate();
    ghCli.issues.createComment({
      ...ctx.repo,
      issue_number: ctx.payload.pull_request.number,
      body: `![Doggo](${doggo})`
    });
  } catch (e) {
    core.setFailed(e.message);
  }
})();

During an event that can trigger GitHub workflows, we are provided with a context object that can be accessed through @actions/github module. Using that, I'm able to check whether my payload is coming from a pull_request and reject otherwise. Next up, I need to post a comment to the corresponding pull request with content of a doggo gif. Given that my doggo generator (of which I will explain in the next section) works properly, I can retrieve an URL of a doggo gif, creating a comment on pull requests is super simple as I just need to pass in the repo's information from our context object and the PR's number. Also, in case we get any errors during these operations, calling core.setFailed(e.message) will mark the build as failed with the error message.

The Doggo Generator

After much research with the intention to use one of the public APIs to get random doggo gifs, I couldn’t find one that’s public (like dog.ceo) and also serves gifs (like GIPHY). Since there’s no avenue for me to store my GIPHY API key securely to be used in action-dogs, I fell back to the good-ol-way of static JSON array.

Wanna know how I obtained my array full of doggo awesomeness (from ❤️ GIPHY ❤️) without any API key generated in the process? I actually went to GIPHY site, searched for doggoes, and scrolled down util a good amount of “giffy-boys” got rendered before pulling up my console

And with these few lines of JS

const dogsData = [];
document
  .querySelectorAll("a._2SwDiFPqIlZmUDkxHNOeqU")
  .forEach(e => dogsData.push(e.href));
var dataStr =
  "data:text/json;charset=utf-8," +
  encodeURIComponent(JSON.stringify(dogsData));
var dlAnchorElem = document.createElement("a");
dlAnchorElem.setAttribute("href", dataStr);
dlAnchorElem.setAttribute("download", "dogs.json");
dlAnchorElem.click();

which basically grab `href` values from all “copy link” elements on the search results page, stream them to a JSON array and fill in a file for me to “download”, “generating” is simply picking a random URL from the array.

import dogs from "./dogs.json";

export function generate(): string {
  return dogs[Math.floor(Math.random() * dogs.length)];
}

Testing

I wrote a unit test for my doggo generator using jest (but actually mainly as an avenue for funny descriptions).

import { generate } from "../../src/doggo/generator";

describe("doggo generator", () => {
  test("to return a good boy", () => {
    Math.random = jest.fn().mockReturnValue(0);
    const good = "https://media3.giphy.com/media/mCRJDo24UvJMA/giphy.gif";
    const boy = generate();
    expect(boy).toBe(good);
  });
});

But the real test is a workflow using action-dogs itself (Yes, you can use a GitHub action on its own repo 🤯).

name: "doggo"

on: pull_request

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: stanleynguyen/action-dogs@master
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

Now I can see action-dogs in action with a sample PR. Hurray 🙌🙌🙌!! Now I can safely publish it on GitHub Marketplace.

Outtro

So that’s my story of creating action-dogs for fun and learning. You can find source code right on GitHub (well, because where else could it be 🤷‍♂️) and action-dogs on Marketplace.

Building my Github Action to deliver doggoes to PRs was originally published in Easyread on Medium, where people are continuing the conversation by highlighting and responding to this story.

Motivation

Most of us, at some point in our lives, have used at least a custom DNS server configurations for our computers. Be it for avoiding censorship, faster browsing, security, or bypassing the content restriction, we’ve all tried setting our DNS servers to some public DNS servers like one from Google (remember 8.8.8.8 and 8.8.4.4?). I myself is also no exception as I have been using 1.1.1.1 for privacy and speed. Unfortunately, having custom DNS nameservers also comes with some setbacks for someone who uses their computer all the time in all the different places. With custom DNS servers, this is what you get on a network that tries to block them (together with VPN services etc.)

Another problem that we would have with custom DNS servers is that networks’ login pages just don’t show up as the default DNS is not being used to redirect us to the local network login page. Of course, it would be easy to just remove the configurations as you (most likely) was the one who set them up, how hard would it be to remove? But what if we need these alternate DNS servers again? I personally find this way of manually removing and adding them back too much of a hassle. Hence, I wrapped them in a bash function that does the job for me as all lazy programmers do.

1.1.1.1

Before starting with explaining what I did in the next section, I would like to do a big shout-out to this awesome project that’s a combined effort from Cloudflare and APNIC — 1.1.1.1. It’s an effort to provide Internet users with a faster and more secure DNS (it is more than 2x faster than Google Public DNS 🚀🚀🚀). But more than just that, it is a privacy-first DNS server. Did you think only these companies like Google, Facebook trying to track all of your activities online (which can be blocked with the awesome Privacy Badger)? Your ISP also eavesdrops on whichever site you are visiting and sell these data to target you with ads, and they do it through, guess what, DNS resolvers!

1.1.1.1 protects you from all of that for a price of $0 (yes, you read that right). A FREE, fast, secure DNS server that respects your privacy — sounds too good to be true, doesn’t it? But it’s an effort towards building a better Internet. You don’t have to take my words for that, read more about it on Cloudflare’s and APNIC’s blogs.

Switching DNS nameservers via bash

As I mentioned previously, it’s too much of a hassle for me to go manually update my DNS configurations via Network Settings UI whenever I jump back and forth between school’s and home’s networks. Naturally, I would try to figure out how to do it via my terminal. That’s when I found out about this awesome tool that comes in-built with macOS — networksetup. With networksetup, changing my DNS config is as simple as

# Adding 1.1.1.1 to my nameservers
networksetup -setdnsservers Wi-Fi 1.1.1.1
# Clear all my alternate nameservers
networksetup -setdnsservers Wi-Fi empty

Now I can easily configure my DNS resolvers to be the same as the instructions for 1.1.1.1 by

# 4 nameservers - 2 IPv4 & 2 IPv6
networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001

But this is quite lengthy to type as well, even though I would prefer this over Network Preferences UI any day. So I went another level of laziness by wrapping it inside a bash function

function dns1111() {
    networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001
}

This seems to be pretty neat and does the job, but hold on a second. How about switching it back to empty? A flag/argument to this bash function would do the job fine but I want to use the least effort as possible and save myself the mental burden of remembering whether my alternate DNS config is empty. So I thought to myself: “Why not detect the current state and switch the DNS config based on that? Like a literal switch button — you don’t have to tell what state you want it to be, just the opposite of what comes before”. With that in mind, I found this option for networksetup that would tell me the current state

networksetup -getdnsservers Wi-Fi

It would list all of my alternate DNS servers, or print out this string There aren't any DNS Servers set on Wi-Fi if there isn’t any. And now I can complete my function, with some cool emojis to signify whether the config has just been applied or removed

function dns1111() {
  if [[ $(networksetup -getdnsservers Wi-Fi) == "There aren't any DNS Servers set on Wi-Fi"* ]]; then
    networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1 2606:4700:4700::1111 2606:4700:4700::1001 && echo 🚀 🚀 🚀
  else
    networksetup -setdnsservers Wi-Fi empty && echo 🚦 🚦 🚦
  fi
}

Now I can easily switch back and forth between 1.1.1.1 and default DNS configs with just a short command dns1111

Bonus: Linux based machine

Since networksetup is not available on Linux based OSes, we would need to use a different package that helps handle DNS nameservers called dnsmasq.

Install it using your distro’s package manager

# this is for Ubuntu
sudo apt-get install dnsmasq

Installing the package will come with a config file /etc/dnsmasq.conf for us to update the nameservers. I have included my implementation below. If you have a better approach, don’t hesitate to reach out to me at hung.ngn.the@gmail.com

function dns1111() {
  # detect existence of the backup file to see whether the config is in place
  if [ -e /etc/dnsmasq.conf.bak ]]; then
    sudo mv /etc/dnsmasq.conf.bak /etc/dnsmasq.conf && echo 🚦 🚦 🚦
  else
    sudo cp /etc/dnsmasq.conf /etc/dnsmasq.conf.bak && \
    sudo echo "server=1.1.1.1
server=1.0.0.1
server=2606:4700:4700::1111
server=2606:4700:4700::1001" >> /etc/dnsmasq.conf && \
    sudo service dnsmasq restart && \
    sudo service network-manager restart && \
    echo 🚀 🚀 🚀
  fi
}

This article was originally published on thecodecousins.

Quick terminal-based DNS switching was originally published in Easyread on Medium, where people are continuing the conversation by highlighting and responding to this story.