Category: Blog

Your open source project will outlive you! Will the Future be able to use it? [updated Oct 2023]

Jeff Luszcz

tombstone saying "in loving memory"

Every decade or so the technology world gets punched in the face by a problem requiring poring through massive amounts of code written well before many of us were born.

In the late 1990s it was the Y2K problem when two digit years were no longer sufficient.

 

In the 2008 financial crisis COBOL based systems required hand editing in order to change state employee salaries en mass.

 

In 2020 we had the Pandemic related economic impact requiring Bank and Employment system’s code to be modified, many of which again were written in COBOL!

 

In 2032 we’ll have the Y2k38 problem when the Unix time will overflow causing software issues akin to Y2K.

 

While many of these systems were closed source and proprietary, open source systems are starting to dominate the software landscape. Much like your grandparents’ hammer, these examples show us that useful tools will almost always outlive the person who first selected or created them.

 

Besides the question of maintainability and programmer experience with very old languages like COBOL, questions of intellectual property and software licensing will complicate the usability of open source software over the next 50 years and beyond.

Think about Open Source Licensing!

As part of software due diligence (when a company purchases another company and confirms that the source code they are buying is correctly owned, licensed and documented) I have had the experience of trying to track down the ownership and licensing of code decades old. This type of software archeology requires access to archives of source code, books, magazines, blogs and other places that programmers have published software over the last 60 years! In many cases the true origin of some source code is lost to time, or can be only partially known.

 

Questions such as “Who wrote this?”, “Did they expect others to freely use this source?”, or “Does a commercial company own this?” are common.

 

It is important to make these types of answers clear for those who come after us.

 

The most important of these is to specify an open source license for the code you are publishing, even if it’s just a “single page” or block of code. If it’s worth putting on the Internet, it’s worth telling people what its license is.  There are many suggestions on how to label code to make the copyright and license clear, but I strongly suggest that each file contains a copyright statement and at least a SPDX license identifier (See https://spdx.org/licenses/)

 

This allows someone in the distant future to know who wrote the source code and what the obligations are even if only a single file remains.

 

You may decide to change the license after you die to something less restrictive or even dedicate it to the Public Domain or Open Source equivalent like the Creative Commons 0 license (CC0). See https://creativecommons.org/public-domain/cc0/

Who do you depend on?

Document all your third party dependencies, including dependencies of dependencies. There is no guarantee that any of our current repository managers will still be working decades in the future, but your code may be. By listing these dependencies, you help the Future build and run your code.

 

In a similar vein, your build system and running environment should be documented as well. For example, if you depend on a certain make system or database to be installed, call these out in separate build and running environment documentation. 

 

Some projects take care to store away copies of all the source code, tools and environments that they require in order to build and run their projects. A copy of the source code and binaries that are downloaded through repository managers like Maven or NPM may be the only way the future generations may be able to build and run your software.

Till Death Do Us Part

In the short term, understand that source code is considered property. What happens after you die should be clearly specified. In most places the ownership of your code will pass on to your heirs, but possibly with complicated and divided ownership.  Do you want anyone in particular to be the new code owner (or someone outside of your family)? In this case your will (or related documents) should make this clear.

 

While everyone should have the permissions available under your open source license for the duration of your copyright, you may wish your heir to have the ability to “own” the code just like you do.

 

By making the ownership clear, they will then have the ability to change the license for your code, just like you likely do now. This means they may have the permission to also sell commercial licenses to this code, or change the open source license of the project. An open source project with multiple contributors has additional concerns about ownership. You may need to make clear dividing lines between projects you own outright as opposed to projects you contribute to, or have others contribute to.

 

Explicit ownership, licensing and future plans should be clear for all resources including source code, images, art work, sounds, documentary and anything else created by humans for the project. 

 

Do you want to change the license after your death, or after a certain amount of time?  Make these changes clear as well. Some may want to open previously closed source, or change to a Creative Commons Zero (CC0) license or Public domain declaration.

 

Similar questions may come up in the case of divorce. While it’s often clear who owns code you write when “on the clock at work”, the code you write at home may have complex ownership issues.

 

Go beyond the code!

An additional thing to consider is account access, logins, domain names and payments.

Typically we tell everyone to keep their account information private and secure. This may be at odds with your desire to keep your project going even after your death.

Keeping a list of domain names, third party services and other account information related to your project can help the heirs to your code keep the project going.

Bear in mind that, after your death, certain accounts may be locked, go away or may be controlled by people other than the code owner. Since these may be considered property, clarity around transfer of ownership is extremely important if you wish to keep the project moving forward.

 

As with most things involving intellectual property and life events, it is best to consult a lawyer to understand your best options.

Specifying A Successor for your Online Accounts

 

Some online accounts allow you to specify a Successor or have a specific feature for handing over inactive accounts. For example Github has a Deceased User Policy which allows “next of kin, a pre-designated successor, or other authorized individual (which could include a collaborator or business partner” to get access to your account after you die. 

 

For more information see: https://docs.github.com/en/site-policy/other-site-policies/github-deceased-user-policy

 

Github allows you to appoint a “successor” which makes it easier for them to legally access the account information. This transfer of accounts is unlikely to affect the legal ownership of the source code and project’s intellectual property. See https://docs.github.com/en/enterprise-cloud@latest/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/maintaining-ownership-continuity-of-your-personal-accounts-repositories#about-successors

 

Google has a similar set of features called “Inactive Account Manager” to allow someone to take control of your Google Gmail and other Google products after your death. See https://support.google.com/accounts/answer/3036546

 

Rest in Peace!

A little care and effort in the present can save the community a significant amount of time in the future. By specifying a license, documenting project dependencies, and clearly transferring ownership you can make sure your code stands the test of time.



Blogging for Overly Busy Experts

Jeff Luszcz

I was talking with an old colleague recently about an age-old problem. He said, “I should write more but I’m just too busy.” It’s true, it’s really hard to justify sitting down and writing something that isn’t part of a deliverable, may not even be read and worst of all surely isn’t billable! Decades of experience get hidden away, only showing up on phone calls and emails. We often joke, “Our best work is under NDA.”

picture of a typewriter and paper

In the end though, public writing is one of the best things that you can do to show off what you know, teach others and make the case that you are the person that should be trusted by your customer for those billable hours.

 

Here are some of the things that I’ve found helpful for getting words down on paper.

 

Start writing!

First off, whether you write one article a year, or an article a week, I can assure you that you will look back on your writing with pride. Get something on paper and publish it.

 

Get a home for your writing!

Figure out where you want to publish your writing. It could be an internal blog, a Slack channel, your external company blog or even a self-hosted blog with or without a custom domain. Sites like LinkedIn, Medium and WordPress make it pretty easy to make a space for your articles. I like getting this figured out first, since once your article is done, you are going to be antsy to get it out there right away.

 

Keep track of ideas!

I keep an electronic to-do list to keep track of the tasks I need to do. I’ve made a folder just for blog and article topics. Whenever you get a good idea (I always seem to get them when I’m washing dishes!) get it recorded. You might not get around to writing on that topic for a year or more, but having a bank of ideas ready to go really helps the writing process.

 

Review that list from time to time. More ideas will almost certainly come to you, write those down as well. I currently have 213 items in my “Blogs to write” folder. (I should write more!) Some of the stored away items are questions, some are comparisons, and some are simply the title of an article. After a while you will find that you have a stable of topics that you could crank out articles for with only a little preparation.

 

 

Try the “old favorites” to get started!

What are some good ideas that you could get started on today?

 

There are some articles that “write themselves”, they are often either topical or document part of your day-to-day activities.

 

For example:

  • Top Ten Lists / Listicals
  • How you got started
  • Trends or things you find interesting
  • A technology you like and why
  • The hot news item du jour
  • The year in review
  • Take a slide from a webinar and turn it into an entire article
  • Why some topic is important to you

 

You could probably start riffing on any of those topics and get something interesting out right now.

 

An example to get started

Picking a top 5 or top 10 can be an easy onramp to writing an article. Start first by writing your top 10 list. Then, expand each item to explain what they mean. Write an introduction explaining what top 10 items you are going to go through and finally wrap up your article with a couple sentences. It’s fine to be a little cliché if it helps you wrap up your first few articles. Find some stock phrases that help you close up. Name it something engaging or descriptive and then fix any typos and problems in an editing pass or two. Then Publish!

 

 

The writing process

The hardest thing is the first word, that’s why I often write my conclusion first! You often will know what you are trying to tell people, so tell them, and then back fill the details and intro as needed.

 

Outlines or sentence prompts really help. Get some words and phrases down in your document, as many as you can at first. You don’t have to fit them all into your final piece. Some of them become perfect future articles whether or not they get in. Filling in the meat of the article is a lot easier when you’ve blocked out most of the content in the first phase. I like writing a series of topic headings and then going back and fleshing them out. Prompts work!

 

Use Speech to Text (if that works for you). Many phones, word processors and computers come with free speech to text. I’ve experimented with riffing on topics while taking walks and then cleaning them up later. This can be a great way to get a couple hundreds of unedited words on the page.

I’ve found it works best if you immediately move over to the editing and writing process since there’ll be enough recognition mistakes that you lose track of what you meant if you let too much time pass.

 

Figure out how many words you want to target. For me around 1000 words is a sweet spot. I often will write a couple hundred more words than that, and then tighten things up in the editing process. This amount of text takes me an evening to write when the words are flowing. I like to do an editing pass when I’ve hit my word count target, but then also will sleep on a piece and re-read the next day for my final editing pass.

 

 

Build on what your write

Use what you wrote as a stepping-stone to further content. A sentence can become a new article, or you can expand the topic to a conference proposal or talk.

I’ve had great luck turning articles into webinars (and vice versa). This is a great way to get your words in front of a new audience. Some articles are evergreen and can be updated for the next year, others can be reworked to expand on one of your paragraphs.

 

It’s your text; don’t let it stop working for you.

 

Let people know what you wrote

 

At first, few people will know what you’ve written. Let people know by announcing your article on social media like Twitter, LinkedIn and similar sites. Send links to your coworkers and customers. I’ve found that customers love this type of content and will often forward it around their companies and peers. It goes beyond the thing you are selling and shows you are there as a partner, not just to sell more product.

 

Wrapping up

 

Writing is a muscle and when exercised, becomes stronger. 750 words on a topic feels like a walk around the block when you’ve trained for a marathon.

 

Everyone ends up with a different voice and style so figure out what works for you.

 

In the end, the most important thing is to write. Get your knowledge and thoughts out there.

 

I’d love to see what you write!

 

 

I’m speaking at All Things Open on 10/19 at 2pm ET

Jeff Luszcz

Are you thinking about selling your company? Are you building a software product? Want to jumpstart your knowledge of Open Source and its impacts on security, compliance and valuation? Join my workshop a week from today at all Things Open.

“Open Source Licensing: Types, Strategies and Compliance” Monday October 19th from 2pm -3:45pm ET (11am PT)

 

Free Registration link: https://2020.allthingsopen.org/register/

 

What is Zebra Cat Zebra?

Jeff Luszcz

As long as I’ve had to tell people my last name, I’ve had to spell it out. Teachers, friends, coworkers, random companies, and so on need a little help after hitting the 4 consonants in a row.

L-u-ess Zebra Cat Zebra has been a helpful hint passed down the generations to remember how to spell my name. 

This is also the place I’ll be posting articles and thoughts on open source, security and technology in general. 

Please let me know if you have any questions or comments about what I write. My contact info should be available in the menu.