After 2 years in the role, I'm moving on from my position as a Technical Lead at Redgate Software. I'd like to share my reflections on that time, which I hope will be particularly helpful for new tech leads.
The tech lead role varies across the industry. At Redgate, it's a mix of line management, along with individual code contributions (when you have time). With that in mind, here are the top 5 things I learned as a new technical lead.
<h2>Enabling others to execute is now your job</h2>
As an engineer, you're mainly an individual contributor. Your performance is based on the things you do directly every day, which is mainly writing and reviewing code.
As a technical lead, things are different. The more you focus on completing tasks yourself, the less effective you'll be.
I've found that for a tech lead, your primary focus is all about enabling your team to execute. Your output is now the sum of your team's output. If they're all doing a great job, then you are. And if they aren't, well... then you aren't.
Ironically, as the team leader, you now have less direct control over how tasks are executed. It's up to individuals on your team to chop through the work - so they'll decide how to go about things.
When things go pear shaped, the temptation is to dive in and start fixing things yourself. However, leading like this is going to leave you overwhelmed and burnt out.
You have to trust your team to execute. Get off the critical path, and delegate as much as you can. If you aren't confident anyone on your team can deliver, then you need to start skilling people up rather than diving in yourself. You need to teach, train, coach, or mentor your people to be the heroes of the story.
<h1>Leadership is a skill, not magic</h1>
What do Augustus Caesar, Steve Jobs, and Atilla the Hun all have in common?
I have no idea - other than they were all leaders.
Some will have you believe there's some magic talent that unites all great leaders.
I've come to believe that's mostly nonsense. There's no secret sauce. I believe that leadership is a skill that can be learned.
Leading consists of concrete and well-defined skills - delegating, coaching, mentoring, presentation skills, business knowledge, technical knowledge, project management, defining goals, and so on.
There are many ways to learn these skills - books, courses, podcasts, or just having a go and reflecting on the experience.
I can recommend these resources to start with:
<ul>
<li><a href="https://www.goodreads.com/book/show/33369254-the-manager-s-path">The Manager's Path</a></li>
<li><a href="https://www.goodreads.com/book/show/11721966-good-strategy-bad-strategy">Good Strategy Bad Strategy</a></li>
<li><a href="https://www.goodreads.com/book/show/29939161-radical-candor">Radical Candor</a></li>
</ul>
I may follow up in future posts with more thoughts about these books.
<h2>It's critical to understand people's roles</h2>
As an engineer, I only really understood what other engineers did. Product Manager? Product Marketing Manager? Development Lead? Pre-Sales Engineer? Uh...
As a tech lead, a bunch of people with unfamiliar roles are suddenly your stakeholders. I found it was critical to get up to speed with what these roles meant.
You need to get a sense of what their priorities are, what you can expect from them - and what they expect from you.
How you manage your relationship with people in each role must vary. For a direct report, like an engineer on your team, you have a right to shape what their role looks like to some extent.
For instance, if you think it's reasonable for a senior engineer to facilitate a team retrospective, then you can tell them to do that (whether they'll be willing or able is a different story).
For your peers, it's trickier - you can't just tell them what to do. You have to think about how to influence them, and conversely, you must be reasonable and sensitive to what they want out of you too.
Your Product Marketing Manager wants the team to write a new blog post for the newsletter every week? Ok, let's set some expectations about how much of the team's time I'm able to commit...
Given the array of roles you'll need to get to grips with, it's easy for mis-alignments to creep in. You'll need be pro-active in learning. There's no harm in grabbing someone for a quick chat just to make sure you're on the same page.
<h1>Get used to awkward</h1>
Disclaimer: Maybe I'm just a particularly awkward individual. However, I've found that as a tech lead (particularly doing line management), you're going to have some awkward conversations.
Telling people 'no' is awkward
Dealing with resignations is awkward
Delivering difficult feedback is awkward
Facilitating meetings with too many people and no one is aligned is very awkward
The list goes on. However, this is something you need to get used to.
It's the 'people side', right? The bit no one likes about the job. Doing this well is hard, and I wouldn't say I've quite cracked it.
You have to take such awkwardness on the chin. Be professional and gracious. Don't take it personally - it's not a reflection on you if you walk away from a meeting feeling a bit weird.
The more you have to deal with awkward stuff, the sting of cringe will begin to numb. You'll be more used to it, and eventually, maybe you'll just figure out how to deal with it.
<h1>Outcomes over everything</h1>
Finally, I've realized that outcomes are everything.
In tech, we're privileged in that ultimately we're employed to deliver business impact, not just meet some output criteria.
That's in contrast to some jobs that are very output focussed - say a Deliveroo driver who is paid in proportion to the number of meals she delivers.
In traditional manufacturing, the 'business' and 'production' aspects are probably more separate than in tech. For instance, <a href="https://auto.howstuffworks.com/why-the-ford-edsel-failed.htm">when Ford executives decided to build the Edsel</a>, it was just a case handing the design to the workers and cracking the whip on the production line to make enough cars to meet demand.
Tech isn't like that (or at least it shouldn't be). Things move way too quickly, and meeting user demand isn't a case of just outputting more units.
In tech, one small team with a sharp focus and good business understanding can have a massively outsized impact. Just look at companies like Basecamp or Slack - a few dozen to a few hundred engineers impacting millions of people.
Therefore, your work really needs to be measured in business impact. The 'outputs' of an engineer (lines of code written, commits shipped etc) aren't really a good proxy for value at all.
So, as a tech lead, I've learned that you need to steer your team to deliver on business impact, rather than meaningless metrics of productivity.
This is of course really hard. There are many approaches used in industry - <a href="https://www.whatmatters.com/faqs/okr-meaning-definition-example">Objectives and Key Results</a> is the format we used at Redgate. It takes alot of collaboration with your team and stakeholders to zero in on valuable work.
<a href="/posts/impact-is-the-only-thing-that-matters">I've written other posts that go into more detail about this</a>. I'm sure it's a lifetime of learning to get even remotely good at this.
<h1>Summary</h1>
So those are my tips from 2 years of being a technical lead at Redgate. I'm thankful for the opportunity I've had to lead an engineering team. It's a great experience that will challenge and grow your skills like nothing else.

5 Things I Learned as a New Technical Lead

Building on my previous post <a href="/posts/why-write-a-line-of-code">'Why write a line of code'</a>, I've continued to reflect on our jobs as engineers in the context of a wider business.
In that post I made this observation:
<blockquote>
The only reason you need to write code in a commercial organization is to ensure the company makes a profit
</blockquote>
An uninspiring conclusion! But right now I'm convinced it's accurate.
Before we despair too much, I'd like to develop this idea a bit more. Yes, if you're employed by a business, the name of the game is profit. As an employee you cost the business something (salary, training costs, HR overhead, and so on). In return, the business hopes to get some value out of you - ideally more value than they invested in you originally.
Yet the value of an employee is hard to measure. It's very rare that I can point at a specific piece of work I do and say 'That resulted in X dollars of revenue'.
Thinking in terms of profit isn't helpful, even if it is the ultimate aim. It's depressing, cynical, and boring.
Instead, we ought to think deeply about the wider effect of the work we choose to do. Even the smallest pieces of work cause a chain reaction, some kind of ripple effect into the wider world.
<h2>Pick high impact work</h2>
Let's take a trivial example - a user reports a bug in the morning, you spend the day fixing it, and ship a release in the afternoon. What is the impact of that work?
To measure the impact you might ask questions like:
<ul>
<li>Did we ultimately unblock the user?</li>
<li>Does the fix affect many people, or just a few people?</li>
<li>Does this affect the company's reputation?</li>
<li>Did you share the knowledge of the fix with your peers? If a similar issue arises, is the team now more prepared to fix it?</li>
<li>What did you learn by fixing the issue? Does it contribute to your progression as an engineer?</li>
</ul>
In fact, there's an unlimited number of questions you can ask.
So here's my point - before you pick up any piece of work, estimate it's impact by asking questions like these. If the answers are 'meh, not really', then perhaps you should rethink picking up that work.
Let's change things slightly - another bug report comes in. It affects our biggest customer. It's super urgent, and it's clear thousands of other users will hit the problem eventually. However, the fix will only take a few minutes of your time.
Of course, you'd fix that one too. A high impact piece of work that only takes a few minutes? Great!
Observe, therefore, that being busy doesn't mean being productive. It'd be better to come in for 20 minutes for that high impact work, than work a full 8 hour day doing low impact.
When put in such stark terms, it seems obvious. Yet I think it's easy to sleepwalk into spending a lot of time on low impact work.
If you can come up with a high-impact feature that takes one hour to design, implement, and ship - I'd say that's more valuable than spending a full 40 hour week working on trivia.
Of course, since impact is hard to measure, it seems necessary that we sign contracts that tell us to sit at our desks for 40 hours a week. It'd be hard to imagine an agreement that demanded '5 pieces of impactful work a month', for instance.
At any rate, the principle remains - focus on the high impact work. The lower impact tasks ought to come second on your priority list.

Impact is the only thing that matters


I become a technical lead about a year and a half ago. At Redgate, this involves line management, along with writing code (if one can find the time).
When I first got the role, I was given total freedom over how my team should operate. So, my first thought was to establish a simple working pattern.
We were a new team of only a few engineers, so we didn't have any processes to fall back on. I set about getting us working in two week sprints, based on what I'd seen other teams do.
Sprints are a very common way of organizing technical work. Get the team together, and review the high level stories. Break them down into sub tasks, estimate how long they'll take, and then create some kind of prioritized backlog. Chop through the backlog over the next two weeks, and then maybe have a retrospective. Rinse, repeat, ad infinitum.
This made sense as I was finding my feet as a team lead. However, I've recently spent some time thinking more deeply about this whole cycle. In my head I've broken it down from first principles, then built it up again.
Doing this has led me to some insights that I think are worth sharing. In this post, I'll explain my current thoughts on the matter.
<h2>What Are We Even Doing Here?</h2>
First, I wanted to identify a strong reason for the team to even come into the office (virtual or otherwise). This might sound philosophical - and it is. Why even write a line of code?
Well the short answer could be 'my boss wants me to'. However, as a team lead, I sort of am that boss (as scary as that thought is). However, having been promoted from engineer to manager, I didn't suddenly receive a revelation about that mysterious 'why'. I certainly didn't get some sudden motivation to boss people about.
Engineers, myself included, are good at coming up with 'whys' on their own. I like learning new things. I like solving problems. I like to learn about new technologies.
Noble, but it's obvious that these aren't good business reasons to write code. Companies don't exist to fulfil our desire to solve problems, sadly.
Sometimes we come up with 'whys' that sound business-like, but still miss the mark. We need to unblock these users by fixing their bugs. We need to improve the UX of this interface. We've need to pay off this tech debt so we can move faster.
More noble lies, unfortunately. Again, companies don't exist so we can pay off tech debt.
I think the ultimate answer is simple, yet disappointing. I think I've realized that the only reason you need to write code in a commercial organization is to ensure the company makes a profit.
<h2>A Chilling Conclusion</h2>
It's a disappointing conclusion to be sure. It doesn't mean those noble ideals of writing clean, maintainable software that solves hard problems are any less valuable. However, it does mean all those ideals must be bent in service of ensuring your organization makes a profit year on year.
Yet it's a big jump to make. How does my pull request really impact the company's bottom line? And really, such concepts are so far beyond us engineers. Isn't this question for the lofty heights of upper management?
Well, individual engineers can get away without knowing how their work impacts the company's commercials. However, the team lead does need to have an understanding of that relationship. How can I justify spending a week of my team's time on anything if I don't understand what the business impact might be?
So my second insight was around connecting the dots from my company's bottom line, down to day-to-day actions of an engineer on my team. I realized my role was to somehow translate what was going on up in the mystical land of executives and senior leaders, to the every day engineer just fixing up her pull request for the afternoon.
The key to that, in my opinion, is all about setting crystal clear Strategic Objectives.
<h2>Strategic Objectives</h2>
A Strategic Objective is a description of a goal that will have a positive impact on the business. That impact ought to be somehow correlated with making a profit for the company. They must be ambitious, but not impossible. Specific, but not prescriptive. Long term, but not pie-in-the-sky.
You need to look at the world - market, your users, technologies, trends, and everything else - and come up with an objective that is crystal clear, actionable, joined up with reality, and will have the business impact (profit, usually) that you desire.
For instance, I might look at the numbers of the software product my team owns. Well, we have X hundred customers. I can see there's a trend in the market that we're well placed to capitalize on by building new features that support people who are following that trend.
So we might have Strategic Objective: 'Win more customers by delivering new features that exploit trend Y'.
It's obvious how hitting that objective might translate into more profit for the company. We invest a few months of engineering time to, hopefully, get new customers who repay that investment and then some - providing a return on investment.
Of course, coming up with such Strategic Objectives is hard. That's why you have senior strategists like CTOs and architects, who come up with top level objectives that should inform your own. You need product managers, who can evaluate the commercial potential of a given approach. You need marketing people to help draw those new customers in. And on it goes.
Of course it's easy to get this wrong, which will result in disaster. There are many methodologies employed to reduce this risk - Objectives and Key Results (OKRs). Key Performance Indicators (KPIs). SMART goals. Objectives, goals, strategies and measures (OGSM). And so on.
This is tough as nails. It's why there are endless books, courses, and university courses about business and strategy. Ultimately, you need some way to formulate an expression of a task that, if successful, will impact the business in a positive way - directly or indirectly resulting in cash profit.
<h2>Sprint Planning</h2>
It's one thing coming up with Strategic Objectives - then quite another to actually execute on them.
So let us return to sprint planning. I realized that all I need to do is get one or more carefully formulated Strategic Objectives in front of the team from week to week. From there, we have a way of finding the intersection between the things we could do, and the things we should do.
Yet this is also extremely hard. Give a team an objective like this, and see what happens:
'Increase trial license requests by X % this quarter'
I'm not being sarcastic, actually. Some teams might be really well equipped to smash this objective. Others might have no idea, and revert to primal behaviors of fixing bugs and debating which component to refactor next.
So my last revelation was that really, it's up to the team lead to ensure Strategic Objectives are translated into actionable technical tasks.
No, updating our dependencies has no strategic relevance. It might be clean code, but it's pointless.
Yes, writing a blog post that we can circulate might have strategic relevance. Are you comfortable doing that? Perhaps we can catch up about it after planning?
From there it's a case of continually joining up the dots. Bring the team along in defining Strategic Objectives. Have open discussions about the why, not just the what. Coach, mentor, and train your team to execute on strategically relevant tasks, not just the tasks they think are cool and interesting. Help your team to really understand why they've been summoned to work each day.
<h2>Closing thoughts</h2>
So this is my mental model of how figure out what an engineering team should actually do. Getting each step right is probably a lifetime of learning. However I'm willing to take it one day at a time.

Why write a line of code?


Designing a command line interface can be tricky. By 'design', I'm thinking of things like usability, consistency, and the like - not the actual function of the application.
I see a number of challenges in designing a CLI. You want the commands to be easy to understand, but not too verbose. You need to be consistent with your context - for instance, <a href="https://docs.microsoft.com/en-us/powershell/scripting/developer/cmdlet/approved-verbs-for-windows-powershell-commands?view=powershell-7.1">PowerShell has a list of 'approved verbs' for commands</a>.
It's also hard to communicate an overall sense of the design. Whereas a graphical application can be built from a set of high-fidelity mockups (or napkin sketches), a command line application doesn't lend itself to being represented in such an simple manner.
So how do you design for a command line? In this post I'm going to share some of my thoughts on the matter.
<h1>Use consistent patterns</h1>
Consistency is important in all aspects of design. Consistent design makes it easier for users to remember commands, and easier to figure out what an unfamiliar command might do.
For instance, here are some command line arguments for <a href="https://git-scm.com/docs/git#Documentation/git.txt---exec-pathltpathgt"><code>git</code></a>:
<ul>
<li><code>--html-path</code></li>
<li><code>--man-path</code></li>
<li><code>--info-path</code></li>
</ul>
There's a nice naming pattern here - <code>something</code> dash <code>path</code>. With consistent terminology and naming pattern, these options naturally form a group.
So, given what <code>html-path</code> does:
<pre><code>Prints the path, without trailing slash, where Git's HTML documentation is installed and exit.
</code></pre>
You can rightly guess that <code>man-path</code>, and <code>info-path</code>, do a similar thing.
<h1>Flags can be powerful</h1>
Flags are a common pattern in command line design to present an on/off choice to users. <a href="https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-pack">Let's look at the <code>dotnet</code> command line for examples.</a>
There are many arguments that can be configured:
<pre><code>--output &#x3C;OUTPUT_DIRECTORY>
--runtime &#x3C;RUNTIME_IDENTIFIER>
--verbosity &#x3C;LEVEL>
</code></pre>
...and so on.
And many arguments (flags) that change behavior just by being present:
<pre><code>--no-restore
--no-build
--include-source
</code></pre>
...you get the idea.
Flags are a great way of providing on/off configuration to users, since they are more terse.
For instance, writing <code>--no-restore</code> is easier on the eyes than <code>restore=false</code> or <code>restore=on</code>.
Let's look at a longer command:
<code>dotnet pack --force --include-source --include-symbols --no-dependencies</code>
Against something like:
<code>dotnet pack --force=true --include-source=true --include-symbols=true --dependencies=false</code>
I certainly think the latter is tricker to parse.
<h2>Opinionated flags</h2>
Command line flags provide an opportunity to be more descriptive about the behavior of your application. In fact, they're so descriptive they can also be just a tiny bit opinionated.
Let's say I'm building a command line app to make my morning coffee. A pure configuration approach might look like this:
<code>barista --drink=coffee --milk=true --espresso-shots=2 --sugar=false</code>
Now that's a lot of configuration for a basic use case. Let's try a flag based approach:
<code>barista --create-coffee --milk --double-shot --no-sugar</code>
So I've just substituted everything for flags. However, I've been a bit sly in the way I've gone about it:
<ul>
<li><code>--milk</code> Just a straightforward on/off option</li>
<li><code>--double-shot</code> I've removed the option to set the number of shots. The existence of this flag sort of implies a single shot is the default.</li>
<li><code>--no-sugar</code> By prefixing with <code>no-</code>, I've kind of implied that having sugar is the default.</li>
</ul>
Now you may agree or disagree with the opinions expressed in these flags (sugar in coffee! Are you crazy?). You might even be passionate about your position.
Not convinced? Let's try a crazier example:
<code>barista --create-coffee --no-goats-milk --caffeinated</code>
Even though it's a perfectly valid configuration - I want caffeinated coffee without goats milk - the fact these flags exist sort of tell you something about the way the app was intended to be used.
So with this silly example, I hope you can see there's a subtle power in the flags you offer to your users.
If someone's new to your application (or coffee), this can be a subtle way of signalling something about how your app is meant to be used.
<h2>Closing thoughts</h2>
So those are a few of my thoughts on designing command line applications. Command line applications are, in essence, all about words. So it's important to pick the right ones that convey what you mean, and how you intend your application to be used. You're trying to strike a balance between verbosity, and readability.
There's a huge amount to write on the topic, and I might do something more in-depth later.

Designing a command line interface


The Flyway command line is a bit like magic. Just download it, and it runs across Windows, Mac, and Linux - even without an installer.
In this post I'll explain some of the technical details that make it all work.
<h2>Things I like about the Flyway command line</h2>
In my opinion, the Flyway command line does some pretty cool stuff:
<ul>
<li>It's a self-contained zip archive, so you know where all the files live</li>
<li>No installer or uninstaller</li>
<li>You can run <code>flyway</code> in your terminal, and it just works</li>
</ul>
I think this setup is really versatile. The manual install/uninstall process might seem clunky to some. However, this setup means we can just offload that work to package managers like Homebrew or Chocolatey.
<h2>Java isn't the whole story</h2>
You might know that Flyway is written in Java. Since Java apps can be run cross platform, perhaps it seems obvious that Flyway can just be deployed on any mainstream operating system?
In the grand scheme, it's true. Using Java gives Flyway it's cross platform capability. However, Flyway does some clever things beyond what a normal Java build process might offer.
<h2>What's in the zip?</h2>
Let's have a look at the <a href="https://flywaydb.org/documentation/usage/commandline/#download-and-installation">Flyway command line</a> archive.
There's a bunch of folders, <code>conf</code>, <code>drivers</code>, <code>lib</code>, and so on. Let's ignore those for now. The interesting part is the <code>flyway</code> and <code>flyway.cmd</code> files.
When you run <code>flyway</code> on the command line, it's one of these two files that are actually executed, depending on your operating system. <code>flyway</code> is for Linux and MacOS, whereas <code>flyway.cmd</code> is for Windows.
I'm a Windows guy, so let's open up <code>flyway.cmd</code> in a text editor.
<h2>The batch script</h2>
<code>flyway.cmd</code> is a batch script file that sets up a lot of variables, then calls the Java executable. Skip to the end to find the line that looks like this:
<pre><code class="language-cmd">%JAVA_CMD% -Djava.library.path="%INSTALLDIR%\native" %JAVA_ARGS% 
 -cp "%CLASSPATH%;%INSTALLDIR%\lib\*;%INSTALLDIR%\lib\%FLYWAY_EDITION%\*;%INSTALLDIR%\drivers\*"
 org.flywaydb.commandline.Main %*
</code></pre>
There's a lot going on here, right? Let's break it down.
First, let's figure out what <code>%JAVA_CMD%</code> is. This is a variable, and scrolling up the file you can see how it's defined:
<pre><code class="language-cmd">@REM Set the current directory to the installation directory
call :getCurrentBatch INSTALLDIR1
set INSTALLDIR=%INSTALLDIR1%
set INSTALLDIR=%INSTALLDIR:~0,-10%

if exist "%INSTALLDIR%\jre\bin\java.exe" (
 set JAVA_CMD="%INSTALLDIR%\jre\bin\java.exe"
) else (
 @REM Use JAVA_HOME if it is set
 if "%JAVA_HOME%"=="" (
 set JAVA_CMD=java
 ) else (
 set JAVA_CMD="%JAVA_HOME%\bin\java.exe"
 )
)
</code></pre>
The comments are helpful here. We set <code>%JAVA_CMD%</code> to this location - <code>"%INSTALLDIR%\jre\bin\java.exe"</code>. If that isn't found, then we use <code>JAVA_HOME</code>, which is an environment variable set by Java when you install it.
So what is <code>"%INSTALLDIR%\jre\bin\java.exe"</code>? Look again at the Flyway installation zip. There's a folder called <code>jre</code>, and within that <code>bin</code>. Open that up, and you'll see hundreds of Java specific files.
So, Flyway actually bundles the Java Runtime Environment (JRE), if you don't already have it installed.
Flyway brings it's platform with it, so it doesn't need any other installation. I think this is a really elegant approach.
<h2>Java magic</h2>
So, <code>%JAVA_CMD%</code> gets set to a path that can call a Java executable. The next step is to set up the Java Virtual Machine (JVM) to load in all the Flyway specific dependencies (JARs).
Java looks for dependencies on something called the 'classpath'. My understanding is, the classpath is just a list of folders on your machine where Java will load in JARs. Flyway sets up the classpath with the <code>-cp</code> argument. It sets:
<code>"%INSTALLDIR%\lib\*</code>, <code>%INSTALLDIR%\lib\%FLYWAY_EDITION%\*</code>, and <code>%INSTALLDIR%\drivers\*"</code>
Ah, <code>lib</code>, that's familiar, right? Open it up in the zip archive and you see the following:
<pre><code>community/
enterprise/
gson-*.jar
jansi-*.jar
</code></pre>
So, we add <code>gson</code> and <code>jansi</code> to the classpath. Then we add everything in the <code>community</code> or <code>enterprise</code> folder, depending on which edition of Flyway the user has selected. Open up <code>community</code> or <code>enterprise</code>, and you'll see the JARs for Flyway itself.
Flyway also sets this thing called <code>java.library.path</code> to the <code>native</code> folder. This is a JVM property, used to configure the JVM's behavior. In this case we're telling Java, 'hey, look in this <code>native</code> folder for some stuff'. For Flyway, this is needed to add some DLLs for Windows Authentication in SQL Server connections.
Finally, we tell the JVM where to start executing code, <a href="https://github.com/flyway/flyway/blob/master/flyway-commandline/src/main/java/org/flywaydb/commandline/Main.java"><code>org.flywaydb.commandline.Main</code></a>.
<h2>Put all your toys in the box</h2>
So, now you've seen a bit more about how the Flyway command line manages to work 'out-of-the-box'. I've glossed over some things, but perhaps you aren't desperate to know much more? :)
In summary, Flyway bundles everything it needs to run in a self-contained way.
I personally really like this approach, however there are some pitfalls. You may have noticed that Flyway is bundling some things only a few users will care about. For instance the DLLs to support Windows authentication. Does every user need it? Probably not!
So Flyway runs the risk of being a bit bloated, in order to provide a nice setup experience for all it's users. I think this is an acceptable risk, really. Maybe some people are really concerned about shaving MBs off the size of their artifacts, but I doubt most people notice.

How does the Flyway command line work, anyways?

In 2019, Redgate acquired Flyway, a popular open source tool for database migrations.
A new engineering team was formed to on-board Flyway into the business, and I was asked to join. Our brief was simple - just get to grips with the codebase.
We suddenly had thousands of new users to look after. Our code was open to public scrutiny, and we had to learn how to keep everyone happy.
Fast forward a couple of years, and I'm glad to say we're much more comfortable running an open source project.
In this post I'd like to share some of what I've learned about the open source world since then.
<h2>Open source doesn't mean what you think</h2>
It turns out that 'open source' is a really broad term, though on the surface it seems obvious. Open source just means that the source code is on a public GitHub repo somewhere, right?
Well, it's not so simple. A naive Google search for 'define open source software' yields definitions from various places. Here are some I found:
'The term open source refers to something people can modify and share' (<a href="https://opensource.com/resources/what-open-source">opensource.com</a>)
'Source code is released under a license... grants users the rights to use, study, change, and distribute the software to anyone and for any purpose.' (<a href="https://en.wikipedia.org/wiki/Open-source_software">wikipedia</a>)
'open source software is code that is designed to be publicly accessible—anyone can see, modify, and distribute the code as they see fit.' (<a href="https://www.redhat.com/en/topics/open-source/what-is-open-source">Red Hat</a>)
Ok, so there are some common themes. 'something people can share', 'publicly accessible' a license to 'study' or 'use the software'.
However, in practice, crack open a popular open source project like, say, <a href="https://github.com/itext/itext7-dotnet">iText 7</a>, and see what they say about your liberty to use, modify, and re-distribute their code at will:
<a href="https://github.com/itext/itext7-dotnet#readme"><code>iText7-dotnet Readme.md</code></a>
<pre><code>iText 7 is dual licensed as AGPL/Commercial software.
AGPL is a free / open source software license.
This doesn't mean the software is gratis!

Buying a license is mandatory as soon as you develop commercial
activities distributing the iText software inside your product...
</code></pre>
It's free! It's open source! But don't make the mistake of thinking it's actually free!
<h2>Open source projects vary in the freedoms they offer</h2>
So, iText, one of the biggest 'open source' vendors out there, still want you to pay for commercial usage of their software.
It turns out, if you look through the license conditions for open source projects you'll notice a pattern. Battle lines are generally drawn over the following:
<ul>
<li>Commercial use</li>
<li>Using the project in your own private (closed-source) projects</li>
<li>Your ability to actually build the code from source yourself</li>
</ul>
For instance, <a href="https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch/">Elasticsearch made headlines earlier this year</a> for adjusting the terms of their license. The details are a bit beyond me, but apparently made it very difficult for existing users to operate their businesses.
<a href="https://opensource.com/article/18/2/top-10-open-source-legal-stories-shook-2017">There are many examples of legal battles in the open source community</a>, usually stemming from some worry about who's really going to get rich off a given project.
<h2>Commercial open source is a thing</h2>
Despite it sounding like a paradox, commercial open source projects are quite common. <a href="https://flywaydb.org/try-flyway-teams-edition">Flyway itself is a great</a> example. As much as I'd like to, I don't work on Flyway solely out of good will!
As you've seen, it's possible to profit from open source projects by using a license that requires you to pay for commercial deployments of that software.
There are other methods too. For instance, some projects take an 'Open Core' approach, where only a subset of the code is publicly available. Generally for 'Open Core', you'll have to pay to see all the code, and/or get all the features.
<h2>Utopian visions of a free world</h2>
So it turns out that 'Free &#x26; open source' software isn't as free, or open as you might imagine. That said, there are many projects that live up to the ideal. In my experience they tend to be software libraries designed to 'scratch the itch' of other developers.
However, such grassroots solutions come with their own problems of their maintainers going AWOL (<a href="https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code/">who remembers left-pad?</a>).
Ultimately, writing software is highly skilled and labor intensive. It's not unreasonable to expect some return for your hours spent. I think open source has it's place, but realistically the software world is always going to be a mix of free and commercial offerings.

Free & open source isn't always free & open


Hello, my name's Mikiel. I'm the technical lead for the <a href="https://flywaydb.org/">Flyway Team</a> at Redgate.
I've started this blog in an effort to '<a href="https://twitter.com/swyx/status/1009174159690264579">Learn In Public</a>'. I hope what I write might be useful to you.
At Redgate, every Friday afternoon we're encouraged to take '10% time' - a chance to pursue personal development and learning. I plan to use this blog to chart my learnings throughout 10% time, and beyond.
So I welcome you to join me on this journey! I hope you find something interesting here.
Thanks
Mikiel

Software & TeamsBlog by @MikielAgutu

5 Things I Learned as a New Technical Lead20th December 2021

Impact is the only thing that matters 17th September 2021

Why write a line of code? 16th July 2021

Designing a command line interface 14th May 2021

How does the Flyway command line work, anyways?30th April 2021

Free & open source isn't always free & open 23rd April 2021

Learning In Public23rd April 2021