Some Tips For Monetizing Work In Open Source

Free and open-source software (FOSS) doesn’t have to be entirely separate from the concept of bringing in money, but the path to monetizing is maybe less clear than it could be. To help address this, [Drew DeVault] has shared some concise thoughts on different ways to monetize FOSS work and projects. [Drew] observes that monetizing one’s own projects is one approach, but that it is entirely possible, and less difficult, to make money by participating in open source work in a more general sense.

There are companies and organizations out there who may make their money otherwise, but are nevertheless involved in or reliant upon open source software for running their business. Such companies are a good starting point for anyone looking to work in FOSS, and [Drew] shares a clever tip for finding them: use git to clone the software repositories of large projects that are of interest to you, then run this command:

git log -n100000 --format="%ae" | cut -d@ -f2 | sort | uniq -c | sort -nr | less

This will extract the domain names from the last 100,000 commits to the repository in question; a good set of leads to companies and organizations that are invested enough in FOSS to contribute, and who may be willing to pay for such work.

There is also the option of monetizing one’s own projects, which [Drew] says is the more difficult approach. He shares tips on monetization options, but cautions that fundamentally one is building a business when going this route. One should therefore be prepared to face the attendant non-software-related problems in the process.

[Drew] runs SourceHut and works entirely in FOSS, but still makes time for fun hacks like using this old line printer to emulate the experience of working on a teletype, which is how it was done when terminal output went to paper, instead of a CRT monitor.

13,000 Regular Expressions Make An Editor’s Life Easier

Being an editor is a job that seems deceptively easy until you are hauled over the coals for letting a textual howler go to print (or website). Most publications have style guides to ensure that their individual voice is preserved, but even the most eagle-eyed will sometimes slip up in their application. At the Guardian newspaper in the UK they have been struggling with this against an ever-evolving style guide that must adapt to fast-moving world events, to the extent that they had a set of regular expressions to deal with commonly-occurring problems. A lot of regular expressions, in fact around 13,000 of them.

Clearly some form of management was required, and  a team of developers set about taming this monster. The result is Typerighter, their server-side document-checker, which can be found in a GitHub repository. Surprisingly for rule management they started with a Google Sheet, a choice which proved unexpectedly robust when working with such a long list even though they later replaced it. The back end doing the job of text matching was written in Scala, and for the front end a plugin was created for their Prosemirror text editor.

For a publication of course this is extremely interesting, but where’s the interest for hackers? The answer lies in any text-processing engine that uses a lot of regular expressions; those of you who have dabbled in this space will know how unwieldy this work can become. Any user of computational linguistic techniques in the pursuit of language processing could probably find much of interest here.

If you’re a bit hazy on regular expressions, how about the episode on them from our long-running Linux-fu series?

Serial Studio: Easily Visualise And Log Serial Data

Outputting data from a microcontroller over a serial port is convenient and easy, but formatting, visualizing, and analyzing the data can be tedious and frustrating. [Alex Spataru] knows this all too well, having spent too many hours building and debugging custom dashboards. To save himself and others the same frustration in the future, he created Serial Studio, a tool for quickly building dashboards for serial data.

The only input required for Serial Studio to create a dashboard is a simple JSON structure specifying the data’s format, and how it should be grouped and displayed. Originally Serial Studio required all the JSON data to be sent over serial, which is fine for simple data but quickly becomes cumbersome for more complex applications. To solve this, [Alex] added a feature allowing the JSON document with the format information loaded from the computer, while only the data is sent over serial.

Serial Studio includes several visualization options, including raw line graphs, bar/level indicator, dial indicator, the artificial horizon for IMU data, or a map widget. It can also output the formatted data to a CSV file for further analysis in other software. A console window is also included for viewing raw data or debugging purposes. See the usage demo after the break.

We like Serial Studio’s ease of use and adaptability, and we’ll likely use it for our own projects in the future. It is compatible with Linux, Windows, and Mac thanks to the Qt framework, and the code is open-source and available on GitHub.

If you’ve ever watched one of the BPS.Space model rocket launch videos, you’ll know how critical data logging, visualization and analysis is for [Joe Barnard]’s work. Serial Studio is perfect for such applications, and [Alex] used it extensively for simulated satellite competitions at his university. Continue reading “Serial Studio: Easily Visualise And Log Serial Data”

SOUL Wants To Process Your Audio

Abstraction is the core of nearly all progress in computing. Unless you are fabricating your own semiconductors and drawing wire, we all create with building blocks ranging from components like CPUs, to operating system functions, to specialized libraries. Just as you wouldn’t want to spend your time deblocking disk records or rendering fonts for output devices, you probably shouldn’t have to think too much about audio data. While there are some powerful audio processing libraries out there, a new embeddable language called SOUL (SOUnd Language) is now in version 1.0 and wants to help you create efficient code for processing audio.

The goal of SOUL is to target a runtime that can run on CPUs, but is better on DSPs. The code aims to be secure and real time with no pointers, garbage collection, and other things that typically interfere with audio processing or security.

Continue reading “SOUL Wants To Process Your Audio”

Naming Names

We have all heard that good variable names are important for creating readable programs — advice that will serve you well when you come back to your code two years later, or even twenty. Sometimes, when you are so deep in the zone and begin to question a variable name that you made three levels up the calling hierarchy, it can be helpful to take a step back and review your variable naming conventions. The wikipedia article on computer program naming conventions is a good starting point, where you can dig into the nitty gritty of Hungarian notation like bFlag, case separated names like camelCase, and so on. But sometimes you have to go meta, and need names to describe the names themselves.

For example, in everyday usage the terms parameter and argument are often used interchangeably. But strictly speaking, a parameter is a placeholder, the variables in a function declaration for example (see image above). An argument is the actual value itself, say the number 50.334 in the example.

We recommend that units of measure should always be clearly specified in your comments, perhaps even in the variable names if you’re mixing different systems in the same program. At Hackaday we prefer to use SI units, check out NIST SP 330 if you’re interested. But invariably, there are going to be exceptions for years to come. We like to deal with those at the edges during I/O if possible, thus keeping a consistent set of units in the core of the program.

What about the terms number and value? We like to think of a number as being a kind of value. For example, a function’s return value could be a number, say a velocity. Or it could return an enumeration or a boolean. Sometimes the perfect meta-name for something will collide with a reserved keyword in your programming language, names like string or data for example. In these cases you have to be creative and find suitable synonyms, perhaps text and payload.

Using consistent and precise language can be tedious, but it can be just as helpful as good commenting and variable naming practices. Do you have any examples where precise terminology such as this has been been helpful or perhaps tripped you up? If so, share in the comments section below.

 

 

Porting Firefox To Apple Silicon: Tales From The Trenches

For any smaller and larger software product that aims to be compatible with Apple’s MacOS, the recent introduction of its ARM-based Apple Silicon processors and MacBooks to go with them came as a bit of a shock. Suddenly one of the major desktop platforms was going to shift processor architectures, and with it likely abandon and change a number of APIs. Over at Mozilla HQ, they assumed that based on past experiences, Apple’s announcement of ‘first Apple Silicon hardware’ would also mean that those systems would be available for sale.

Indeed, one week after the November 10th announcement Apple did in fact do so. By then, Mozilla had worked to ensure that the Firefox codebase could be built for Apple Silicon-based MacOS. Fortunately, through the experiences of running Firefox on Windows-on-ARM, they already had gained a codebase that was compatible with 64-bit ARM. Ultimately, the biggest snag here was the immature Rust language and dependency support for Apple Silicon, which set back the first release.

When it came to the distributing of Firefox on Intel- and ARM-based Macs, the decision was made to package both versions of the application into a so-called Universal Binary. While this pads out the size of the installer, it also means easier distribution and would not affect the built-in updater in Firefox. This also allowed for an easy fix for the Google Widevine DRM module, for which no Apple Silicon version was available at first, allowing the same module for Intel to be used with either Firefox version via the Rosetta 2 binary translator in MacOS (as we covered previously).

After this it was more or less smooth sailing, with some Rosetta 2-based glitches and MacOS Big Sur-related bugs that spoiled some of the fun. What this experience shows is that porting even a big codebase like Firefox to Apple’s new platform is fairly straightforward, with lack of support from toolchains and other dependencies the most likely things that may trip one up.

The Rosetta 2 feature, while helpful, also comes with its share of gotchas as the Firefox developers found out, and of course there is a lot more optimization that can (and should) be done for such a new platform.

The (Probably) Most Thoroughly Commented Linker Script For The SAM D21 MCU

Linker scripts are one of those things which nobody who does software development really wants to deal with, but like many things in life sometimes they are inevitable to make things work. Although one could keep pretending linker scripts do not exist and let IDEs handle such pesky details, some of us suffer from this unfortunate condition called ‘curiosity’ and just have to know. People like [Thea].

Recently, [Thea] wrote a blog post on exactly what the linker script generated by the Microchip IDE for a Cortex-M-based SAM D21 project does. The result is a nicely annotated overview of the file’s contents, accompanied by links to the Arm and GCC documentation as well as other references where appropriate. The entire linker script (.ld file) can be viewed on GitHub. With the SAM D21 being a popular choice for Arduino and Arduino-compatible board, this article is a good starting point to understanding what a linker script does and how it affects one’s project.

For other (Cortex-M) MCUs this linker script is also useful as a starting point. Especially knowing which sections are required and what changing them affects in the final (ELF) binary and the firmware that is ultimately written to the MCU. We recently covered linker scripts for Cortex-M as well, along with the concept of memory-mapped I/O.