Content Developer II at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
132221 stories
·
29 followers

PPP 442 | The Coaching Shortcut That Transforms Teams, with Dominic Ashley-Timms

1 Share

Summary

In this episode, Andy discusses the challenges and benefits of being a project manager or team leader with guest Dominic Ashley-Timms, co-author of the book The Answer is a Question: The Missing Superpower that Changes Everything and Will Transform Your Impact as a Manager and Leader. Dominic introduces the STAR model, a framework designed to enhance management effectiveness through operational coaching, and explains the concept of Frankenstein managers. They also delve into the importance of triggers, anchors, and asking better questions to foster growth and problem-solving within teams. The discussion highlights practical applications of the STAR model and its potential to transform leadership impact both professionally and personally.

What if coaching wasn't something you put on the calendar? What if you could recognize coaching moments in the day-to-day activity of work and life? This episode shows you how to do that.

Sound Bites

  • “Most of us are Frankenstein managers.”
  • “Stop, think, ask, and secure a result—that's the STAR model in action.”
  • "The hardest part of coaching? Catching yourself and biting your lip.”
  • “Is this a coachable moment? If not now, then when?”
  • “A simple question can turn a two-hour supplier meeting into a seven-hour collaboration that saves millions.”
  • “People might thank you for advice you never gave—just the right questions you asked.”
  • “Changing your management style isn’t about a lifetime—it starts with two weeks of asking better questions.”
  • “Pre-live moments to break the cycle of overreaction.”

Chapters

  • 00:00 Introduction
  • 02:53 Start Of Interview
  • 03:00 What are Frankenstein Managers?
  • 07:17 Introducing the STAR Model
  • 09:59 Triggers and Anchors: Tools for Behavioral Change
  • 17:04 The Skill of Asking Questions
  • 18:00 Identifying Coachable Moments
  • 21:05 Crafting Effective Questions
  • 24:40 Example Scenarios
  • 26:12 How Parents Can Apply The Learning
  • 28:40 End Of Interview
  • 29:06 Andy's Comments After The Interview
  • 31:54 Outtakes

Learn More

You can learn more about Dominic and Laura and their book at TheAnswerIsAQuestion.com.

For more learning on this topic, check out:

  • Episode 150 with Michael Bungay Stanier about his book The Coaching Habit. It's a perfect compliment to this book!
  • Episode 297 with Glain Roberts-McCabe about her book on coaching communities.

AI for Project Managers and Leaders

With the constant stream of AI news, it's sometimes hard to grasp how these advancements can benefit us as project managers and leaders in our day-to-day work. That's why I developed our e-learning course: AI Made Simple: A Practical Guide to Using AI in Your Everyday Work.

This self-guided course is designed for project managers and leaders aiming to harness AI's potential to enhance your work, streamline your workflow, and boost your productivity.

Go to ai.i-leadonline.com to learn more and join us. The feedback from the program has been fantastic. Take this opportunity to unlock the potential of AI for your team and projects.

Thank you for joining me for this episode of The People and Projects Podcast!

Talent Triangle: Power Skills

Topics: Leadership, Coaching, Management, Parenting, Personal Development, Communication, Team Management

The following music was used for this episode:

Music: The Fantastical Ferret by Tim Kulig
License (CC BY 4.0): https://filmmusic.io/standard-license

Music: Fashion Corporate by Frank Schroeter
License (CC BY 4.0): https://filmmusic.io/standard-license

YouTube clip: “Brian Regan Stand-Up” The Tonight Show Starring Jimmy Fallon
Link: YouTube.com/watch?v=LWm9Em2rwD4





Download audio: https://traffic.libsyn.com/secure/peopleandprojectspodcast/442-DominicAshleyTimms.mp3?dest-id=107017
Read the whole story
alvinashcraft
11 minutes ago
reply
West Grove, PA
Share this story
Delete

Being a SysAdmin in 2025

1 Share

For the first show of 2025, let's talk about being a sysadmin in the coming year. This is the sixth year of Richard going solo on the show to talk about the things he's seen in the past year and speculate a bit on the next year, at least for sysadmins. Economic uncertainty is still a thing, as is employment. The security situation continues to be tough - and getting worse. But remarkable new tools, including large language models, are on the horizon to make things a bit easier. The adoption rates for LLMs aren't as quick as some people would like, but things are happening, and they can provide value. However, you have to do your homework. Oh, and then there's Windows!

Links

Recorded December 31, 2024





Download audio: https://cdn.simplecast.com/audio/c2165e35-09c6-4ae8-b29e-2d26dad5aece/episodes/d15a9ba9-a519-4f49-922a-0163d1f86838/audio/39ddbc25-cf08-4f83-adcc-68fcc3aa5d27/default_tc.mp3?aid=rss_feed&feed=cRTTfxcT
Read the whole story
alvinashcraft
11 minutes ago
reply
West Grove, PA
Share this story
Delete

Host and deploy an ASP.NET Core API to a Hetzner VPS

1 Share
<p>For a side-project I’m currently working on, in addition to some CRUD operations, I needed a way to run Playwright commands. I decided to use <a href="http://ASP.NET">ASP.NET</a> Core for this, as I’m already familiar with it and the setup is very easy. I started with a blank <code>dotnet new webapi</code> project. After development and testing my API locally, I wanted to deploy it somewhere for production use. I decided to try Azure Container Apps initially. However, after the first month and the first bill of ~60€ (with not that much traffic) - I started looking for alternatives. I heard good things about <a href="https://monsterasp.net" target="_blank">monsterasp.net</a> and can recommend them for <a href="http://ASP.NET">ASP.NET</a> projects - with my requirements, especially running a headless browser in a separate process, their offering was not suitable. So I decided to try a VPS and skip the serverless fees and have full control over the server. I chose <a href="https://hetzner.com" target="_blank">hetzner.com</a> as my provider, as they offer a great price-performance ratio and have a data center in Europe. In this post, I’ll show you how to host and deploy an <a href="http://ASP.NET">ASP.NET</a> Core API to a Hetzner VPS. I’m using their cheapest plan which is &lt; 4€ per month.</p> <h2 id="prerequisites">Prerequisites<a title="#prerequisites" href="#prerequisites"></a></h2> <ul> <li>A Hetzner Cloud account</li> <li>A domain name</li> <li>A VPS running Ubuntu &gt;= 20.04</li> </ul> <h2 id="setting-up-the-vps">Setting up the VPS<a title="#setting-up-the-vps" href="#setting-up-the-vps"></a></h2> <p>First, you need to create a new VPS in the Hetzner Cloud Console.</p> <p><img src="/2024/12/Host-and-deploy-ASP-NET-Core-to-a-Hetzner-VPS/hetzner0.jpg" alt="Hetzner Cloud Console" loading="lazy" class="φbp"></p> <p>You can choose the location of the server - I chose Nuremberg, Germany.</p> <p><img src="/2024/12/Host-and-deploy-ASP-NET-Core-to-a-Hetzner-VPS/hetzner1.jpg" alt="Hetzner Cloud Console" loading="lazy" class="φbp"></p> <p>And the image which is pre-installed on the server. I went with Ubuntu 24.04 but .NET should run on other distributions as well.</p> <p><img src="/2024/12/Host-and-deploy-ASP-NET-Core-to-a-Hetzner-VPS/hetzner2.jpg" alt="Hetzner Cloud Console" loading="lazy" class="φbp"></p> <p>You can choose between a shared vCPU which is cheaper but resources are shared with other applications on the host or a dedicated vCPU which is more expensive but you have the whole CPU for yourself. For my tests here I went with a shared x86 vCPU.</p> <p><img src="/2024/12/Host-and-deploy-ASP-NET-Core-to-a-Hetzner-VPS/hetzner3.jpg" alt="Hetzner Cloud Console" loading="lazy" class="φbp"></p> <p>The base price of the VPS inclused a free IPv6 address. If you are not setup for IPv6 yet you can add an IPv4 address for a small fee.</p> <p>My full config was a CX22 plan, which is the cheapest one with 2 vCPU, 4 GB RAM, and 40 GB SSD storage - plus 20 TB of traffic. You can choose any plan you like, but for my simple API, the CX22 should be sufficient. During the creation you can also set a SSH key or password. After the VPS is created, you can connect to it via SSH.</p> <h2 id="installing-docker">Installing Docker<a title="#installing-docker" href="#installing-docker"></a></h2> <p>Previously on the Azure setup, I used containerized apps, so I already had a Dockerfile for my API. Therefore, I decided to use Docker on Hetzner as well. First, you need to install Docker on your VPS. You can follow the official Docker documentation for this. Here are the commands I used:</p> <figure class="highlight bash"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br></pre></td><td class="code"><pre><span class="line"><span class="comment"># Add Docker&#x27;s official GPG key:</span></span><br><span class="line">sudo apt-get update</span><br><span class="line">sudo apt-get install ca-certificates curl</span><br><span class="line">sudo install -m 0755 -d /etc/apt/keyrings</span><br><span class="line">sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc</span><br><span class="line">sudo <span class="built_in">chmod</span> a+r /etc/apt/keyrings/docker.asc</span><br><span class="line"></span><br><span class="line"><span class="comment"># Add the repository to Apt sources:</span></span><br><span class="line"><span class="built_in">echo</span> \</span><br><span class="line"> <span class="string">&quot;deb [arch=<span class="subst">$(dpkg --print-architecture)</span> signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \</span></span><br><span class="line"><span class="string"> <span class="subst">$(. /etc/os-release &amp;&amp; echo <span class="string">&quot;<span class="variable">$VERSION_CODENAME</span>&quot;</span>)</span> stable&quot;</span> | \</span><br><span class="line"> sudo <span class="built_in">tee</span> /etc/apt/sources.list.d/docker.list &gt; /dev/null</span><br><span class="line">sudo apt-get update</span><br></pre></td></tr></table></figure> <p>This works fine for Ubuntu 24.04 at the time of writing. Here is the official docs for Docker installation: <a href="https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository" target="_blank">https://docs.docker.com/engine/install/ubuntu/#install-using-the-repository</a></p> <h2 id="caddy">Caddy<a title="#caddy" href="#caddy"></a></h2> <p>I wanted to use Caddy as a reverse proxy for my API. Caddy is a modern web server that can handle HTTPS, reverse proxy, and more. I like it because it’s very easy to set up and configure. It also handles automatic HTTPS with Let’s Encrypt and the configuration file is very simple and easy to read. You can find the installation instructions on the Caddy website: <a href="https://caddyserver.com/docs/install" target="_blank">https://caddyserver.com/docs/install</a>. There are different ways you can setup Caddy on the VPS - either directly on the host or in a container. I decided to also use Docker for Caddy, it’s easy to set up and manage with a simple compose file.</p> <figure class="highlight yaml"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br></pre></td><td class="code"><pre><span class="line"><span class="attr">services:</span></span><br><span class="line"> <span class="attr">caddy:</span></span><br><span class="line"> <span class="attr">image:</span> <span class="string">caddy:latest</span></span><br><span class="line"> <span class="attr">restart:</span> <span class="string">unless-stopped</span></span><br><span class="line"> <span class="attr">ports:</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">&quot;80:80&quot;</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">&quot;443:443&quot;</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">&quot;443:443/udp&quot;</span></span><br><span class="line"> <span class="attr">volumes:</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">./Caddyfile:/etc/caddy/Caddyfile</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">./site:/srv</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">caddy_data:/data</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">caddy_config:/config</span></span><br><span class="line"></span><br><span class="line"><span class="attr">volumes:</span></span><br><span class="line"> <span class="attr">caddy_data:</span></span><br><span class="line"> <span class="attr">caddy_config:</span></span><br></pre></td></tr></table></figure> <p>from <a href="https://caddyserver.com/docs/running#docker-compose" target="_blank">https://caddyserver.com/docs/running#docker-compose</a></p> <p>this configuration can be tested by creating some html content in a site folder at the level of the Caddyfile. The Caddyfile can be as simple as:</p> <figure class="highlight yaml"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br></pre></td><td class="code"><pre><span class="line"><span class="string">domain.tld</span> &#123;</span><br><span class="line"> <span class="string">root</span> <span class="string">/srv</span></span><br><span class="line"> <span class="string">file_server</span></span><br><span class="line">&#125;</span><br></pre></td></tr></table></figure> <p>This will serve the content of the site folder on the domain.tld. Let’s test this setup by running <code>docker-compose up -d</code> in the same folder as the docker-compose.yml file. After the container is running, you can visit your domain in the browser and see the content of the site folder.</p> <h2 id="deploying-the-api">Deploying the API<a title="#deploying-the-api" href="#deploying-the-api"></a></h2> <p>After installing Docker and Caddy, you can deploy your API. I used a simple Dockerfile for my API, which looks like this:</p> <figure class="highlight dockerfile"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br></pre></td><td class="code"><pre><span class="line">services:</span><br><span class="line"> aspnetcore:</span><br><span class="line"> image: mcr.microsoft.com/dotnet/aspnet:<span class="number">9.0</span></span><br><span class="line"> restart: unless-stopped</span><br><span class="line"> ports:</span><br><span class="line"> - <span class="string">&quot;5000:80&quot;</span></span><br><span class="line"> - <span class="string">&quot;5001:443&quot;</span></span><br><span class="line"> volumes:</span><br><span class="line"> - ./aspnetcore:/app</span><br><span class="line"> working_dir: /app</span><br><span class="line"> command: [<span class="string">&quot;dotnet&quot;</span>, <span class="string">&quot;aspnetcore.dll&quot;</span>]</span><br></pre></td></tr></table></figure> <p>This will build the image from the official <a href="http://ASP.NET">ASP.NET</a> Core image and run it on port 5000. I ran a simple <code>dotnet publish -c Release</code> to generate the required dotnet artifacts. Those will be created in <code>bin/Release/net9.0/publish</code>. I copied the content of this folder to the <code>aspnetcore</code> folder at the level of the docker-compose.yml file.</p> <p>To use Caddy in front of the API, you need to add a reverse proxy to the Caddyfile:</p> <figure class="highlight yaml"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br></pre></td><td class="code"><pre><span class="line"><span class="string">domain.tld</span> &#123;</span><br><span class="line"> <span class="string">root</span> <span class="string">/srv</span></span><br><span class="line"> <span class="string">reverse_proxy</span> <span class="string">/api/*</span> <span class="string">aspnetcore:8080</span></span><br><span class="line"> <span class="string">file_server</span></span><br><span class="line">&#125;</span><br></pre></td></tr></table></figure> <p>This will forward all requests to <code>/api/*</code> to the <a href="http://ASP.NET">ASP.NET</a> Core container. The container name is set in the updated docker-compose.yml file. Which now looks like this:</p> <figure class="highlight yaml"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br><span class="line">3</span><br><span class="line">4</span><br><span class="line">5</span><br><span class="line">6</span><br><span class="line">7</span><br><span class="line">8</span><br><span class="line">9</span><br><span class="line">10</span><br><span class="line">11</span><br><span class="line">12</span><br><span class="line">13</span><br><span class="line">14</span><br><span class="line">15</span><br><span class="line">16</span><br><span class="line">17</span><br><span class="line">18</span><br><span class="line">19</span><br><span class="line">20</span><br><span class="line">21</span><br><span class="line">22</span><br><span class="line">23</span><br><span class="line">24</span><br><span class="line">25</span><br><span class="line">26</span><br><span class="line">27</span><br><span class="line">28</span><br></pre></td><td class="code"><pre><span class="line"><span class="attr">services:</span></span><br><span class="line"> <span class="attr">caddy:</span></span><br><span class="line"> <span class="attr">image:</span> <span class="string">caddy:latest</span></span><br><span class="line"> <span class="attr">restart:</span> <span class="string">unless-stopped</span></span><br><span class="line"> <span class="attr">ports:</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">&quot;8080:8080&quot;</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">&quot;443:443&quot;</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">&quot;443:443/udp&quot;</span></span><br><span class="line"> <span class="attr">volumes:</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">./Caddyfile:/etc/caddy/Caddyfile</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">./aspnetcore:/app</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">caddy_data:/data</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">caddy_config:/config</span></span><br><span class="line"></span><br><span class="line"> <span class="attr">aspnetcore:</span></span><br><span class="line"> <span class="attr">image:</span> <span class="string">mcr.microsoft.com/dotnet/aspnet:9.0</span></span><br><span class="line"> <span class="attr">restart:</span> <span class="string">unless-stopped</span></span><br><span class="line"> <span class="attr">ports:</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">&quot;5000:80&quot;</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">&quot;5001:443&quot;</span></span><br><span class="line"> <span class="attr">volumes:</span></span><br><span class="line"> <span class="bullet">-</span> <span class="string">./aspnetcore:/app</span></span><br><span class="line"> <span class="attr">working_dir:</span> <span class="string">/app</span></span><br><span class="line"> <span class="attr">command:</span> [<span class="string">&quot;dotnet&quot;</span>, <span class="string">&quot;aspnetcore.dll&quot;</span>]</span><br><span class="line"></span><br><span class="line"><span class="attr">volumes:</span></span><br><span class="line"> <span class="attr">caddy_data:</span></span><br><span class="line"> <span class="attr">caddy_config:</span></span><br></pre></td></tr></table></figure> <p>After updating the docker-compose.yml file, you can run <code>docker-compose up -d</code> again to start the containers. Now you should be able to call your API on your domain. If you have any issues, you can check the logs of the containers with <code>docker-compose logs</code>.</p> <h2 id="conclusion">Conclusion<a title="#conclusion" href="#conclusion"></a></h2> <p>That’s it for now. Just a quick guide on how to host and deploy an <a href="http://ASP.NET">ASP.NET</a> Core API to a Hetzner VPS. I hope this helps you to get started. I will probably follow up with more details about monitoring and resiliency in the future. If you have any questions or feedback, feel free to reach out!</p>
Read the whole story
alvinashcraft
12 minutes ago
reply
West Grove, PA
Share this story
Delete

CfP List Updated 2024-12-31

1 Share
LAST UPDATED: 2024-12-31

This is a list of CfPs (Calls for Papers/Presentations/Participation/etc.) that I know of, closing within the next two weeks.  It is updated approximately every week (usually on Tuesday afternoon), so nothing should fall through the cracks.  There are usually about ten to twenty, but highly variable.  It is an extract of a much larger list that I maintain on behalf of Toptal’s Speakers Network.  That one contains past CfPs, CfPs closing much farther in the future, and estimates when past ones should reopen.  (If you want access to that, use my referral link, click on the “Apply as a Freelancer” button, pass the screening, then apply to join the Speakers Network, which may require going through their Speakers Academy first.)

This list contains only the CfPs of conferences I am personally interested in, ones that other Speakers Network members inform me of, and a few others I happen to stumble across.  So, that’s mainly software development conferences, focused on Elixir (or Phoenix), Ruby (or Rails), Python, JavaScript, C, or sometimes closely related things (like the BEAM or C++), or not tightly focused on any particular tech stack (though it may lean heavily towards one or two), or occasionally testing (of the kind devs should do to their own code, not the kind a QA tester does).  It usually omits CfPs from conferences held in places I won’t go, lasting less than a full work-day, or about any other tech stack or topic, or tightly focused on various specific subtopics, or that doesn’t have a website of its own (at least about the series).

If you know of something missing, feel free to contact me.  Just please make sure that the CfP is indeed closing within the next two weeks from the latest update, else I might already have it in the big list, just not this extract.

You can always get the latest version of this list here.


Event Name Event
Website
Location CFP Close
Date
Event
Date
CFP
Link
JNation link Coimbra, Portugal 12-31 05-27 link
JSHeroes link Cluj-Napoca, Romania 12-31 05-29 link
Social Developers Club link Hamburg, Germany 12-31 03-15 link
The Design Conference link Brisbane, Australia 12-31 06-18 link
200 OK link Tulsa, OK, USA 01-01 05-23 link
Baltic Ruby link Riga, Latvia 01-01 06-12 link
Blipz on the Radar link Utrecht, Netherlands 01-04 03-11 link
RVAjs link Richmond, VA, USA 01-04 03-14 link
NDC Oslo link Oslo, Norway 01-06 05-21 link
PyCon Italy link Bologna, Italy 01-06 05-28 link
CityJSConf LONDON link London, UK 01-10 04-25 (est) link
DDD (Developer Developer Developer!) North link Kingston upon Hull, UK 01-10 02-22 link
Devoxx UK link London, UK 01-10 05-07 link
Tropical on Rails link São Paulo, Brazil 01-10 04-03 link
Devoxx France link Paris, France 01-12 04-16 link
DWX (Developer-Week) link Mannheim, Germany 01-12 07-01 link
Ruby Kaigi link Matsuyama, Japan 01-12 04-16 link
LDX3 (formerly LeadDev LONDON) link London, UK 01-13 06-16 link
Read the whole story
alvinashcraft
12 minutes ago
reply
West Grove, PA
Share this story
Delete

What 2024’s Data Told Us About How Developers Work Now

1 Share
year wrapup illustratiojn

2024 saw The New Stack report on a variety of survey-based research about software development. Here are the takeaways we think are most relevant to you as you plan for 2025.

Platform Engineering and Developer Platforms

  • Platform engineers are focused on infrastructure provisioning, which can be problematic because of the diversity of platforms being managed.
  • Even though self-service increases productivity for developer teams, too many platform teams are failing to collect and demonstrate metrics of success.

Open Source

  • Paid maintainers keep code safer.
  • Maintainers worry about contributions from AI and unknown developers.

AI and Developers

  • Time savings and increased productivity, not code quality, are why developers are using AI.
  • Led by younger, inexperienced developers, AI tools have rapidly been adopted for use within the development process.
  • GitHub Copilot did not experience mass adoption.

Hiring and Careers

  • Personal job security is stronger than would be expected based on developers’ generalized anxiety.
  • Developer salaries and wages have been constrained.

Programming Languages

Other Noteworthy Findings

  • Not all companies are leaving the cloud.
  • Customer-facing incidents are on the rise.

Platform Engineering and Developer Platforms

While not a portmanteau like DevOps, platform engineering has emerged as the discipline in which the goals of development and operations converge.

Throughout 2024 we reported on more than four survey-based reports that provided insights into platform engineering and internal developer platforms (IDPs). They demonstrated that the vast majority of enterprises have adopted platform engineering, even though they may not have a formal team with that name.

Standardizing infrastructure provisioning and consumption of IDPs is a main focus of 68% platform teams. Improving developers’ experience and productivity with IDPs follows closely as focal points, per the latest version of the “State of Platform Engineering Report.” by Gitpod and Humanitec.

Read the whole story
alvinashcraft
5 hours ago
reply
West Grove, PA
Share this story
Delete

Open Source in 2025: Strap In, Disruption Straight Ahead

1 Share
An open box with a star atop it is encircledd with various lines coming out from it to symbols representing growth and trends to watch.

The open source software world can feel like a bubble at times, one in which people who love to solve problems go and tinker with solutions, share ideas freely and build global communities of contributors. They gather at conferences, meetups and online to praise each other’s hard work and innovation, and remind each other how awesome they are.

But outside forces can sometimes shake that bubble like a snow globe. In March, Redis adjusted the licensing for its open source in-memory data store, which prompted the creation of a Linux Foundation-supported fork, Valkey.

In December, the community around Puppet, an Infrastructure as Code tool, announced plans to fork it in the wake of November news that Perforce, its owner, would “ship any new binaries and packages developed by [its] team to a private, hardened and controlled location. Community contributors will have free access to this private repo under the terms of an end-user license agreement (EULA) for development use.”

In other words, Puppet will now be source-available, not open source.

The trend of widely used open source software moving to more restrictive licensing isn’t new. But the current wave started, arguably, with HashiCorp’s August 2023 decision to pull Terraform (and subsequently other products, like Nomad) back from the open source world, assigning them to Business Source License v1.1. A community is growing around the fork of Terraform, OpenTofu. Likewise for OpenBao, a fork of HashiCorp’s Vault secrets manager created at the end of 2023.

Users are truly experiencing some “turbulation” — a word Matt Butcher, CEO and co-founder of Fermyon Technologies, coined about the open source licensing dramas of 2023 and 2024 — a mashup of “turbulence” and “tribulation.” His company was hit by turbulation caused by HashiCorp’s decision, since Fermyon uses HashiCorp’s Nomad. Butcher told The New Stack (TNS): “We literally ended up asking them for exceptions to bits and pieces, because we were running a patched version of Nomad.”

But as a startup founder, he is watching the licensing decisions carefully. Fermyon, which focuses on WebAssembly, has both open source projects and paid enterprise-level products.

“I’m kind of hoping that that particular approach to things remains still highly tenable, and I think it will,” he told TNS at KubeCon + CloudNativeCon North America, in November. “If we can plan that way from the get-go, we don’t have to yank things back, which is what tends to build up the bad faith in the community, or the assumption of bad faith.”

In addition to the demands of late-stage capitalism and impatient investors in companies built on open source tools, other outside factors are pressuring the open source world. There’s the promise/threat of generative AI, for instance. Or the shifting geopolitical landscape, which brings new security concerns and governance regulations.

And there’s the perennial issue of how to compensate the global army of unpaid, volunteer maintainers that so many projects rely on.

What’s ahead for open source in 2025? Here are some ideas, gleaned from interviews at this past autumn’s tech conferences and also from a New Stack survey of more than 120 industry experts, conducted in November, that asked about the future of open source, developers’ use of AI, and IT infrastructure.

More Consolidation, More Licensing Changes

Expect more “turbulation” in the coming year, as the sprawling cloud native ecosystem consolidates. IBM’s $6.4 billion purchase of HashiCorp, announced in April and now expected to close in Q1 of 2025, may herald a trend.

Matt Moore, CTO of Chainguard, said in a response to the TNS survey that he hopes the IBM-HashiCorp deal might bear fruit for the open source community. “I kind of hope that with IBM’s acquisition of Hashi that they might mend fences between Terraform and OpenTofu. There’s already a precedent here, with Elastic’s reversal of a similar decision.”

Elastic moved Elasticsearch and Kibana to open source licensing in August by adding a GNU Affero General Public License to them. The move came three years after the company’s decision to move both projects away from Apache 2.0 licenses. Elastic’s search and analytics engine, Elastic, has been seeing competition from OpenSearch, a fork sponsored by Amazon Web Services.

What’s tricky about guessing the future of licensing is that the pressures on open source software sponsors don’t simply push in one direction; competition could make a company either embrace more restrictive licensing for an open source tool, or create an open source version to speed adoption.

“Predicting what open source projects are moving to a more restrictive model is highly speculative,” said Scott Wheeler, cloud practice lead at Asperitas, in response to The New Stack survey of industry experts.

Still, Wheeler pointed to Elasticsearch and Kibana as examples that might feel new licensing pressures down the road. And, based on the HashiCorp example, he thinks the following projects might experience similar pressures in the future:

All but Ansible, which is covered by a GNU General Public License v3, are under Apache 2.0 licenses currently. (And all but Ansible are housed at nonprofit foundations, presumably sheltered from commercial concerns.)

By contrast, Jason Perlow, president of Argonaut Media and former editorial director at The Linux Foundation, told TNS that “the reverse of this is going to transpire.”

“I feel it is likely that Chrome and possibly Android are likely to become independently governed open source projects, rather than sold off by Google per antitrust regulation,” Perlow said in response to a TNS survey question about the future of open source. (In August, a US District Court for the District of Columbia found the company had maintained an illegal monopoly in online search.)

David DeSanto, chief product officer at GitLab, expects to see more formerly open source projects move to more restrictive licensing in 2025. But he’s taking a glass-half-full view of the trend.

“I expect that’ll be open to a whole new breed of what open source can mean,” he told The New Stack at KubeCon in November. He pointed to HashiCorp’s moves as an example.

“They’ve been moving Vault off of a very permissive open source license, but that’s led to OpenBao. And at GitLab we’re building our own native secrets manager. That’s going to generate the next round of future open source.”

The Open Source AI Debate: Just Getting Started

In October, the Open Source Initiative released version 1.0 of its definition of open source AI. Stefano Maffulli, OSI’s executive director, told The New Stack ahead of its release that 1.0 is a “humble” document, a work in progress.

In the wake of the definition’s release, critics picked it apart, complaining that it gives some vendors cover if they don’t want to reveal their training data, that the definition fundamentally changes the meaning of open source, and that, given how different AI is from software code, maybe OSI shouldn’t have attempted to define open source AI at all.

“There’s an interesting debate around what constitutes ‘open source’ in AI,” said Yang Li, COO at Cosine, in response to The New Stack’s survey.

Meta and Google just got called out for claiming they’re open source when they’re not. The real question is: as we generate more synthetic data, where do you draw the line? You can be open about your data sources but keep your synthetic data generation process proprietary. It’s a blurry line between revealing your data set and revealing how you created it.”

Clearly this debate is just getting started. Moves by the big players will likely be part of 2025’s conversation. In a company blog post on Dec. 26, OpenAI stated its intention to transform from a for-profit and nonprofit structure to a public benefit corporation — like rivals Anthropic and xAI — that supports a nonprofit.

The big takeaway: AI and its major players are certainly poised to suck a lot of the oxygen out of the open source bubble in 2025.

“The biggest threat will likely be the sustainability and maintainability of existing open source projects,” replied Christian Posta, global field CTO at Solo.io, in response to a survey question about the future of open source.

“As AI continues to dominate technological advancements, there has been a noticeable shift in focus toward AI-related initiatives. This often leaves mature projects, such as CNCF-graduated projects, with fewer maintainers, jeopardizing their ability to remain healthy and sustainable in the long term.”

And it will become harder in 2025 for entities that aren’t Google, Meta, Microsoft and its ilk to compete in open source AI.

“For AI applications, computation and data is central, but only the giants like Google or Meta can obtain the data easily,” said James Luan, vice president of engineering at Zilliz, in response to the TNS survey.

“Smaller groups of developers or even individual developers do not have this luxury, and therefore will find it continuously challenging to find open source models.”

In fact, some are concerned that deep learning models could eventually overtake open source development. There’s pushback on that idea. But the threat looms nevertheless.

“GenAI tools, often proprietary, offer developers advanced automation, code generation and observability capabilities that could outpace open source alternatives in convenience and performance,” warned Eran Kinsbruner, head of product marketing at Lightrun, in his response to the TNS survey.

“At the same time, complex architectures demand highly integrated, scalable solutions, which proprietary platforms are better positioned to deliver. This shift risks sidelining open source projects, especially those unable to keep up with AI-driven innovations or the demands of distributed systems, leading to reduced adoption and investment in open-source ecosystems.”

Security and Compliance Concerns Will Rise

The world, you may have noticed, is not particularly peaceful at the moment. And cyberattackers love to create opportunities out of crises.

“Aside from AI, the other big, huge debate [is] going to be security and compliance,” OSI’s Maffulli told The New Stack. “It’s already there. But in 2025 it is going to be even more, given the geopolitical landscape getting more and more complicated and convoluted. It’s going to be big.”

AI has the potential to supercharge threats, noted Idan Plotnik, co-founder and CEO of Apiiro, in response to the TNS survey.

“In 2025, open source software threats will shift from traditional vulnerabilities to AI-generated backdoors and malware embedded in open source packages,” said Plotnik. “With attackers leveraging AI tools to develop and disguise malware within open source code, addressing these new threats will require a significant advancement in security tools to stay ahead of these quickly evolving challenges.

A bit of good news, however: In 2025, AI automation tools might help find and remediate more unmaintained open source code and technical debt, helping to close some of the potential on-ramps for hackers.

“I believe with the proliferation of AI coding tools we should definitely see some decrease in unmaintained open source components primarily because it would be easier and faster to write code for developers even with limited experience in some highly niched areas,” said Madhukar Kumar, chief marketing officer at SingleStore, in response to the TNS survey.

Paying Maintainers: More Cash, Creativity Needed

Nearly every stack uses open source code but still — still! — most open source maintainers essentially get paid in GitHub stars and kissy-face emojis.

Sixty percent of open source maintainers surveyed by Tidelift, in a study published in September, said they aren’t paid for their work. (Perhaps not coincidentally, about the same percentage said they had quit or had considered quitting their project.)

This situation — the continued dependence on an army of unpaid, underappreciated hobbyists to maintain essential codebases — is going to be the biggest threat to open source in 2025, including the security of its tools and platforms, say industry experts.

“Open source is sprawling and often thanklessly maintained by folks in their nights and weekends,” said Moore of Chainguard, in response to the TNS survey. “As the complexity and breadth of open source ecosystems expand, the rate of necessary updates accelerates exponentially.”

“As more organizations integrate open source solutions, the potential for unpatched vulnerabilities and outdated configurations increases, exposing businesses to significant security and performance challenges.”

Jeff Hollen, director of product for Snowpark, the ecosystem and developer platform at Snowflake, replied to the TNS survey with a comment on the importance of paying the people who build and maintain open source projects.

“Open source depends on sponsors and supporters,” Hollen wrote. “Many maintainers and contributors (myself included) participate in open source in addition to their day-to-day job responsibilities. The biggest threat to open source would be if significant enterprise sponsors stop encouraging, promoting and supporting those efforts to help contributors and maintainers get some value from them.”

In addition to the contributions of sponsors like Tidelift and by large corporations to put productive maintainers on their payrolls, expect some creative attempts to compensate open source developers to emerge in 2025.

One to watch in the coming year is tea, a decentralized technology protocol co-founded by Homebrew creator Max Howell. Howell has launched Chai, which measures open source vitality through package manager data.

Participants who have signed up for a “testnet” of the project are earning tokens; at some point in 2025, when the “mainnet” stage of the project launches, those tokens will be launched on a number of cryptocurrency exchanges, with the intent of having monetary value.

About 16,000 projects signed up for Chai’s testnet, Howell told The New Stack. It’s a mere sliver of the 10.5 million open source projects worldwide, but it’s a clear indication that there’s raging demand for innovative thinking when it comes to compensating open source’s makers.

Lawrence E. Hecht contributed to this post.

The post Open Source in 2025: Strap In, Disruption Straight Ahead appeared first on The New Stack.

Read the whole story
alvinashcraft
5 hours ago
reply
West Grove, PA
Share this story
Delete
Next Page of Stories