Brain Spill

There are two things I look for whenever I check out an Opensource project or library that I want to use.

1. Screenshots (A picture is worth a thousand words).

2. Examples (Don't tell me what to do, show me how to do it).

Having a fully working example (or many examples) helps me shape my thought process.

Here are a few projects that are excellent examples of this.

1. https://github.com/prompt-toolkit/python-prompt-toolkit

A CLI framework for building rich command line interfaces. The project comes with a collection of small self-sufficient examples that showcase every feature available in the framework and a nice little tutorial.

2. https://github.com/coleifer/peewee

A small ORM for Python that ships with multiple web projects to showcase how to use the ORM effectively. I'm always overwhelmed by SqlAlchemy's documentation site. PeeWee is a breath of fresh air with a clear purpose and succinct documentation.

3. https://github.com/coleifer/huey

An asynchronous task queue for Python that is simpler than Celery and more featureful than RQ. This project also ships with an awesome set of examples that show how to integrate the task queue with Django, Flask or standalone use case.

The beauty of these examples is that they're self-documenting and show us how the different pieces in the library work with each other as well as external code outside of their library such as Flask, Django, Asyncio etc.

Examples save the users hours of sifting through documentation to piece together how to use a library.

Please include examples in your project.

I believe that the language you speak influences the way you think. I don't have any kind of proof other than some anecdotal evidence. 

Recently I started noticing this in the field of computer languages as well. I consider Python to be my dominant language. I have a coworker (let's call him Aaron, because that's his name) who likes to bait me by pointing out certain lack of features in Python and how Ruby gets it right. Most of the time I dismiss his complaints as invalid because I never have a use for those features in my day to day coding.

Then it dawned on me that I don't have a need for those features because I tend to think in Python. When I am presented with a problem I think of a solution that can be implemented in Python and my thought process naturally gravitates towards the features available in Python. 

What I learned from this realization is, if you learn many different languages you'll never be happy with any single language. You'll always yearn for that sweet feature that is missing in your current language. 

Let that be a lesson.

You can add a git sub-command by defining a new alias in your ~/.gitconfig file as follows:

The git open defined in the ~/.gitconfig is mapped to a shell script called git-open.sh. 

This bash script does two things: 

1. It tries to detect if there are any files with uncommitted changes in the current repo and prints out the filenames.

2. If the repo doesn't have any uncommitted files, it'll print the filenames from the last commit.

The git open alias is mapped to open the output from this script using vim. 

Why is this useful?

I can pick up where I left off the previous day by simply typing `git open` inside the repo. This will open either all files with uncommitted changes or open the files from the last commit. There is a very good chance that my work for the day will continue on those files.

A small hack to make life a little bit easier.

When I first started coding, GPL used to be the most popular license for open source projects. It was the go to license for someone dipping their toe in the FOSS world unless you're developing software for FreeBSD.

But over the past few years, companies have pulled a brilliant coup d'état and convinced the up and coming programmers that GPL is a virus. If you release your software in anything other than MIT or BSD license the programming community looks down upon that contribution.

Recently I've been seeing a lot of open source maintainers complaining about companies that use their software and demand bug fixes or features but hardly contribute any code or money towards their projects. 

This is the exact problem that GPL was designed to solve. If a company finds value in your code and decide to build upon it, they can either contribute back to the community by making their product open source or pay you for an alternative license that allows them to keep their code closed source.

OpenSource is Socialism. People do OpenSource because they enjoy doing it or they stepped up to fill a need. In a socialistic community, you're not paid for the end product and sharing (or forking) is encouraged. But commercial companies operate on the principle of Capitalism. They're trying to maximize their shareholder's value. Trying to appeal to a capitalist entity to support a socialist endeavor will not work. This is the reason why GPL is designed the way it is. GPL protects the OpenSource source ecosystem from the exploitation of capitalist entities.

But somehow the programming community decided that permissive licenses are the way forward. This is further encouraged by commercial companies because now they can use all this quality software without paying a penny or contributing back to the community. This erodes the OpenSource ecosystem in the long run because we are building software on the ashes of thousands of burnt out programmers.

This is where we arrive at a fork in our journey. 

Should we all use GPL? No.

If you're doing OpenSource because you love what you do and want to see your work used by as many people as possible, go with a more permissive license. But don't expect companies or users to pay for the product. This is never going to work.

There is nothing wrong with trying to make a living through OpenSource. Dual licensing with GPL + paid commercial license is a fantastic option. Don't succumb to the ivory tower programmers who demand all OpenSource software must be permissively licensed. If a company wants to build their profits from your software, there is nothing wrong with asking them to pay your fair share.

If you do take the more permissive license route, take care of your mental health and take steps to prevent burnout. Because whether you like it or not it's coming.

Github produced a video series called "Maintainer Stories". One of the videos is about my experiences as a maintainer of pgcli.