Is Open Source licensing holding us back?!

This sounds like an outrageous question, coming from me, a top-100 software developer in the world!
Ok, I may have omitted a zero or two in the number above. Maybe three, don’t push it!
Nevertheless, hear me out till the end.

I am not against open source software at all.
I am not against giving everybody the ability to read a code, learn from it, modify it and derive their own variant out of it.
After all, I am one of so many developers who learned so much from open source projects.

Free numbers do not lie!

Did you know this about open source maintainers?
- about 60% are UNPAID
- only 13% are paid enough to be dependent on their project as a sufficient source of income
- the rest are paid, but not enough to live off

Open source licensing was initially created to fight against the monopoly of knowledge. Trying to maintain the maximum amount of freedom, open source licensing accidentally deprived many of the OSS maintainers of one important freedom: the freedom to financially benefit from their works.

Free like free food, but is free always good?

You would argue against that by saying:

Argument: OSS projects get funding.
Refutation: We already established that the largest chunk of OSS projects are underfunded.

Argument: OSS can earn money through support services, training, certifications and lots of other stuff.
Refutation: But those earnings are from the side services and not the main product. Imagine owning one of the fanciest restaurants, and disclosing your recipes for free, but you can’t charge your customers for anything except for the optional use of the premium silverware!

Argument: Big companies sponsor OSS and their events.
Refutation: Indeed, those big companies fiercely fought against OSS in the beginning. Later on, they discovered that the pros of OSS outweigh the cons for them. Not only tons of their projects became dependent on OSS, ultimately contributing to more profit, but they also get the credit by becoming the “gigantic philanthropists”. They give back a small chunk of their earnings to the geese that lay golden eggs.

Cut it free, but cut me in!

No doubt that Open Source licensing had, and still have, contributed so much to the software development world. But we have been clinging to the same model of licensing for decades, depriving ourselves from well-deserved opportunities, in a harsh world where survival is for the FAANGest!

Is it unthinkable to create or adopt a license that allows freedom of access/modification/contribution/redistribution of the source code, but monetize the derivation? The derived works of such sources can opt for getting some royalty if the corresponding revenues are above a certain threshold.

Did we become so afraid of using a license that does not stick to the perfect model of the open source license? Are we ashamed of imperfection to the extent of endangering our own sustainability and survival?

Would you support something like an OpenRoyalty license? Curious to hear your take.

Ever wondered what will happen if we combine one of the most promising Python web frameworks with a rock?!

In my previous article, I introduced Rockcraft and its ability to create minimalistic and secure container images, known as rocks. Today, we delve deeper into this evolving tool, highlighting its latest feature: Extensions. This powerful addition allows for effortless deployment of apps like Flask and Django without the need for custom scripts or manual intervention. Let’s explore how to leverage this feature effectively.

Install or update Rockcraft

First, let’s make sure we have the latest version of Rockcraft by running the following update command in terminal:

$ sudo snap refresh rockcraft

If that is your first time using Rockcraft and you don’t have it installed, you can install it by running:

$ sudo snap install rockcraft --classic

Get the rocket ready!

Now, I will initiate our rockcraft project in an empty folder called /home/ubuntu/django. Pick your own empty folder then run:

$ rockcraft init

This will create rockcraft.yaml with placeholder values:

name: django
base: ubuntu@22.04 # the base environment for this rock
version: '0.1' # just for humans. Semantic versioning is recommended
summary: Single-line elevator pitch for your amazing rock # 79 char long summary
description: |
    This is oci-factory's description. You have a paragraph or two to tell the
    most important story about it. Keep it under 100 words though,
    we live in tweetspace and your description wants to look good in the
    container registries out there.
license: GPL-3.0 # your application's SPDX license
platforms: # The platforms this rock should be built on and run on
    amd64:
    arm64:

parts:
    my-part:
        plugin: nil

Change the values of version, summary, description, license and platforms to your linkings and needs, and remove the my-part subsection under parts:. You have to change two important fields:

• name: should match with your Django project name
• base: only bare and ubuntu@22.04 are currently supported for this extension

One last thing! Since extensions are still experimental, we need to say the SECRET WORD! Without the following environment variable, Rockcraft won’t allow us to build our image:

$ export ROCKCRAFT_ENABLE_EXPERIMENTAL_EXTENSIONS=true

Django unchained, and initialized!

Now, let’s create a very simple django project. Assuming you already have Python 3.x installed, create and activate a virtualenv first by running:

$ virtualenv .env
$ source .env/bin/activate

Proceed then to install the latest version of Django:

$ pip install django

The django-framework extension that we are going to use requires us to store the list of our python packages in a requirements.txt file, so create that file in the django/ folder and write in it:

django

Create a new Django project:

$ django-admin startproject djangoproject

Remember to change the name field in rockcraft.yaml to become djangoproject as well.

Next, let’s create a Django app within our project:

$ cd djangoproject
$ python manage.py startapp django_app

By default, a Django project used sqlite as database. We will leave it at that for now and proceed to create the database without altering settings.py. To create the database and an admin user, we run the following commands in terminal (the second command is an interactive one):

$ python manage.py migrate
$ python manage.py createsuperuser

Now, to have an actual application, we will modify two of the django files to have the bare minimum functionality. First, change the file djangoproject/django_app/views.py so it becomes:

from django.http import HttpResponse

def index(request):
    return HttpResponse("<h1>Hello World!</h1>")

Next, change the file djangoproject/djangoproject/urls.py so it becomes:

from django.contrib import admin
from django.urls import path
from django_app import views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', views.index),
]

With this, we implemented a “Hello World” index page in our Django web application. Let’s test by running the development web server:

$ python manage.py runserver

We can access the Hello World page from any browser by navigating to http://localhost:8000. We should be able to see the infamous Hello World!

Watch the clock, it’s time to rock!

Finally, since our Django app is all set up, we are ready to build our rock!

Interesting enough, we only need to add 2 more lines to our rockcraft.yaml to make everything magically work. Actually, our final yaml file will look like this:

name: djangoproject
base: bare
build-base: ubuntu@22.04
version: '1.0'
summary: Django app rock
description: Django app rock
license: MIT
platforms:
  amd64:

extensions:
  - django-framework

Notice how simple the yaml file is and how it is void of any scripting/coding contents.

NOW, LET’S ROCK! LET’S PACK AND BUILD THE ROCK!

$ rockcraft pack

If you receive no error with this command, but obtain no .rock file at the end of it, make sure you have set the environment variable that I have mentioned before properly.

Hint: it’s called ROCKCRAFT_ENABLE_EXPERIMENTAL_EXTENSION

If everything cooks well, your output should be like this:

deleting current features configuration
*EXPERIMENTAL* extension 'django-framework' enabled                                                                                                                                   
deleting current features configuration                                                                                                                                               
*EXPERIMENTAL* extension 'django-framework' enabled                                                                                                                                   
Packed djangoproject_1.0_amd64.rock

We did it! Our trophy is a rock and it’s called djangoproject_1.0_amd64.rock!

Ready… Set… Run!

Let’s give the rock a test drive with a docker run command.

First convert it to a docker image by running:

$ rockcraft.skopeo --insecure-policy copy oci-archive:djangoproject_1.0_amd64.rock docker-daemon:djangoproject:1.0

Reminder: skopeo is tool, shipped within Rockcraft’s snap, that allows you to convert an OCI image to a Docker image and vice versa.

Then create and run the container:

$ docker run -d --name mydjango -p 8000:8000 djangoproject:1.0

We can finally access our Django we app in the browser by navigating to http://localhost:8000.

Pretty straightforward, huh? You can just close your eyes and let the magic happen automatically. Or, if you are a bit curious how things are working under the hood, the rock’s process manager called pebble allows you to do just so!

To see the services running using pebble:

$ docker exec mydjango pebble services

Service          Startup  Current  Since
django           enabled  active   today at 17:43 UTC
statsd-exporter  enabled  active   today at 17:43 UTC

You can even see the changes happening while running the image:

$ docker exec mydjango pebble changes

ID   Status  Spawn               Ready               Summary
1    Done    today at 17:43 UTC  today at 17:43 UTC  Autostart service "statsd-exporter" and 1 more

And more importantly, you can see the logs of your running services:

$ docker exec mydjango pebble logs

2024-05-24T17:43:51.738Z [statsd-exporter] ts=2024-05-24T17:43:51.738Z caller=main.go:300 level=info msg="Starting StatsD -> Prometheus Exporter" version="(version=, branch=, revision=2c7fd1edd4bdf01982a648b689da10e5bcff860d-modified)"
2024-05-24T17:43:51.739Z [statsd-exporter] ts=2024-05-24T17:43:51.738Z caller=main.go:301 level=info msg="Build context" context="(go=go1.22.3, platform=linux/amd64, user=, date=, tags=unknown)"
2024-05-24T17:43:51.739Z [statsd-exporter] ts=2024-05-24T17:43:51.738Z caller=main.go:350 level=info msg="Accepting StatsD Traffic" udp=localhost:9125 tcp=localhost:9125 unixgram=
2024-05-24T17:43:51.739Z [statsd-exporter] ts=2024-05-24T17:43:51.738Z caller=main.go:351 level=info msg="Accepting Prometheus Requests" addr=:9102
2024-05-24T17:43:52.855Z [django] [2024-05-24 17:43:52 +0000] [19] [INFO] Starting gunicorn 22.0.0
2024-05-24T17:43:52.855Z [django] [2024-05-24 17:43:52 +0000] [19] [INFO] Listening at: http://0.0.0.0:8000 (19)
2024-05-24T17:43:52.855Z [django] [2024-05-24 17:43:52 +0000] [19] [INFO] Using worker: sync
2024-05-24T17:43:52.857Z [django] [2024-05-24 17:43:52 +0000] [20] [INFO] Booting worker with pid: 20

This was just a glance at one of Rockcraft’s new capability. There is so much you can still do with this extension feature. If you want to experiment more, try switching Django settings to use a mysql database, and modify your rockcraft.yaml so that it has a part and a service that installs, configures and run the mysql daemon. If you get stuck or need help, check the official documentation or ask here in the comments section.

Meet the rockstars!

Want to learn more about rocks, the team behind them, or stay up-to-date with the rock ecosystem?

• Subscribe to the Rocks Discourse to stay updated with rock news!
• Hop in the Rocks Matrix server to talk to Rockstars, seek help or just to say hello!
• Join the Rocks Community and help creating and maintaining rocks!

Django Beats Scissors, Stands Up to Paper was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a journey to a achieving better container images, let’s stop in a cozy corner where we will dive into the fascinating world of Rockcraft. If you’re a bit of a container enthusiast, which I’m guessing you are, you are in for a treat. Today, we are going to unravel some of the secrets of building secure and mini-sized images, affectionately known as “rocks”, using Rockcraft.

So, what’s Rockcraft, I hear you ask? It is a very crafty tool in your developer’s toolkit, something like a Swiss Army knife for creating super-efficient and secure container images. It is like a professional cook that you gives the recipe (aka rockcraft.yaml), then proceeds to fetch the ingredients, then cook, and finally produce the cake. The only drawback is you may lose a tooth or two if you try a bite, as that cake will be as hard as a “rock”.

Get Ready for the Hike!

And if you are wondering what makes “rocks” special, there are 3 main reasons:
- It is based on Ubuntu LTS images for a higher security.
- It uses chiselled packages to include only necessary files and binaries.
- It has a cute embedded service manager called Pebble!

Before we start, we’ll will make a checklist of the items we need in our little journey:
- Ubuntu system or one of its flavors/derivatives
- Docker needed to test and run our rock
- LXD required internally by Rockcraft

Next, let’s install Rockcraft on our system. The most recommended way is by using snap, ensure that we will get the latest stable Rockcraft version:

snap install rockcraft --classic

Next let’s create an empty folder and move inside it. We will proceed to initiate our first rock:

mkdir my-first-rock
cd my-first-rock
rockcraft init

One YAML to Conquer Them All!

Rockcraft’s init command will create a rockcraft.yaml file in our folder, containing a template ready to be filled in. This yaml file is the recipe to cook our rock. You could think of it as a Dockerfile, but unlike a Dockerfile, it uses a declarative language, allowing for a more efficient image building.

Looking at our auto-created rockcraft.yaml, it should look like this:

name: my-rock-name # the name of your rock
base: ubuntu@22.04 # the base environment for this rock
version: '0.1' # just for humans. Semantic versioning is recommended
summary: Single-line elevator pitch for your amazing rock # 79 char long summary
description: |
  This is my my-rock-name's description. You have a paragraph or two to tell the
  most important story about it. Keep it under 100 words though,
  we live in tweetspace and your description wants to look good in the
  container registries out there.
license: GPL-3.0 # your application's SPDX license
platforms: # The platforms this rock should be built on and run on
  amd64:
parts:
  my-part:
    plugin: nil

Fields like name, version, summary, description and license are informative fields and can be changed according to the rock we are trying to make.

Secure The Base!

Moving on, the base field allows us to choose which LTS version we want to base our rock on. At the time of writing this article, the supported versions are ubuntu@20.04, ubuntu@22.04 and ubuntu@24.04.

But wait! base also allows for a very cool value called bare. Imagine you want to put only your application files inside your rock, and include only the required libraries for your application to run, and not the whole system. With Docker, you would go about that with something like the following in your Dockerfile:

FROM ubuntu:22.04 AS builder
RUN mkdir /rootfs
# do things in your /rootfs folder

FROM scratch
COPY --from=builder=/rootfs /
ENTRYPOINT […]

However with Rockcraft, just use base: bare. Along with another field called build-base, base: bare will do the same magic as above. build-base will tell Rockcraft which Ubuntu image will be used to create your rock, but other than that, your image will be stripped out from all other unnecessary files:

base: bare
build-base: ubuntu@22.04

Pretty neat, huh?

build-base supports an extra value called devel, which points to the next Ubuntu version that is yet to be released.

The next field that may have caught your attention is platforms. It allows you to build rocks for multiple architectures at the same time (if your system allows it). You will get a separate rock file for each architecture you build for. There are several architectures supported: amd64, arm64, armhf, i386, riscv64, ppc64el and s390x.

Plug-in-Part!

Now let’s come to juicy part, the part where you make the sauce! Conveniently, that part is called parts. This is where you put the files and packages you want to have in your rock. You can have multiple parts, each with a different name, and each part needs to have a plugin, which can be nil.

Secret Agent nil

If you want just to install packages inside your part, either apt packages from ubtunu repositories or slices (but not both at the same time), then the nil plugin is your friend. For instance:

parts:
  nodejs:
  plugin: nil
  stage-packages:
    - nodejs_bins

This will install the nodejs_bins slice inside your part, which contains all the necessary files to run Nodejs. By the way, you can discern a slice from an apt package by the underscore, since slice names must have an underscore. stage-packages field means that we are asking for that package to be installed in the stage step. There are 5 steps involved in rock packing process, but let’s not delve too deep into that right now.

Other Plugins to Explore

Unsurprisingly, the nil plugin is not the only plugin you can use in your part. But what’s a plugin, I hear you say? It is a build environment already prepared for your configuration and use. If you want to build a python application in your rock, the python plugin will do that for you, courtesy of Rockcraft’s parts model.

There are a variety of plugins currently supported in Rockcraft parts. The list includes, but is not limited to: nil, python, npm, make, qmake, cmake, go, rust, java and dotnet.

Another example is the python plugin, you can also have it come pre-installed with whatever python packages you need with a plugin property called python-packages. Alternatively, you can use python-requirements to point to the location(s) of your requirements file(s).

Let’s try that right away, shall we? Let’s create a simple Flask project in a new folder called src inside my-first-rock folder. We tell it to install flask package via python-packages. Furthermore, we will need the python3-venv installed through stage-packages.

parts:
  python-runtime:
    plugin: python
    source: src/
    python-packages: 
      - flask
    stage-packages:
      - python3-venv

However, for our first journey we want to try something simple, like running a single python file. The python plugin is made to build Python projects, so it will look for something like setup.py and pyproject.toml and build accordingly. Since we aren’t going that far, we are just using the python plugin as a quick way to install Python and Flask.

Inside the src folder, create a file called hello.py with the following contents:

from flask import Flask

app = Flask(__name__)

@app.route("/")
def hello_world():
  return "<p>Hello, World!</p>"

Finally, we want to copy the contents of our local src folder to the root of our image. That can be done by adding a second part that uses the dump plugin:

parts:
  python-runtime:
    plugin: python
    source: src/
    python-packages:
      - flask
    stage-packages:
      - python3-venv
 
  hello-app-files:
    plugin: dump
    source: src/

Et voilà! It is simplicity itself, my dear Watson!

Thank You for Your Service!

Now that we have our files and packages already well-tidied in our rock image, we need to run our Flask application. Our tiny friend Pebble comes to shine at this moment, because it will take care of running everything under the hood through the field services. In our case, we will use something as simple as:

services:
  flask-service:
  startup: enabled
  override: replace
  command: flask --app /hello run --host=0.0.0.0

This will make Flask runs the single application file we have at /hello.py inside the rock.

Now our complete rockcraft.yaml should look like this:

name: my-first-rock
base: ubuntu@22.04
version: '1.0'
summary: My first amazing rock
description: |
  This is my first rock. Deal with it.
license: MIT
platforms:
  amd64:

services:
  flask-service:
    startup: enabled
    override: replace
    command: flask --app /hello run --host=0.0.0.0

parts:
  python-runtime:
    plugin: python
    source: src/
    python-packages:
      - flask
    stage-packages:
      - python3-venv
 
  hello-app-files:
    plugin: dump
    source: src/

Cook It Nice and Slow!

We are ready to cook as all the ingredients are ready in the pot. Start the fire by running:

rockcraft pack

This may take a couple of minutes, so lay back and contemplate the beauty of the nature around or your incomparable genius, whichever way you swing.

When Rockcraft successfully finishes packing, you will get your prize: a nice rock image named my-first-rock_1.0_amd64.rock.

Run It for Your Life!

Unfortunately, we cannot run the rock image directly in a container manager such as Docker. However, a nifty tool called skopeo can convert our rock, an oci archive, to a Docker image. Luckily for us, skopeo comes installed within the Rockcraft snap. Run the following command:

skopeo --insecure-policy copy oci-archive:my-first-rock_1.0_amd64.rock docker-daemon:my-first-rock:1.0

Let’s run this Docker image right away:

docker run -d -p 5000:5000 --name first-rock my-first-rock:1.0

This will launch our flask app in our rock, which we can access on a browser at http://localhost:5000.

Rock Hard!

After this rather, hopefully, enjoyable journey, I hope we learned together a thing or two about rocks and how to craft them. There is much more to discover about them rocks, so here are a few tips on what to do next:

- Subscribe to the Rocks Discourse to stay updated with rock news!
- Hop in the Rocks Matrix server to talk to Rockstars, seek help or just to say hello!
- Learn more about Rockraft through its official documentation!
- Join the Rocks Community and help creating and mainting rocks!

So, what’s the secret behind listicles? We find them anywhere and everywhere, and fall in the trap of clicking on their titles again and again, because numbers are so magical and so mesmerizing. After all, we can’t resist the temptation of knowing 31 ways that spaghetti can make us more attractive to the other sex, or the 17 life hacks that will make squirrels salute us on our way to work, can we? Mind that we often end disappointed and almost gaining nothing useful after reading those listicles, but the addiction is just too strong, just like the 23 non-addicitive substances we use daily to survive in our tough lives.

Prolific writers like listicles. They allow them to write more with less words, plus they gain more attraction, so more money. That made our environment full of nearly useless content, shining like beautiful balloons, but containing nothing but mere cheap air. With the help of our smart devices constantly spying on us, you can expect that the next time you stumble and fall down the stairs, you will find waiting for you a listicle titled “11 steps to heal your broken bones fast”. Yes, they are even accomodating you by counting the number of the steps you fell over.

So, what can replace those silly listicles? It’s an old nemesis that existed long before them: stories. You can read hundreds of listicles, with none leaving any traces over in your memory, but you can never forget that nice story that your cousin told you over a sleepover night when you were 9 years old. Whether it is funny, dramatic, full of wisdom, or scares the shit of you; whether it was told by your grandma, your friend, or by that great movie you watched; a good story will stay with you, and can even shape a part of what you are. But good stories are rare, and very hard to come up with. Nonetheless, you don’t need to write great stories all the time, or even create one out of your imagination. You can tell one of your own, based on a real event taht happened with you, and by picking your own narrative and telling it your own way. It doesn’t have to be accurate, and it doesn’t even have to be interesting to everyone. What’s important that it has meaning to you, and that you enjoy voicing it over to others by writing.

Now you know about this little secret. When you’re about to write something next time, remember to review my article “7 ways to avoid being beaten by clickbaits full of repetitive contents”.

The Archnemesis of Listicles was originally published in The Haven on Medium, where people are continuing the conversation by highlighting and responding to this story.

Scientists often stand bewildered in front of this grayish-green banknote. Is it the ink-rich smell? Is it the non-balanced layout that triggers OCD to many people? Is it the mysterious Franklin smile that beats that of the Mona Lisa? Whichever it is, and despite Franklin’s apparent discontent, everyone loves to swim in a pool of those notes, so here are 5 tips on how to mass produce them through a writing career:

1. A Word Is Worth a Thousand Pictures

Just stack those words together in endless sentences. Make your readers dizzy with the uninterruptible flow of letters. Put everything together in one super long paragraph, minimize line spacing if possible, and put away any form of separation that let the readers take a break. After all, quality is measured in mm cube of ink per inch (or black pixels per inch), so squeeze every pixel you can in the reader’s face.

2. Clickbait With Numbers

You probably noticed how much a fancy number in an article title attracts people, even when they already assume it’s a clickbait. On a platform like Medium, those clickbait articles seem to find their way more easily to the front page.

Numbers are magical; they tell so much with less symbols. Imagine that you’d have to draw 78 sticks in order to represent the same corresponding number otherwise. Therefore, exploiting their incurable weakness, humans will almost always fall victim to this simple trick. You know that firsthand since you’re already here, don’t you?

3. Proofreading Is For the Unprofessional

Writing about controversial topics is a sure way to invite an infinite stream of commentators. If you can’t write about such topics, worry not! A lack of proofreading will definitely attract a herd of special grammar nazis instead. Just remember to write in an inconsistent style. Ignore those red-lined words pointed out by Microsoft Word spellchecker; they only prove how much envy Microsoft has for your unparalleled writing talent.

4. Everyone Can Google

Wasting hours on research before writing? Nah, that’s not us! Readers can use Google to verify any crazy stuff you published. If they find anything wrong, then it’s for the better: negative comments are comments after all.

Sometimes you need to rely on other sources of information, either due to your total ignorance of the topic or because you are too tired to make things up. In such cases, you better hide the references you have used. How much you “borrowed” from those references should stay a top secret to the very end.

5. Be a Lonely Wolf

You may have contemplated the idea of posting your article in a publication. I’m glad I got to you just in time then. You are already a well-established writer, having reached your peak of 7 claps on Medium just last week. Are you really going to endanger your fame and image by collaborating with a publication? You don’t need to think twice about it.

Imagine those cunning editor-in-chiefs lurking in the darkness of their offices behind old screens waiting for you to submit your article to them. They swore they’re not after your money, but if they suddenly changed their terms and decided they wanted a share of your earnings? Can your risk losing a portion of the $3.57 you earned over the few last months? Hell no!

To Wrap It Up

By the time you’ve reached this section, the effect of applying the techniques above must be driving six-figure numbers to your bank account. You can finally stare back fearlessly at your life partner who has been financially supporting you for so long.

The 5 Underrated Tips to Become a Millionaire Writer was originally published in The Haven on Medium, where people are continuing the conversation by highlighting and responding to this story.