30 Years of PHP: Guarding the Core Infrastructure

Show notes

In this episode, host Michael Dowden sits down with Sebastian Bergmann, the creator of PHPUnit, to discuss the evolving landscape of open-source software development. Bergmann shares details on upcoming features in PHPUnit 13.3 designed to tackle flaky tests. The conversation delves deeply into modern supply chain security, highlighting recent changes in Composer's dependency handling and the necessity of automated dependency hygiene. Bergmann also addresses the dual-edged sword of AI in engineering—explaining how AI tools are driving an onslaught of security reports while warning against the dangers of developer "de-skilling." Finally, they examine the long-term financial sustainability of open-source projects and call on businesses to support the shared digital infrastructure they rely on.

Show transcript

00:00:10: Hello, I'm your host Michael Doudin and here with me today is a Sebastian Bergman creator of PHP unit.

00:00:16: Sebastian thank you for joining Me.

00:00:18: Thank You For Having Me

00:00:20: Absolutely so.

00:00:21: PHP has been around now for a little over thirty years And PHP Unit Has Been Around For Most Of That.

00:00:29: So You Have A lot Of Experience In This Industry And This Ecosystem.

00:00:33: But What Is Been Holding Your Attention Recently?

00:00:37: What am I currently working on?

00:00:39: Or what have started recently to work on is basically, i'm currently tackling issues in PHP unit.

00:00:50: Working on features that Have been at the back of my mind for quite some time.

00:00:57: A little bit of background On how new features get into PHP Unit.

00:01:04: New Features get into PHP unit, not because somebody most definitely not me just wakes up one morning and thinks oh I have this idea for some feature that might be useful.

00:01:18: Let's just build that right?

00:01:20: That is not how it works.

00:01:22: um It works by listening to users that use PHP Unit in their daily work.

00:01:34: Either they talk to me directly at the meet-up, a conference or they send an email.

00:01:43: Or their open ticket and I'm working with them as consultant or coach.

00:01:49: when you use it too like PHP unit there is sometimes friction right where your user don't know.

00:01:57: am i using this wrong?

00:01:58: could be better.

00:02:00: most users do not there open a ticket for an Open Source project.

00:02:09: And I think that's sad because, for me the most valuable contribution to an OpenSource Project is feedback.

00:02:18: if nobody tells me something cumbersome or tedious and not optimal-to use?

00:02:26: I don't know!

00:02:27: Because i can only personally notice the friction that I experienced myself.

00:02:38: And, in a privileged position then that I notice the friction and have really short turnaround time of getting

00:02:46: rid off that friction

00:02:48: by implementing an improvement- Right!

00:02:50: That could be a bug fix or it would be new feature which can improve developer experience.

00:02:56: So what i've been hearing for quite some time is both from individual developers and teams of developers that they run into situations of flaky tests.

00:03:13: And the flaky test is a test that sometimes fails, most of the time works.

00:03:23: The next version of PHP unit will ship two features I've worked on for quite some time now to deal with Blakey tests going at the problem from two different angles.

00:03:38: The two features in question are repeated test execution and execution of tests with a retry, And what do I mean by they go at the problems from different angles?

00:03:54: Let me start this repeat Repeat allows you to tell PHP unit for all my tests every test ten times, for example.

00:04:09: And stop when one of the repetitions fails.

00:04:15: So that way you can stress-test your test suite and see and provoke flaky tests.

00:04:29: the chance of a flaky test failing when you're running it ten times immediately one after another is a lot higher than repeatedly running your tests where each

00:04:42: test

00:04:42: runs just once.

00:04:46: So this helps identify in a reliable way which tests are flaky?

00:04:53: or if you're lucky to prove that you do not have any flaky tests, yeah?

00:04:59: You also have to look at the positive

00:05:00: case.

00:05:01: So what do you do when you identify a flaky test while we are having a couple of choices?

00:05:08: You can improve the test and improved code so that the flakiness goes away.

00:05:15: in some situations it is possible.

00:05:18: for others For the cases where it's not possible to get rid of the flakiness, maybe you're testing integration with an external service that sometimes works and sometimes doesn't.

00:05:36: You can retry in individual tests for example like let say using repeat your identified as a test is flaky.

00:05:46: now you can add an attribute on this one test saying retry ten times.

00:05:55: Retry works similar to repeat, but it runs the test once and if it works or passes its done no longer repeats But you allow how many time it can fail.

00:06:14: So for instance say retry a test ten times, and out of those ten times it's allowed to fail three times.

00:06:26: So that is one solution for dealing with flaky tests.

00:06:33: Of course you're not limited just putting the attribute onto a single test method or a single-test class but please retry all my tests when they fail and retry them up to ten times, but each is only allowed to fail three out of ten times.

00:06:55: Whatever fits the situation off your particular

00:06:59: project.".

00:07:00: Nice!

00:07:02: And this has been quite some work... I'm very happy that i am finally able to ship it at the beginning of August with PHP unit thirteen dot-three And I'm not only happy because I am shipping these two features that finally tackle the flaky test problem, but also because in part this brings back a feature used to be in PHP unit already.

00:07:35: So for quite some time there was a repeat CLI option told PHP to run tests repeatedly But that did not work in some edge cases properly, and it didn't work how people actually expected to even team developers or teams who have been using it for quite a while.

00:08:01: They didn't know what they were doing at the end of the day!

00:08:05: That caused more problems... So between PHP unit nine and PHP unit ten a couple of years ago, I decided to remove the functionality hoping that A lot sooner than it actually happened now to replace.

00:08:21: It was something that works.

00:08:23: And um i'm sorry that it took almost five years To bring this feature back.

00:08:29: But the good news is that it now actually works, the way its supposed to work.

00:08:34: The way was always supposed to be worked but didn't and it's now flanked by additional feature of retry give a complete solution for flaky test problem.

00:08:50: Sure That sounds like huge win for you and users.

00:08:58: certainly sounds like a challenging feature to build.

00:09:02: When you talk's little bit about really wanting and getting that user feedback too when your managing the project, I feel any products or any open source projects.

00:09:14: thats kind of big thing we want see.

00:09:17: in know that working on product even if your dog fooding it right?

00:09:22: Even using yourself you're probably the most familiar person in the world with how it works.

00:09:28: So, some cases is the worst person to find the friction points right?

00:09:34: I know i run into that with some of the products im working on.

00:09:39: so... That's definitely

00:09:41: true.

00:09:41: and its more true also in another aspect more or less jokingly, actually less jokingally sometimes say I am the worst person to write the documentation for PHP

00:10:00: unit.

00:10:04: Because i keep forgetting things like just implemented a new feature like repeat or retry and then want to document it because as long as its not documented that features doesnt really exist.

00:10:20: So I write the documentation and it happens so often that i forget something in the documentation.

00:10:30: And then weeks or months, sometimes even years later someone opens a ticket for the documentation.

00:10:36: hey this is incomplete!

00:10:38: Um...I spend couple of hours trying to figure out if there's one sentence or paragraph missing Two steps and then it becomes clear.

00:10:52: And I have yet to find a way, um... To solve that problem?

00:10:57: It's an open source project!

00:10:59: I cannot afford uh..to contract the technical writer to do this.

00:11:06: Um ideally I would tell someone there is a new feature.

00:11:10: They look at the future, they write documentation and interview me ask me questions And i answer their question.

00:11:17: that will probably assure That the documentation Is complete earlier.

00:11:22: yeah

00:11:23: but for The time being um we have unfortunately to lift it with the fact that i Forget things when i write documentation.

00:11:33: oh?

00:11:33: Yeah absolutely understand that happens.

00:11:36: It's so hard to write about the thing you already know really

00:11:39: well.".

00:11:40: Yeah, but basically two of the easiest ways and two of most important way is contribute an open source project give feedback either in person or via email by opening a ticket or contributing documentation.

00:12:00: for me it more valuable than in a lot of cases, a pull request.

00:12:05: Sure sure that makes a lot sense.

00:12:08: so I've been following some your recent conference presentations and the things you have planned.

00:12:14: it looks like we're talking about security lately.

00:12:19: And i know you had an upcoming talk on supply chain security.

00:12:23: what can tell us where are thinking is right now?

00:12:29: I would never have imagined that.

00:12:32: I would ever need to become a security expert and definitely don't consider myself as security experts, um i'm learning more there especially when it comes to supply chain security which basically means we all needs to focus more to the code that is part of our applications and solutions, That we did not write ourselves.

00:13:05: Sure

00:13:06: Yeah We are talking about PHP ecosystem and PHP applications And in ours Ecosystem V install dependencies Code that we didn't know right but reuse from either open source components or closed source commercial libraries that you can also manage and install using Composer.

00:13:29: We do that use in Composer, so we need to be aware That not only every line of code that V write ourselves is a liability And not an asset.

00:13:44: yeah big every line Of code that I don't have with the lineup called it cannot Have security issue or any other type of bug.

00:13:53: Every library framework, whatever I install through Composer is a potential door through which security vulnerabilities can come.

00:14:07: And please don't misunderstand that as Sebastian says do not depend on other libraries and frameworks and roll everything yourself changing and it's changing for the better, but these changes also cause friction again.

00:14:36: With a modern version with the current version of Composer you can no longer install a version over dependency that has unknown security vulnerability at least not by default.

00:14:53: Yeah, if you really want to install something that has a known security vulnerability.

00:15:01: You can opt out of the check and installed it but why would you?

00:15:08: So this is something teams need be aware off And its also where I learned alot about how the machinery for how composer knows and enforces these rules recently because a couple of weeks ago, I think by now it's one or two months ago.

00:15:51: So, I released two new versions of PHP unit.

00:15:58: One PHP unit twelfth version and one PHP unit thirteenth version with a fix for that bug because those two versions currently receive bug fixes.

00:16:10: then less than twenty four hours later i get the security vulnerability reported to me.

00:16:17: That affects Those Two Versions I had Released The Day Before.

00:16:25: Remember, I said a couple of minutes ago that I do not consider myself as security

00:16:29: expert.

00:16:30: And I made a mistake by fixing the bug.

00:16:37: so I fixed it but introduced a security vulnerability along-the way and shipped those two releases and did the right thing?

00:16:54: Since PHP unit is developed on GitHub, I can use a service from GitHub to write and publish such as security advisory.

00:17:05: And one of the many things that it's asked in the form is please specify exactly the versions that are affected right?

00:17:17: So using the right syntax equals eleven dot x.y and equal twelve dot x, dot y And save that!

00:17:31: The next step in that before security advisory is published somebody at github reviews it then pushes a button to publish this.

00:17:41: I think that's good because this needs to be reviewed.

00:17:46: That's fair.

00:17:48: Unfortunately, in this case the person who reviewed security advisory I drafted thought these version constraints.

00:17:59: they look odd.

00:18:03: Let's replace equals eleven point y dot z and equals twelve Y dot Z with less than or equal

00:18:13: no.

00:18:16: And then they published it without asking me whether or not that change would be correct.

00:18:23: Then nobody could install any version of PHP unit through Composer anymore and I was notified about this on a Saturday morning via a phone call.

00:18:50: I did not know how to fix that other than open a ticket with GitHub saying, hey my security advisory was changed before it was published.

00:19:03: Now the PHP unit added the PHP ecosystem cannot install PHP Unit anymore.

00:19:10: please fix.

00:19:13: in The end It took about three days for github To fix that but In the meantime i already figured out with the help of Niels and Jordy from The Composer & Packages Project on that Saturday, how to work around the issue by publishing an override in another database.

00:19:38: That is also consumed by composer to figure out which versions are vulnerable.

00:19:46: but that meant because my Saturday.

00:19:51: Well, it was not ruined.

00:19:53: But I needed to deal with that over the weekend and also had... To ruin somebody else's Saturday but we managed to fix or address within an hour so then we could enjoy our weekends.

00:20:09: This shows because there are more attacks on supply chain of ecosystem like PHP.

00:20:21: The tools to install dependencies needs to evolve.

00:20:26: They need to be strict,

00:20:28: more

00:20:28: strict than they used to be up until and including Composer two dot nine Composer one about.

00:20:41: hey you just installed something that has a security issue this change with composer two dots ten by default, it no longer installs such a version.

00:20:54: And this is something that you need to be aware about?

00:20:56: Yeah

00:20:57: I mean in my opinion you should have always been aware of your dependencies more than most teams were.

00:21:08: but now we are forced to think because the tool now enforces these rules and does not give us the dependencies we need to develop, deploy our software.

00:21:26: And if you have a CI CD pipeline where you automatically run installation of your dependencies and tests or whatever... Your pipeline now grinds into a halt?

00:21:43: when there's a security vulnerability, which I think is good because it clearly shows that this is not something you can deploy but also means being able to deal with such situation.

00:21:58: Sure A few weeks ago i was talking about the NodeJS team and they mentioned production packages that are becoming security vulnerabilities, it's things you run in your dev environments because they're still inside of the CIACD pipeline.

00:22:15: They're still providing vulnerabilities to environment so you see them same thing okay?

00:22:23: For me PHP unit is a development tool and I now have very well defined security policy what i consider as security issue.

00:22:35: Basically, I'm now saying there are no security issues in PHP unit.

00:22:40: The security issues our regular bugs.

00:22:44: the argument against that stance that i get is yeah but um...I run PHP units to run tests and when running those tests um exploit something in php unit then it's your fault.

00:23:02: and i would like to say too that well if you have.

00:23:07: Is the icd pipeline?

00:23:10: And someone that you do not trust can send you a pull request, That, by definition is a remote code execution and whether or not PHP unit has a part in that is irrelevant.

00:23:30: Yeah

00:23:32: yeah that makes sense!

00:23:34: So as you work through some of these supply chain issues what... What does good security hygiene look like for typical PHP project?

00:23:46: Like what are things that you recommend folks do?

00:23:48: There's couple.

00:23:51: So for example, it's really hard by default and out of the box to write workflows.

00:24:02: For something like GitHub actions that are secure.

00:24:06: but finally as over a couple months ago there is now static analysis tools That analyzes your github actions workflow specifications and tells you hey You have a mistake here.

00:24:19: And we honest the GitHub workflow action pipeline for PHP unit.

00:24:26: Had close to twenty issues that I just was not aware of like and it was possible to steal Git credentials, what's possible to do this?

00:24:35: What's possible To Do That they are now secure And It is really easy to fix these issues once you're are aware of them and have then pointed out to you by this tool.

00:24:49: This is called sysmore, it's easy to find if you go search for that... That is one part of it!

00:24:59: Now when it comes to dependencies update your dependencies.

00:25:03: often It sounds trivial and simple and obvious but a lot of teams still do not do that.

00:25:11: They do not do that because they think it's a process.

00:25:14: It has to be tedious and manual, but there are services like Renovate or Dependabot or Packages Conductor who can do this automatically for you.

00:25:31: These bots send you pull requests within minutes when the new version of one of your dependencies is released and you can decide whether or not this should be automatically merged when your pipeline works.

00:25:48: And then it depends on how much do you trust your test suite?

00:25:52: Is the test suite exhaustive enough to... When a dependency is updated, nothing fails!

00:26:00: You can put that into production.

00:26:03: Whether or not you want to automatically Merge something like that without looking at the change log for the new version and things.

00:26:13: Like, but that can all be configured especially with regards to where I want to automatically merge new versions bugfix and security fix releases.

00:26:27: Do I want to do that for versions with new features?

00:26:30: You definitely don't want to this one.

00:26:32: you major version set may break backwards compatibility, but use something like that at least To learn about a new version of one off your dependencies as soon as possible.

00:26:45: right And i think thats the most important thing here.

00:26:49: when it comes to dependency hygiene

00:26:54: Awareness is always the first step, I think.

00:26:56: Yes!

00:26:58: It's so easy to be in a situation where you just have no idea what the bugs are with security vulnerabilities on your software?

00:27:07: What is their relationship between not only the test suite but maybe speed of execution and security?

00:27:19: Yeah that topic... the concept of awareness again.

00:27:25: There's a growing awareness that we, in a lot of situations can no longer afford running our tests is really slow.

00:27:39: Of course nobody likes a slow test suite and there are certainly some types of tests That have to be slow And they cannot be made faster, but you probably do not want to have a lot of those tests.

00:27:56: But any speed improvement in your test suite helps and it helps everyone involved.

00:28:03: It helps the humans working on their project because they get fast feedback loop... ...but also help an AI-based agent that also works on the project because that agents profit when the test suite is fast.

00:28:24: They can work better than it's fast and although they are machines, not humans... ...they sometimes get bored or lose their focus!

00:28:37: I run tests then two minutes later as tests still running.

00:28:43: So far, nothing has failed.

00:28:45: I'll kill the test execution and move on to the next thing because obviously this is not... And you need to be very careful with setting up guardrails for your project that you do not run into a situation like that.

00:28:59: but also most important reason due to fact we have now AI models like Mythos from Anthropic and similar security focused Models.

00:29:15: we are seeing an onslaught of Security vulnerabilities that I reported not only for Of course, i'm talking about the PHP ecosystem here But it's same is true.

00:29:30: For all ecosystems out there And for all open source projects

00:29:34: sure

00:29:35: But I have a little bit more insight into PHP and the ecosystem around it.

00:29:40: And there are record numbers of security vulnerabilities being reported for PHP itself, and commonly used libraries and frameworks and tools... Anything that helps you verifying a potential fix or something like that is good!

00:30:03: And that is, of course not only related to security but any work you do in a project.

00:30:09: The faster the feedback loop and better if you can improve performance on it – great!

00:30:16: And more security vulnerabilities are reported as you need to inspect and write tests for them and run all existing tests every step along the way….

00:30:28: …the less time takes, the better.

00:30:32: So you mentioned that you're getting a lot more security reports.

00:30:37: Is this, the discovery of security vulnerabilities is getting faster?

00:30:43: The reporting is getting more comprehensive?

00:30:46: or are you also seeing a bunch of false reports coming through

00:30:51: all off the above including duplicates?

00:30:56: for

00:30:56: example there was recently security vulnerability reported for PHP itself.

00:31:07: that turned out to be not a security vulnerability.

00:31:14: After someone who actually knows what they are doing and not doing some prompting in the LLM of their choice, so it turned out And the ten reports all looked different.

00:31:36: So at first glance, this looks like oh we have ten new issues in that area of the code base so people start investigating them and only along the way after investigating five or six of these report they realize it's all the same... ...and its' all false!

00:31:55: That takes a lot time.

00:31:59: Yes, we get false reports but not as many.

00:32:05: As about a year ago maybe because the models have gotten better and especially with MUTOS it's that you get to comprehend using additional tooling around that like scrutiny here which is something that is built by Alpha Omega.

00:32:26: You get actionable reports, including a reproducer.

00:32:32: So that also helps cutting down the time it takes for a human to make the final decision.

00:32:39: yes this is an issue.

00:32:40: no this is not an issue and this is how we will fix it but basically all of the above.

00:32:44: um And I assume That This Onslaught Will Continue For The Next One Or Two Years.

00:32:52: After That My Hope Is We Will Have A Lot More secure software than we have today.

00:33:01: But I would also assume that a lot of projects

00:33:05: will

00:33:05: disappear over this, because they cannot keep up with it.

00:33:12: They can not fix all these issues or research on the issue and sooner or later those issues become known as everyone can prompt an LLM More people will get access to more powerful models.

00:33:31: Yeah, it's no longer the domain of very few highly skilled security experts that can find a vulnerability right and exploit do the research And then either publish a vulnerability report to the project and communicate at two to get it fixed or make a profit by illegally exploiting that in the wild, more and more people will get access to this kind of information.

00:34:06: And projects that cannot keep up with fixing these issues we'll go

00:34:11: under."

00:34:12: Which is hard for the community but also... In some ways it's necessary because of the state security?

00:34:21: We as in The PHP Foundation are trying to help the PHP ecosystem as best we can.

00:34:28: We now have an AI security engineer in residence, I hope... I got that title right?

00:34:37: It's not something that we came up with but it was suggested for us.

00:34:41: Volker Dusch who is currently working six months full time on the PHP Foundation to help libraries and frameworks in the PHP ecosystem deal with these reports.

00:34:55: Because let's face it, a lot of these projects have never had security advisory to write or publish.

00:35:04: to deal with consequences like that It starts really simple explaining things Like somebody reported vulnerability.

00:35:16: How do you verify this?

00:35:19: Don't just run the Reproducer on your machine.

00:35:25: Create an environment that is isolated, but it's safe to reproduce that and where do you go from there?

00:35:34: That's something we're currently working onto give the official slash canonical slash whatever you want.

00:35:41: call guidelines for dealing with security vulnerabilities in the PHP ecosystem.

00:35:46: make it easy and approachable as possible to educate maintainers about these things.

00:35:56: Sure, software has gotten to the point that there's so many things we need to know especially if you're independently running an open source project You need to understand accessibility, security or a problem like in the entire supply chain.

00:36:17: It's hard.

00:36:17: A lot of these projects started because somebody had a need and saw it, solved them for themselves released to other people then took off.

00:36:26: Yeah I did not imagine little bit over twenty six years ago by now when i started work on PHP in it Because I have an edge to scratch.

00:36:37: that was painful for me Not being able test the software writing in PHP.

00:36:46: I did not imagine back then that first of all, other people would start using this.

00:36:53: and now i'm getting close to one billion downloads.

00:36:57: Wow!

00:36:58: Right?

00:36:58: So yeah... That I will still be doing these twenty six years later And learned a lot along the way about maintenance and responsibility.

00:37:10: Sure.

00:37:11: I never imagined it but most of the time I'm still enjoying that.

00:37:16: That's good, so how has the introduction of AI into development processes and coding in pipelines changed?

00:37:29: either change?

00:37:29: The way you work or changed the product.

00:37:34: I'm

00:37:38: taking off my the head of the PHP unit maintainer and the PHP open source project now.

00:37:45: And put on the hat after consultant coach, and trainer who has been telling developers and teams for over twenty years right tests do this to that write architecture decision records build clean software And I was met with so much resistance over the years.

00:38:11: We do not have time for that, nobody pays for it!

00:38:18: We understand this might be right thing to do but we don't need or want it.

00:38:25: So a lot of different reasons some people were not doing And suddenly they are scrambling to introduce these tools and techniques, practices into their daily work.

00:38:43: Because with... They realize that without this guardrails using an agent to accelerate development is reckless!

00:38:55: I have to be as blunt.

00:39:00: Part of me finds that frustrating and sad, but it takes this for people to finally do.

00:39:08: Then again I think doing the right thing is still a wrong reason!

00:39:14: But software development is more about human-human interaction than even in this age of AI-assisted development.

00:39:30: And

00:39:31: all these tools and techniques, and practices would have helped still help the humans in their project... ...and we could've done that for twenty plus years!

00:39:44: The teams who have been doing it are few but there's a lot to do with them.

00:39:53: They are the ones that thrive right now because they can really accelerate their development, use none of these tools that I just mentioned, then you're just producing code faster.

00:40:29: But from my experience if you do that You just go faster into the wrong direction and accumulate technical debt faster than ever before And That is certainly not desirable.

00:40:44: No no it's not.

00:40:46: Yeah, so I think the human needs to stay in control and i can also only encourage everyone who does use AI assistance In software development.

00:40:59: So sometimes don't use it And this is a very fresh experience that I can share from last week.

00:41:08: Last week?

00:41:09: I was at conference where gave A full day training on AI-assisted software development.

00:41:18: And in the AM for the first two hours, I forced the attendees to work without an AI agent.

00:41:31: I gave them an assignment and asked them to implement a specific thing test driven...

00:41:36: Uh huh!

00:41:37: ...and then over lunch one of the attendees told me, Sebastian i'm shocked.

00:41:44: I'm doing PHP for twenty-five plus years and the last six months, basically since December.

00:41:59: an AI agent and just review what the AI agent is producing, the tests in code everything.

00:42:05: This morning you forced me to write code by hand.

00:42:09: I did that and realized it forgot so many things.

00:42:15: over last couple of months i read a lot articles about phenomenon called de-skilling And this does not only apply to IT professionals and software developers.

00:42:29: This applies to all professions, and disciplines where there is an increased use of AI.

00:42:36: One example I read was from oncologists that within a year Forgot or D learned unlearned how to interpret x-rays and MRIs To detect cancer because they rely on AI to do that for them now And that is something that genuinely scares me.

00:42:56: I think we need to tackle the education problem there.

00:43:00: on one hand, educating new developers so they understand the foundations and fundamentals So that they can stay on equal footing with AI agent and detect when what the AI agent does Is not the right thing but also to senior developers that they do not unlearn what they already

00:43:27: know.

00:43:27: Absolutely,

00:43:29: because we need to stay in control and that means... We NEED the skills!

00:43:34: WE NEED THE EXPERTIES TO JUDGE WHAT THE AI IS DOING.

00:43:39: at least that is my opinion.

00:43:41: I agree.

00:43:42: if you de-skill too much You lose the ability to effectively Audit or review.

00:43:49: with the AI is doing you're effectively pulling the human out of the loop even if there's a technically person There, you've gone from becoming a skilled reviewer or expert to a button pusher And that's not really good.

00:44:02: The goal patterns I Think think it's great Great evaluation.

00:44:09: i agree With everything You said and i think It's interesting That The conversations that I'm having with folks are increasingly going in a similar direction.

00:44:18: It's it's That we need to focus on building the right thing.

00:44:21: We need to focused on the human-to-human interaction at end of day and Making sure that we maintain skills, and stay in control over what is happening?

00:44:33: All good very good lessons

00:44:36: And then case we need one more reason To not be skill.

00:44:41: What if the agents are gone?

00:44:43: prices can only go up and all the big cloud-based, LLM based agent solutions are US-based.

00:44:54: It

00:44:54: doesn't really matter where they're based but it's a big corporation whether for corporations goals or government agenda.

00:45:02: at push of button we lose access to that.

00:45:08: if no longer do know how build software ourselves What do we then?

00:45:15: Right.

00:45:18: I can say that being a bit of an issue, so keeping your consultant hat on what is some things you see have been milestones over the past few years in changes and development or in the ecosystem... Do feel like Teaching the same lessons today that you were twenty years ago

00:45:50: At the core of it.

00:45:51: It's probably the same topics but in different contexts and In different ways, probably yeah fundamentals are still important sure.

00:46:05: And Yeah I don't really have a good answer to this.

00:46:09: That is fair.

00:46:12: You talked about the things that you've been talking about for a long number of years are now super important.

00:46:17: And this is also conversation I've been having where, especially those who have spent a lot time speaking with other developers or advocating for developer experience were advocating to make our lives easier as developers and we're getting them now but not ourselves For The Agents!

00:46:37: On one hand like you said it's great that we get it right now But on another hand It would be nice ten years ago

00:46:44: Definitely.

00:46:47: What do you see as the future over the next, I don't know a couple of years?

00:46:53: Any major changes that you see on the horizon?

00:46:56: or is that kind of time frame where things are finally balancing out with the influx of agent pull requests and agent led security and those sorts?

00:47:09: I'm almost certain about the thing that i already said earlier, with the influx of those security vulnerability reports etc.

00:47:24: That will be a painful journey over next one or two years.

00:47:30: I don't think that this will go on forever because there is the term again.

00:47:36: This will also cause friction and developers are really good at getting rid of friction, they'll figure out the tried-and-true best practices for dealing with it which means more automation, tooling or guardrails to prevent security issues that were now reported and then fixed to not come again in the future.

00:48:04: So there is the immediate impact of something like that, but also long-term impacts on improving the security posture for a project whether it's open source or closed source.

00:48:18: so at some point At least I hope this crisis of increased security vulnerabilities might be over but beyond that, i don't know.

00:48:28: What do

00:48:28: you see as the impact to the ecosystem?

00:48:33: or put another way?

00:48:34: what is the sustainability of the open source ecosystem when we see some projects shut down perhaps as a result of this influx of security issues?

00:48:45: well in general I fear that if we do not finally really figure out how to fund open source development, that open-source will die.

00:49:00: And it's just not sustainable.

00:49:06: the way right now and part of why there is no more funding for open source is that the funding.

00:49:20: That's currently happens, but most part comes out of the marketing budget over company.

00:49:26: yeah at least I did that.

00:49:29: The experience that I have with this companies that sponsor development off PHP unit it its employer branding, it's getting a company logo onto the PHP unit website so they can signal hey we do something for the ecosystem come work with us.

00:49:48: We are nice companies and there is nothing wrong with that.

00:49:53: I think however investing in maintenance of the dependencies you use to operate your business should not come out of the marketing budget, but out off the IT budget.

00:50:13: And it's not a nice to have... It is essential!

00:50:18: A lot people say now we do not need open source and dependencies anyway because my AI agent can build me all the functionality for those dependencies.

00:50:35: And then what?

00:50:36: You maintain it, your agent maintains it.

00:50:40: How do you know that really works?

00:50:42: I mean... That's the benefit of sharing common infrastructure and from a technical perspective we as in the open source community have proven over-the last depending on how you want to call or where That it makes a lot of sense to have common infrastructure that everyone can use.

00:51:10: To build the solution on, I mean It would be ridiculous if Everyone built their own operating system and web server And programming language and testing framework and whatever.

00:51:26: they Would all be terrible?

00:51:28: Yes.

00:51:29: So now we just And just in air quotes need to figure out how to make sure that everyone pays their fair share for this?

00:51:41: Absolutely.

00:51:42: So the open source developers don't burn out and stop doing what they are doing, instead do something with wood or gardening... I

00:51:55: would venture to guess if every tech company Contributed to open source projects based upon the economic value they got out of those.

00:52:04: Projects then open search developers would be.

00:52:06: that was highly compensated developers on the planet, and that's often not the case which is unfortunate because there are tremendous amount of value being.

00:52:17: Loans mm-hmm

00:52:19: There isn't.

00:52:20: initiative called Open Source pledge stated some calculations in their recommendation is that a company should give a thousand dollars or euros per developer, per year to open source.

00:52:37: Yeah!

00:52:38: To the projects that they depend

00:52:41: on.

00:52:42: That makes sense.

00:52:45: And don't get just-just.

00:52:48: be clear.

00:52:50: I do not want to get rich from doing Open Source work But... Doing Open Source Work does not put a roof over my head or food on my table.

00:53:03: I need to justify against myself that i put in thousands of hours,

00:53:11: sure um

00:53:12: over the years into doing this.

00:53:15: and of course in the beginning i did this...to scratch an itch!

00:53:20: And i still have that itch.

00:53:22: but i did not imagine that so many people depending how you count somewhere between one and two million developers worldwide, depending on my testing framework to work correctly.

00:53:37: And I feel that responsibility every time i publish a new release because I know within minutes it will be installed already a couple of hundred times and if I messed up somebody would have a miserable day Time and effort that goes into it.

00:53:54: It's time in which I cannot do other work for my customers to get a direct income from them, so we need as society to figure out how to properly compensate those

00:54:12: costs.

00:54:13: I totally agree!

00:54:14: Sebastian this has been an amazing conversation.

00:54:17: Thank you very much for your time.

00:54:19: is there one final takeaway?

00:54:22: Those are usually the toughest questions.

00:54:26: In these times of security vulnerabilities, take that time to reflect in your project and in your team how you deal with your dependencies?

00:54:41: Do you have a process for updating your dependencies?

00:54:45: if having one.

00:54:50: It can be manual in the beginning, if you already have a process and it's manual start thinking about automating it.

00:54:59: now do need to minimize that time between security vulnerability becomes known for something you depend on?

00:55:11: And appropriate fix is released To You Having That Fixed.

00:55:16: Excellent advice.

00:55:17: Well thank you again So much, it's been great having you here.

00:55:20: I appreciate your conversation.

00:55:22: Thank you for having me again!

00:55:23: Alright and to the rest of you take care enjoy coding.

New comment

Your name or nickname, will be shown publicly
At least 10 characters long
By submitting your comment you agree that the content of the field "Name or nickname" will be stored and shown publicly next to your comment. Using your real name is optional.