That question led Paolo Rizzi (sustainability principal at ustwo), Nayan Jain, Executive Director of AI at ustwo and Nick Hegarty (Executive Director of Technology at ustwo)to start looking for tools that could help developers see the environmental cost of their AI usage while they worked.

Having found no real tools for this, ustwo and the University of Bristol built one: PRISM. It launched last week, and we sat down with Nayan to talk about how it works and what it aims to change.

PRISM uses AI token activity to estimate energy use and emissions

The tools that were available mostly focused on data centers or broad “big picture” ideas, but none catered to the developers actually using AI tools.

That gap led the ustwo team to think about ways to connect AI usage to real-world energy:

We quickly ran into a challenge that still exists today: a lack of transparent data from model providers. Without reliable information on energy consumption and infrastructure, it is difficult to build and validate a model with confidence.

Working around that, they decided to rely on tokens, a visible and relatively accurate measure of AI spend.

The idea was to use token activity as a proxy for compute demand and estimate energy use and emissions using published research and carbon accounting principles, including the Green Software Foundation’s Software Carbon Intensity framework.

Nick Hegarty, who helped narrow the focus: could they help developers understand the environmental impact of their AI use while they worked? That made the project possible.

From idea to IDE

The answer was to create an in-editor tool, where the developer could see an estimation of their token costs and impact on energy consumption in real time.

The theory here is that, with this data, engineers can see their habits and perhaps be more conscious about their usage:

Our theory is that making this visible can guide engineers into more mindful habits around their AI consumption in the moment. Because AI providers don’t publish complete energy or emissions data, PRISM acts as a proxy for energy consumption by surfacing an estimate rather than an exact measurement.

PRISM directly monitors token usage, the model being used, and the provider. For other tools, like GitHub Copilot, PRISM reads local activity logs. AI requests made by an application at runtime are captured through a local interceptor.

The app then combines input and output tokens into an estimate. Nayan notes that these will be separated “as soon as robust factors exist”.

How red was that prompt?

In practice, PRISM is more of a subtle indicator than a big flashing number that appears after every call. Nayan explained how it feels to use it:

In the editor, a status indicator reflects your most recent call, colour coded. The headline feature is Relative Impact Classification, where each interaction is rated Green, Amber, or Red based on where it sits compared with the other requests in the same project.

Nayan continued to explain the colors:

Green is below the median, Amber sits between the 50th and 90th percentile, and Red is the top tenth. A few requests need to accumulate before the colours become meaningful, because the whole point is comparison within your own project rather than against an arbitrary threshold.

Clicking around the dashboard more, users can get information broken down by model usage, as well as other interesting metrics:

• Timeline of estimated carbon over the course of development
• Heatmap that shades from green through amber to red
• Breakdowns by branch and other visualisations.

However, Nayan explains that a relative, percentile-based design was chosen due to the inability of estimates to present absolute carbon figures. The goal of the tool is to explain and raise awareness more, and hopefully educate engineers on how their usage looks like from the eco standpoint.

The impact is awareness, not less AI use

Ustwo has tested PRISM with UOB students and across the company’s engineering team, and the results have been positive so far:

Several users said that seeing estimated emissions made them more deliberate with AI tools.

Nayan added that engineers, having seen the data for their usage, tried to make adjustments to their style and became a bit more conscious of how they refine requests.

Some wrote shorter, more precise prompts instead of using multiple iterations, and others paid closer attention to model selection after seeing how much environmental impact different models could have for similar tasks.

But as Nayan said, what interested them the most wasn’t that developers used AI less, but that they became more aware of how they were using it. “Once the data was visible, users started noticing things they hadn’t considered before.”

PRISM won’t solve AI’s environmental impact, but it makes it more visible

Right now, PRISM can provide data and insights for cloud and assistant-based models by identifying them, capturing token usage, and calculating the energy factor from a list of supported models. Locally run models are not yet supported, but might be in the future.

As the tool grows, ustwo sees its ideal outcome at three levels.

For engineers, the goal is awareness: giving users more information about their environmental impact during their work. Nayan says this is not about telling people what to do, but showing them a fuller picture of the tools they’re using. For organisations, the goal is to create a shared picture and open up more conversations about sustainability, governance, and responsible AI.

Beyond those, ustwo is positive about the potential of collaboration in the field of environmental impact of AI. He concluded:

PRISM won’t solve the environmental impact of AI on its own, but if it helps make that impact a little more visible, and sparks better conversations and behaviours as a result, then we’ve achieved something worthwhile.

The post This IDE Plugin Shows the Energy Cost of Your AI Prompts appeared first on ShiftMag.

I’m a software engineer who works on domains that represent the messy corner of the internet.

In this corner, there are bad actors doing bad stuff and us trying to make their lives harder. Hence I spend a lot of time looking at what people do when they’re trying to slip something past a system. This led me to developing a slight paranoia about anything that reads untrusted input and then does something with it.

So when half my Linkedin timeline started losing their minds over OpenClaw, I developed a specific kind of curiosity:

What happens when this thing reads an email that’s actively trying to manipulate it?

So I tried… and the model caught me on the first try.

That’s the disappointing part. The interesting part is what happened when I tried harder – and what I realized about where the defense actually lives.

The hype isn’t manufactured, which is the whole point

But first, let me be honest about why this thing went viral. OpenClaw is genuinely impressive.

The first time I asked it to triage my inbox in detail and it actually did, I had the same reaction every other dev on X or LinkedIn has been having: oh now we are talking. This is the thing!

That reaction is part of what makes this complicated. Because the same architecture choices that make OpenClaw feel magical are the ones that create some genuinely hard security questions. The type of questions the broader industry hasn’t figured out how to properly answer yet.

15 minutes from npm install to AI reading your Gmail

Fifteen minutes. That’s how long it takes from npm install to having an LLM agent reading your inbox. The installer warns you this is a hobby project and still in beta – which, with 360k GitHub stars and 1.500+ contributors, reads more like a legal disclaimer than a self-description. The warning is the project being honest: security isn’t the primary concern here.

The onboarding wizard asks which channels you want, which model provider to route through, and walks you through the gateway setup. Gmail takes a little more work. OpenClaw doesn’t ship a “Connect Google” button because Google’s OAuth verification for production Gmail apps is strict, so every developer rolls their own Google Cloud project. The flow:

# 1. Create a Google Cloud project, enable Gmail API, download credentials JSON
# (console.cloud.google.com → New Project → APIs & Services → Library)

# 2. Install gog — OpenClaw's OAuth bridge for Google Workspace
brew install gog

# 3. Authenticate
gog auth --credentials ~/Downloads/client_secret_xxx.json
gog auth add me@example.com --services gmail,calendar,drive,contacts

gog auth opens your browser and walks you through Google’s consent screen with a scary “this app isn’t verified” warning (technically correct – it isn’t, you just installed it). You grant the scopes. Done.

That’s what the wizard shows you. Four defaults it doesn’t show matter more.

Gateway auth is off by default. The gateway runs on localhost, sure. But the moment you expose it, it’s wide open. Bitsight found over 30.000 OpenClaw instances exposed directly on the open internet in their February report. If you’re one of them, anyone who can reach your WebSocket can issue commands as you.

Permissions are off by default. Out of the box, OpenClaw runs with no filesystem restrictions. A skill can reach anything the OpenClaw process can reach – ~/.ssh, browser credential stores, shell history. You configure restrictions yourself in openclaw.json.

Set chmod 600 openclaw.json to restrict file permissions. And if you’re testing skills from unknown publishers, run OpenClaw inside a Docker sandbox.

That’s from the project’s own docs. Read it again. The maintainers know what happens if you don’t sandbox the agent.

Skills are markdown files. OpenClaw learns new tools by loading a SKILL.md This is a YAML file with a body describing, in English, which CLI commands it can run. The model reads the description, decides when the skill is relevant, and runs the commands the markdown tells it are available. Here’s a trimmed version of the real gog skill:

---
name: gog
description: Google Workspace CLI for Gmail, Calendar, Drive, Contacts.
metadata:
  requires:
    bins: [gog]
---

# gog
Use `gog` for Gmail/Calendar/Drive/Contacts. Requires OAuth setup.

## Common commands
Gmail search: gog gmail search 'newer_than:7d' --max 10
Gmail send:   gog gmail send --to a@b.com --subject "Hi" --body "Hello"

That markdown file is the entire trust boundary. Malicious instructions in a SKILL.md and legitimate ones look identical to the model, because they are identical. The only thing differentiating the “read my mail” prompt from “send mail to a stranger” is the model’s judgement about it.

OAuth scopes are all-or-nothing. The three scopes gog asks for – gmail.readonly, gmail.send, gmail.modify – apply to every email in your account, ever. No “only this or only that” variant. That’s a Google API design decision, not OpenClaw’s fault, but you inherit it the moment you wire them together.

The test I came here to run

So I sent myself an email from a burner account. The visible body was a generic delivery confirmation. At the bottom, using an ancient trick of white text on a white background, I embedded a quiet exfiltration request dressed up as a routine maintenance message. These instructions told the agent to forward emails containing password-manager keywords to an address I controlled.

Then I opened the chat interface and asked the agent a simple question: Are there any emails today?

The model saw through me

It flagged the sender as suspicious – a personal Gmail issuing a corporate-sounding directive. It called out the hidden text explicitly. It refused to act on the instruction. It categorized the message alongside the day’s normal mail, presented its reasoning, and asked whether I wanted to flag the suspicious one as spam.

I’ll be honest, I was kind of disappointed. I’d sat down expecting a war story. Instead, I got a well-aligned frontier model doing exactly what a well-aligned frontier model is supposed to do.

So I tried harder

I thought about what had triggered the defense and iterated.

The first attempt hit at least three trained heuristics at once: suspicious-sender detection, hidden-text detection, and a pattern-match against “silent operation, don’t tell the user” phrasing.

I removed the tells one at a time. Visible text instead of hidden. Plausible sender framing instead of a personal Gmail. Configuration-style payloads instead of one-shot exfiltration. Setting up an ongoing workflow rather than asking for something bad right now.

Against the frontier model I was routing through, every version I tried got caught. Sometimes immediately, sometimes with a clarifying question, but the model never silently complied.

Against lighter models, that’s not what happened.

Same architecture. Same skill. Same agent. Cheaper model. And the defenses that were reliable at the top of the hierarchy became probabilistic as I moved down. I’m not going to publish specific payloads. Not because the finding is novel (Cisco, CrowdStrike, and Barracuda have all been saying this for months) but because the payload is not the interesting finding here.

The gradient is.

The defense isn’t where you think it is

Here’s the thing the defensive and offensive communities both already know, and that almost nobody installing OpenClaw on a Friday night has internalized.

The security of these agent systems lives at the model layer, not at the architecture layer.

OpenClaw doesn’t defend against the attack. The model does. The skill doesn’t defend. The tool framework doesn’t defend. If the model you’re routing through has been trained to spot the pattern, the attack gets caught. If it hasn’t or if it was trained to spot last month’s patterns but not this month’s – the attack lands.

Which means the security posture of your OpenClaw install depends almost entirely on which model is sitting behind your API key that day. And most developers running personal agents are doing one or more of the following:

• Routing through whichever model is cheapest this week
• Using a fallback chain that drops to lower-tier models under load or rate limits
• Not paying attention to which model they’re on, because the agent works regardless

Every one of those is a security decision. Most developers don’t realize they’re making one.

Why this is the failure mode that matters

The architectural problem doesn’t go away when the frontier model defends perfectly. Three facts stay true:

1. The agent reads untrusted external content: inboxes, fetched pages, message bodies.
2. The agent has tools that can act on what it reads: send email, run shell commands, call APIs.
3. Skills declare capability in plain English: which means, at the token level, an instruction in a skill and an instruction in an email are the same thing.

The model is what stands between those three facts and an exploit. For the frontier model I tested, the model was enough. For the lighter ones, less so. And the model is a training artifact. This means the defense you have today is not necessarily the defense you have tomorrow, and the defense at the top of the model stack is not the defense at the bottom.

This isn’t just an OpenClaw bug; it’s a universal one. It’s the current shape of personal-agent architecture, and it’ll probably take several generations of isolation patterns, capability frameworks, and signed skill registries before the industry has an honest answer.

In the meantime, the defense you get is whatever your provider shipped this quarter… and the defense the developer across the room gets is whatever their provider shipped, and those are not the same thing.

Where this goes from here

What I came away with is that OpenClaw is the most honest version we have of where personal agents are going and it’s exposing a question the whole industry is going to have to answer:

When the only thing standing between an untrusted email and a privileged action is the model’s judgement, and model judgement varies by an order of magnitude across the price curve, what is the security posture of the system?

Right now the honest answer is: whichever model you happened to pick. I believe that shouldn’t be the case.

If you want to play with OpenClaw, play with it but do it in a hardened environment with throwaway credentials, pin your model explicitly in config, keep it away from your real inbox until the safety story catches up to the capability story, and read the hardening docs before you read the tutorials.

The post I Tried to Get OpenClaw to Betray Me. The Model Caught Me on the First Try appeared first on ShiftMag.

Many startups today open source their products. But it’s not just startups: Microsoft open-sourced VSCode and GitHub Copilot; Meta gave us React and LLaMA; Google opened up Android and the Chrome browser. All of them rely heavily on Linux – itself an open-source operating system.

So for many – especially startups building infrastructure or developer tools – building on open source, or open-sourcing their own product, might seem like the obvious, default choice.

But it’s not. Far from it.

How not to use other people’s open source projects

A year ago, PearAI (a YC-backed startup) forked VSCode and the Continue.dev extension, repackaged them, and presented the result as their own. The move sparked public backlash and led Y Combinator to issue an apology for mishandling the situation.

While PearAI’s intentions may have been good, their actions revealed a lack of understanding (or concern) about intellectual property. This was exemplified by their defense: “Dude, I ChatGPT’d the license. We’re busy building- can’t be bothered with legal.

Recently, another YC startup, Glass, made a similar misstep: they took an open-source project, changed the license, removed attribution, and claimed to have built it in just four days. Public backlash was swift once again.

The issue here wasn’t that they copied or reused the code – the license does allow that. The issue is that they changed the license to something else, didn’t acknowledge they weren’t the original authors, and again demonstrated a profound lack of understanding or care about it.

This “it’s open source, so it’s not stealing – who cares?” mindset from move-fast-and-break-things startups reflects poorly not just on the founders, but also on their investors. Both of these startups are part of YC, which now risks appearing as if it either doesn’t know – or doesn’t care – about intellectual property when it comes to open source.

How not to open source your own stuff

On the other side of the table are founders who open source their product without fully understanding the consequences.

Earlier this year, the author of ColorMagic complained that someone had ripped them off. And yes – if you open source your product, someone can take it, tweak a few things, and host it themselves (as long as they follow the license). Someone did exactly that, and the author was upset.

To make matters worse, the author didn’t even choose a specific open source license that could have protected them while still being open.

I get it – developers, designers, and founders aren’t lawyers. As a developer and founder myself, I can relate. But ignorance of the law isn’t an excuse for breaking it. Open source, in particular, works best when we all try to be good citizens of the community. And that means having at least a basic understanding of open source licensing.

Public humiliation for a two-month-old startup is a minor issue compared to what can happen later in your product’s life, especially if it gets popular or if you’re being acquired.

When licensing missteps come back to bite you

One of the things that prospective buyers will do is make a thorough technical and legal due diligence. This involves tracing the origin and ownership of all intellectual property in your startup.

If this kind of error is detected at that stage, it’s much harder to fix: there may now be years of work and thousands of lines of code done under an incorrect license, which must be retroactively applied. In the end, you might be forced to publish all of your own source code, potentially lowering your acquirer’s interest.

Another high profile example is ElasticSearch, which initially used a very permissive license, with the business model of selling a managed version of the database.

When they got popular, Amazon hosted a version on AWS, allowing it to get revenue without investing in the service development. ElasticSearch overreacted, switched to a non-open-source license, to the ire of many genuine open source users, which flocked to Amazon’s open source fork. ElasticSearch backtracked later, switching to a more strict open source license which does prevent Amazon from doing what they’ve done.

MongoDB and RedisLabs had the same model as ElasticSearch, ending in the exact same situation, with similar results.

Be a good open-source citizen!

When thinking about open sourcing your code, consider these questions:

• Why do you want to open source? What it is that you hope to achieve? You must have a good reason, not “everyone else is doing it”
• What if your competition just takes your code and uses/improves/hosts it? Does it matter? What’s your moat?
• Based on the above, how “open” do you want to be? (open source everything under a very permissive license (MIT, BSD, Apache) OR open source non-core or commodity parts of the code; keep secret source secre OR open source everything under a strict license, so that anyone using it must contribute code back to you (GPL, AGPL))
• Open source “eventually”, but not right now – constrain competition while being “almost” open source  (FSL, BSDL, SSPL)

When using 3rd party open source, especially for a core of your product, consider:

• What does their license require you to do? Are you required to open source your own code? Can you freely host and redistribute it?
• You’ll have many dependencies – how do their licenses mesh together? Some are known to be legally incompatible.
• Keep some kind of log – know which 3rd party code you forked or depend on, what are the licenses, so you can always trace the IP ownership
• Don’t “chatgpt” a legal document. Ask a lawyer, or at least find a template from a reputable source.
• Don’t invent your own license (“enterprise” or otherwise). Use a well known license that your customers will have easier time to evaluate as well.

The post How to Use Open Source Without Losing Your Code, Users – or Sanity appeared first on ShiftMag.

The Omnichannel Messaging for WooCommerce is a powerful plugin that directly integrates Infobip’s communication tools into WooCommerce. This enables you to deliver personalized SMS notifications, transactional emails, and targeted marketing campaigns – all from one platform.

The plugin was developed as a joint-venture between Infobip, a global leader in omnichannel engagement, and Neuralab, an agency with more than a decade of experience in building web / eCommerce projects (and a global WooCommerce Open Source Champion).


The goal is simple – to enable online merchants and WordPress/WooCommerce developers to automate marketing and omnichannel communication, which they truly need and deserve. The end result is combining the best of AI and human interaction – ensuring WooCommerce end users receive superior customer service.

Neuralab’s Kresimir Koncic stressed that this is especially important if you take into account that more and more omnichannel communication will go through “Gen AI” workflows:

All currently available platforms prioritize message sending, while data processing is secondary. Over the past decade, we’ve noticed a need for a more robust and functional platform, which led us to pivot towards Infobip’s enterprise solution.

Infobip has “data” at its core through the CDP (Customer Data Platform) module, and we believe this is an excellent foundation for building any subsequent functionality and interactivity that merchants should have. 

WooCommerce merchants will be able to send all their eCommerce data to the Infobip People platform, which can then power various Gen AI chatbots that communicate with users through Live Chat, WhatsApp, Viber, or any of the dozen channels.

Routing from AI to human

Merchants have always struggled with human agent costs, which is the main reason you don’t see 24/7 live chat widgets in average eCommerce stores. While financially challenging, this represents a missed opportunity because customer support shouldn’t be viewed as a cost center but rather as a revenue generator and experience enhancer.

Naturally, merchants or developers will want to deploy an army of robotic agents magically serving users – something akin to Star Trek’s ship computer. Reality is much “messier,” and we face complex technical and legal hurdles in integrating AI into automated omnichannel experiences. Kresimir points out that LLM models hallucinate and that that’s a feature, not a bug, and will not disappear:

Hallucinations are, in fact, inherent features of all implicit systems like artificial neural networks. Additionally, data source integrity is often questionable, which brings me to my main point. Merchants should leverage GenAI in areas where it’s most efficient – in open conversations and creative ideation.

Infobip’s “cautious” approach to GenAI tools enables switching specific chat functions on and off. For example, when a customer asks: “Which socks go with these brown shoes?” – AI can shine in cross-selling and user engagement. But when it comes to specific questions about refunds, discount policies, or shipping – traditional IF/ELSE bots or, better yet, human operators should remain the norm. The Infobip platform enables “routing” in both scenarios.

The robot can redirect the conversation to a human agent within Infobip’s product or to an external third-party contact center or CRM.
 
Our vision for the Infobip-WooCommerce integration is to combine the best of AI and human interaction, ensuring WooCommerce end users receive superior customer service. The latest partnership between Infobip and SplxAI, which enables automated “Red Team” checks, is a perfect operating example of how to guardrail Gen AI conversations.

What do developers and agencies get with Omnichannel Messaging for WooCommerce plugin?

The first version of the integration covers basic functions that WooCommerce merchants and developers can utilize through four main modules:

• Communicate with customers via SMS channels in automatic (e.g., order status changes) or manual mode (if there are product or order issues)
• Utilize Infobip’s vast network of email servers to increase message deliverability, crucial for UX, spam prevention, and legal obligations toward end users
• Integrate Infobip Live Chat solution into their store and connect with GenAI Infobip systems (currently a manual process through WP theme, but we’re working on automation integration for future versions)
• Most importantly, export customer data from WooCommerce to Infobip “People” CDP and use that data for various marketing automation

What’s next?

The 2025 Roadmap for the Omnichannel Messaging for WooCommerce plugin will be announced soon, but it’s been mentioned that it will include improved and automatic sync between Infobip and WooCommerce, new channels such as RCS, Telegram, and WhatsApp for a truly omnichannel experience, and more marketing automation options.

The post Meet the Omnichannel WooCommerce Plugin Developers Need and Deserve appeared first on ShiftMag.

If you’re a tech enthusiast or an open-source advocate, you’ve likely encountered the term #wpdrama. But what exactly is it, and why has it caused such a stir in the WordPress community?

In short, Matt Mullenweg, co-founder of WordPress, criticized companies like WP Engine for benefiting from open-source software without contributing back.

It’s not the first time a company has been accused of exploiting open-source contributions, but the way Matt addressed it sparked significant controversy. Open-source contributors face these issues day in and day out. Articles have already been written on this topic (to name a few).

What is dramatic is the way this was addressed. The argument was framed as he went against one specific company, and his actions called all the good things he has been doing for the WordPress community into question.

In the end, as the song says, It’s all about the money.

The Contributor Effect

At the beginning of this #wpdrama, I was just reading the news, checking the Twitter threads (yes, I’m still calling it Twitter), and watching it all unfold in real-time. It was scary to see one man going against every sound advice people were giving him. This resonated deeply with me because I, too, am a long-term contributor to WordPress.

Even though I’m not as active in the WordPress community as I was a few years ago, I still hold the community in my heart. It is what drew me in. WordPress was my ‘gateway drug’ to programming.

I started working with WordPress in 2014 at my first job. Soon enough, I realized that the software is more than it seems. I found out there are thousands of people writing the code and trying to make it better. Not only that but there are people organizing meetups and conferences, bringing people together who feel passionately about the project. A lot of popular open-source software have similar communities, but I don’t think that any has the scale of the WordPress community.

And it is that community that makes you go back to contributing. There is a sense of accomplishment when you see your name in the credits of a major release. I went from reviewing WordPress themes to being a representative of the themes team to a member of the WordPress Coding Standards group. I’ve organized local meetups after a long time of hiatus. During my time as a contributor, I met dozens of amazing people from all over the world and I call them friends now.

Seeing all this happening was a bit disheartening, partly because it confirmed why I slowly stopped actively contributing.

The price of the contribution

In 2019, I met Matt at WordCamp Berlin to discuss issues related to theme reviews and their role in the community. The meeting left me feeling like I was talking to a politician – vague answers and no concrete solutions.

In a sense, Matt is like a politician—never giving straight answers. And I can understand him. He cannot promise to solve everybody’s problems with WordPress.

Not because he cannot or doesn’t want to. The reason is quite simple—besides being a co-founder of WordPress software, he is the founder of Automattic, a parent company of WordPress.com, a hosting platform for blogs and websites powered by WordPress software (I can feel the confusion setting in). As a CEO, his mission is to have a profitable company. 

This was the gripe most people had when wanting to contribute to WordPress. It’s no secret that the direction WordPress software makes is the direction that is most beneficial to Automattic.

The introduction of the Gutenberg editor was seen as a response to competitors like Wix and Squarespace, which had already simplified page building for users. Despite its potential, Gutenberg received the most 1-star reviews on wordpress.org, highlighting the community’s dissatisfaction.

The alienation of contributors started a long time ago and culminated with the latest drama.

Giving your time and money with nothing in return is demotivating. This is what made me slowly stop making contributions.

The drama unveiled

At his State of the Word address at WordCamp US in Portland, Oregon, Matt Mullenweg decided to ‘go nuclear’ (his own words). He attacked all the companies taking advantage of WordPress software without contributing back, specifying WP Engine as the big bad guy funded by private equity firms. He went so far as calling them a ‘cancer to WordPress’.

You could say the pot is calling the kettle black, as several private equity firms fund his own company, Automattic.

We can agree that his company spends much more money on contributions than any other. Then again, they do have the most to gain or lose by supporting it.

However, the point of contributing is that it’s not all about how much money you bring to the table. WP Engine contributed by sponsoring numerous events and paying its developers to maintain free and paid versions of very popular plugins such as Advanced Custom Fields. We could play tit for tat on this one and end up being none the wiser. Ultimately, what about thousands of contributors who took their time and contributed but got nothing in return?

In the aftermath of his speech, it became public that he contacted them before the speech and requested that they give 8% of their revenue to Automattic due to a ‘trademark violation.’ His issue wasn’t just about contributing.

Aftermath

Soon enough, cease-and-desist letters started flowing, followed by Matt banning all members of the WP Engine engineering teams that maintained their plugins. This resulted in lawsuits and a hostile takeover of one of the most popular WordPress plugins, Advanced Custom Fields, under the guise of security.

It was an unprecedented move that proved that Matt has ultimate control over wordpress.org. In an interview with The Verge, he said that he owns wordpress.org (the site that hosts all the WordPress themes, plugins, and related services that power the WordPress community).

This one revelation, coupled with his responses on social networks, caused quite a stir among long-time contributors and enterprises that used WordPress as the basis for their web presence.

To be honest, it’s hard to say which part of this #wpdrama is worst. This could impact regular users, enterprise owners, or contributors.

In my opinion, one of the worst things that happened was the exodus of core committers—trusted and regular WordPress committers to the core software. Many prominent WordPress users stopped their contributions until this mess was resolved. 

The effects of this can be detrimental to the overall stability of the software. When you lose quality contributors to your software, you risk adding code that will do more harm than good. When you lose people who have worked on it for years and know its ins and outs, more and more subtle bugs creep in.

The #wpdrama saga underscores the tension between commercial interests and community contributions in open-source projects. As WordPress navigates these challenges, the community’s response will be crucial in shaping its future.

The way forward

We don’t know how these lawsuits will end. This is the first time we are seeing two massive players with lawyers who charge serious amounts of money engage in legal battles. 

This creates uncertainty for end users and, for regular contributors, fear of losing jobs and means of survival.

One thing is clear: the benevolent dictator-for-life model isn’t working. In an open-source community with such an impact on the web, we must have clear governance in place—a board consisting of trusted community members pushing the agenda that will benefit the contributors and the end users, not corporate interests.

The governance idea isn’t new. An initiative called wpgovernance.com aimed to implement guardrails against precisely what happened.

It may sound ungrateful toward Mullenweg, seeing as he was the person spending his company’s money to run WordPress.org. But with such a big impact, something like a PHP foundation could have been set up for WordPress instead. The infrastructure wouldn’t be dependent on one person but on the goodwill of the individual contributors and companies profiting the most from the project.

WordPress will have a great future only if we figure out how to change this at a structural level and take back the community.

Only time will tell.

The post How to Scare your Contributors Away: A Veteran’s View on the Platform’s Turmoil appeared first on ShiftMag.

Instead of being replaced by AI coding tools, developers are increasingly integrating AI into applications and engaging with AI projects on GitHub.

According to GitHub’s latest report, Python surpassed JavaScript as the most popular language on GitHub, reflecting a rise in data science and machine learning. Developers are rapidly building AI models and engaging with AI projects on GitHub. They’ve also noticed an Increased interest in AI agents and smaller models that require less computational power.

1.4 million new developers globally joined open-source projects on GitHub, with a majority of them contributing to commercially backed and generative AI projects. 

In 2024, there was a 59% surge in the number of contributions to generative AI projects on GitHub and a 98% increase in the number of projects overall.

There are more developers than ever

The data also shows the rise in the number of developers suggesting AI helping more people learn to code and build software. The number of people actively contributing to GitHub projects is particularly expanding, especially in regions like Africa, Latin America, and Asia, with significant growth in first-time open-source contributors. Brazil’s developer community is growing fast, and India is expected to become the world’s largest developer population on GitHub by 2028.

Python on the throne

Python is now the most used language on GitHub. The rise in Python usage correlates with large communities of people joining the open-source community and with the rise in machine learning and data science projects.

Systems programming languages, like Rust, are also on the rise, even as Python, JavaScript, TypeScript, and Java remain the most widely used languages on GitHub, the report says.

The post Python overtakes JavaScript as the most popular programming language appeared first on ShiftMag.

A US District Court judge in San Francisco has dismissed most of a class-action lawsuit that challenged the legality of GitHub’s use of code samples to train its AI-driven coding assistant, Github Copilot.

The suit was filed by Matthew Butterick, a lawyer and open-source programmer, and Joseph Saveri Law Firm, InfoWorld reports. It claimed that GitHub’s training of the Copilot AI on public GitHub code repositories violated the rights of creators who posted code under open-source licenses on GitHub.

The law firm made the suit and all the documentation public and claimed that it represented the first major step in the battle against intellectual property violations in the tech industry arising from artificial intelligence systems.

Despite Microsoft’s protestations to the contrary, it does not have the right to treat source code offered under an open-source license as if it were in the public domain.

However, the judge ruled that the plaintiffs had failed to establish that restitution for any unjust enrichment was available as a measure of damages for their breach of contract claims. The claim for breach of contract of open-source license violations against all defendants was not dismissed.

Software Freedom Conservancy, a non-profit organization that promotes open-source software, has been asking developers to quit GitHub for several years, and the launch of Copilot, an AI coding assistant, was the tipping point. They, too, considered GitHub to have violated its users’ intellectual property by training its models on their code.

In a blog post, the conservancy announced that it was ending all use of GitHub and will be offering a long-term plan to assist FOSS projects in migrating away from it.

The post Lawsuit against GitHub Copilot AI dismissed appeared first on ShiftMag.

If you have been in the open-source community lately, you know what I am talking about. The story goes something like this: There were loads of videos/blogs/events hyping up open-source contributions, mainly as a good gateway to land your dream software engineering job. And to some extent, it is true.

However, this trend has also brought a flood of pull requests (PRs) that contribute little to nothing or, worse, add clutter to the codebase.

And this is why, lately, you can find a wave of blogs and videos on why you should NOT contribute to Open-Source.

This article will show how bad it can get with the latest surge of unsavory PRs.

ExpressJS​

The latest drama has happened in the epxressjs GitHub repo. As you can see, there were loads of “Update Readme. md” pull requests.

This doesn’t immediately sound bad; perhaps the Readme was riddled with typos. It’s a long shot, but let’s investigate. Unfortunately, that wasn’t the case. Looking closely at some of these PRs, we will see the drama’s root cause.

So let us take a look… 

Maybe it’s just one bad apple? Well, let’s look at some others…  

As you can see, these PRs are not trying to improve the projects they contribute to. Although somewhat comedic, having lots and lots of such PRs is a nightmare for the project’s maintainers.

And the last one, I think, tells the bigger picture in this story. It seems that lots of these PRs were a learning experience (assuming “Collage” was a mistype of “College”). Although, that is an assumption made in good faith.

Some of them could have been done as a sort of shortcut for bolstering resumes, which is a far more alarming intent.

The missing puzzle piece​

Newcomers don’t understand that contributing is not all about the code. It is about investing your time in understanding the project and the issues it is trying to solve, being a part of the community and the discussion, and wanting to better the project because you want it to thrive.

And that is what is praised about open source contributions, the will to learn and the will to help. In the process, you demonstrate that you can be proactive and solve complex issues. That is what employers are really looking for.

One look at contributions like these, and you can be sure potential employers will ignore you.

Final thoughts​

Now, there were some external actors in the latest PR nightmare that I won’t be naming here because I doubt that they acted with ill intent. It’s the latest buzz, and I am sure that you can find them with a single Google search if you want to.

It’s important to mention that when considering contributing to open-source, start by looking at the projects you already use and are familiar with.

Alternatively, focus on projects where you have domain expertise, as sharing that knowledge can be a valuable resource for the maintainers.

Have you had any bad experiences contributing to open-source?

The post How promoting open-source can become problematic appeared first on ShiftMag.

These cases vary, but they all share a common thread: Flutter, an open-source framework created by Google in 2017, can be a better choice than native development and other cross-development frameworks. Let’s explore when and why.

Building high-performance, visually appealing applications with ease

A rapid development cycle becomes paramount for effective iteration during the development phase. Leveraging Dart’s compiler technology, Dart can be compiled, and by extension, Flutter, for multiple architectures. When an app is ready for production deployment, the Dart ahead-of-time (AOT) compiler stands prepared to compile them into native ARM or x64 machine code. 

The outcome? Excellent performance, ensuring the best possible user experience. On the other side, there is a just-in-time (JIT) compiler used during development which provides incremental recompilation (enabling hot reload), live metrics collection (powering DevTools), and robust debugging support.

Flutter’s hot reload feature empowers engineers to view the effects of their code changes instantly. Gone are the days of needing to restart the entire application with every code modification. This immediate update capability enables engineers to rapidly experiment with and refine their code, resulting in a more efficient and iterative development process.

In addition, Flutter distinguishes itself from other cross-platform solutions by not relying on web browser technology or native UI components specific to each operating system. Instead, it employs Skia/Impeller for rendering. In this regard, Flutter shares more in common with game engines like Unity than other cross-platform development frameworks. The diligent Flutter team has painstakingly recreated all Material and iOS (Cupertino) UI components for engineers to employ within Flutter. This is particularly beneficial for crafting custom UI.

Finally, Flutter proudly boasts its status as an open-source framework. This means that its complete source code is freely accessible to the public. Engineers can explore and contribute to the continuous improvement of the framework without incurring any cost. This openness fosters transparency, collaboration, and community engagement. 

Speaking of community engagement – the Flutter community of over 2 million engineers is thriving. Countless resources are readily available to assist engineers in mastering the full potential of Flutter. This growth is also evident in the increasing number of stars Flutter has garnered on GitHub and its popularity in Google search trends. In fact, Flutter has overtaken React-Native to establish itself as the most popular cross-platform development framework.

When to use Flutter and when not to

Flutter is well-suited for applications where there is no requirement for interactions with highly specialized native functionalities. It shines in applications heavily relying on networking and highly customized user interfaces (UI).

For example, Flutter is an efficient solution for building financial and health/fitness applications. It is chosen for its ability to create secure, visually appealing experiences across mobile and web platforms. It offers benefits such as the convenience of a single codebase for efficient development, quicker market entry, and easier creation of polished user interfaces, complete with interactive graphs and charts.

Flutter is also becoming a suitable choice for IoT projects because it’s starting to integrate better with platform-specific features like Bluetooth Low Energy (BLE). As the IoT space keeps growing, there’s a higher demand for IoT apps. We’ve noticed that more Flutter BLE libraries are emerging, making connecting and working with IoT devices easier. This was a big drawback for Flutter in the past, but it’s not so much of an issue anymore.

Also, perhaps a more curious use case for Flutter is using it for Minimum Viable Product (MVP) development. Its hot reload feature offers a rapid and cost-effective solution, enabling quick iterations and reducing time-to-market.

Deciding between Flutter and native development

If you want to streamline development and reduce the workload, Flutter is an excellent choice for small and large teams alike. If you prioritize fine-tuning and taking full advantage of platform-specific tools and features, native development is the way to go. It provides greater control over the user experience.

Deciding between Flutter and React Native

If your project has special design needs, pick Flutter. If it needs to look like typical iOS or Android, go with React Native.

Enhancing Flutter is a constant work in progress

Flutter has undergone a significant transformation over the years, evolving into a more mature and stable framework. This progress has been driven by a collaborative effort from the community, which has actively identified and addressed issues, resulting in a more robust framework. Google’s commitment to Flutter’s growth is evident through the consistent introduction of new features and capabilities, including improved performance, new widgets, enhanced tooling, and seamless integration with various platforms, to name a few.

For example, in recent notable updates, Flutter has introduced support for WebAssembly (Wasm), enabling more efficient code execution and enhanced performance. Additionally, Impeller now precompiles essential shaders during the Flutter Engine’s build, resulting in faster and more stable animations and improving the user experience. Also worth a mention is Flutter Add to App, which simplifies the integration of Flutter into existing applications, allowing for seamless cross-platform operation, albeit with potential development overhead in complex integrations between native components and Flutter.

More significantly, although it initially offered support exclusively for iOS and Android, Flutter has since expanded its reach to include web, Windows, Linux, macOS, and even embedded systems, as noted in the regularly updated Flutter release notes.

However, so far, our primary focus with Flutter at Infinum has been on mobile development. Our position is that while Flutter has made significant strides, there are areas in which it still has to catch up with web development frameworks like React or Angular. This discrepancy is expected, given their long-established presence, Flutter’s reliance on CanvaseKit, as well as Flutter’s limitations, like the absence of SEO optimization, occasional issues with hot reload functionality, and an overall mobile-oriented look and feel.

Tailoring the tool to fit the task

In the ever-uncertain future, especially within the AI app development landscape currently taking shape, our approach at Infinum remains – business as usual. We continue utilizing whatever tool best suits the job to develop high-performance, eye-catching applications for clients across various industries.

Resources for learning Flutter

• https://flutter.dev/
• https://www.youtube.com/@flutterdev
• https://flutter.dev/showcase
• https://github.com/flutter/flutter
• https://infinum.com/services/engineering/flutter/
• https://infinum.com/handbook/flutter
• https://pub.dev/publishers/infinum.com/packages
• https://infinum.com/blog/flutter-vs-native/
• https://infinum.com/blog/chatgpt-flutter-app/
• https://infinum.com/blog/charts-in-flutter/
• https://infinum.com/blog/flutter-embedded-device/
• https://infinum.com/blog/flutter-might-be-your-technology-of-choice-for-mobile-in-2020/
• https://infinum.com/blog/flutter-color-schemes

The post Why use Flutter in 2024 appeared first on ShiftMag.

Maximum customizability, data ownership, and prevention of vendor lock-in are the usual benefits of WordPress and are among the main reasons for web development agencies to pick it as their tech of choice.

However, these valid arguments miss two crucial points, according to Krešimir Končić, co-founder of web development and design agency Neuralab. The agency recently participated in WordCamp Europe (one of the many celebrations of WordPress’s 20th birthday) and brought home one of the “Open-Source Champions” awards.

All great reasons to catch Krešimir and hear his opinions on the impact WordPress has had so far, what lies ahead, the ins and outs of creating award-winning open-source communities, and, of course, the opportunities and challenges of open-source software in general.

OS code is rigorously tested across various use cases

The first often missed point, he believes, is that describing WordPress, or any other open-source software, as free is a significant misdirection and undersells its actual value. In his view, the real advantage of a system without hefty perpetual licensing costs is the ability to allocate the entire planned IT budget towards one critical aspect: creating a polished and meaningful user experience. Krešimir emphasized investing in high-quality copywriting, custom user interfaces, content architecture, proper user flows, and any necessary custom frontend or backend code.

In his opinion, open-source projects provide an “architectural peace of mind,” allowing teams to concentrate on user-centric challenges and building solutions that genuinely meet users’ needs.

The second one, Krešimir pointed out that open-source code has undergone rigorous testing across various servers, deployment processes, implementations, agencies, freelancers, enterprises, and volunteers. He believes that this extensive testing and collaboration are something that proprietary software solutions can only dream of achieving:

Take Gutenberg editor, for example – it’s currently written, optimized, and maintained by over 1,060 developers or contributors. That’s a lot of quality assurance eyeballs, and this is the production power of open source.
Clients and investors usually don’t care about this argument, which is ironic because they later always shout, “Hey, our new web admin is awesome. It just works.”

How to build and foster a community?

In 2010, when WordPress’s market share was significantly smaller, Neuralab embraced the platform’s potential. During this era, Neuralab passionately championed WordPress as a viable solution during this formative period. Agencies, product developers, and freelancers, like Neuralab, played pivotal roles in educating clients about the benefits of open-source solutions.

The widespread adoption of WordPress in both enterprise and SMB contexts was essential for attracting meaningful contributors, as projects needing more active contributors often faced abandonment. As time progressed, Neuralab expanded its involvement in the WordPress community by organizing conferences and meetups and hosting a series of WooCommerce and WordPress meetups.

Krešimir also shared his company expertise through lectures on various web development topics, contributing valuable knowledge to the WordPress community.

Winning Automattic’s Open Source Champion award represents a significant achievement for Neuralab.

One notable community-building initiative for Neuralab is their e-commerce podcast, Nominis. Another significant community pillar for Neuralab is its involvement in local WooCommerce meetups. Furthermore, Neuralab actively contributes to the open-source community by regularly publishing essays and columns across various media outlets. They tackle industry-related issues head-on and emphasize self-criticism while advocating for how the broader web community should address civic matters. Accordingly, Krešimir especially points out:

We don’t shy away from problems, so we try to double down on self-criticism and present how the web community should address civic issues. This has piled into a small library of topics, so I’m writing a book titled “Coding is the Easier Part” with a similar tone.

The importance of owning and controlling your data stack

WordPress has undergone significant evolution over the years. When considering the future of WordPress as a content management system and its role within the broader tech ecosystem, Krešimir says it’s an understatement to label WordPress as merely a web-building platform. In his view, the WordPress community plays a pivotal role in shaping and advancing the web industry.

WordPress’s influence is undeniable, with a remarkable content management system (CMS) market share of 65% and an overall web market share of approximately 42%. Krešimir believes WordPress has effectively democratized publishing, enabling individuals and businesses to function as media outlets. Furthermore, he anticipates that WordPress will continue to “democratize creation” as Generative AI models seamlessly integrate into existing content publishing workflows.

Moreover, he points out that the WordPress community has been instrumental in educating the entire market about the importance of actual ownership and control over one’s data stack. WordPress was among the early adopters of integrating privacy controls directly into the native admin experience. While WordPress has made many other contributions to the tech world, Krešimir emphasizes some critical aspects:

Matt Mullenweg famously touted in 2015. that JavaScript is the future of the web and WordPress. He was spot on, as we now observe that JS is running under the hood of most modern applications and tools. This opened the world for headless web projects for React, Angular, Vue, etc. While one could spend endless hours weighing the pros and cons of “headless,” WordPress did impact adding these types of architectures into the web industry.

Boring is cool, innovation has to be meaningful

Looking ahead to the future, Krešimir expressed genuine excitement about the upcoming developments in the Gutenberg block editor. He anticipates the implementation of real-time collaborative editing functionality akin to the features found in Google Docs.

This enhancement promises to revolutionize content creation and collaboration within the WordPress ecosystem. Furthermore, Krešimir highlighted the impending overhaul of the entire WordPress admin interface, which he views as a long-overdue and essential update.

There’s a “but”, of course. The problem with large systems like WordPress is that once they get big enough, they must become stable, robust, and backward compatible:

Every engineer knows that this means less experimentation, which hinders developers, especially those who want to work only on the latest hype.
This is the most significant pain that either PHP or WP endures, and it’s one of the reasons why we as a community need to work on educating both ourselves and the market that “boring is cool” and that innovation needs to be meaningful – and not conducted just for the sake of unquestioningly innovating.

Toxic scorekeeping is not fair, nor realistic

From the point of view of the co-founder of the agency that extensively relies on open-source tools, the most pressing challenge of the OS community today is the question of how to sustainably fund and support open-source projects, ensuring they can continue to evolve and thrive. He framed this challenge as the critical issue of “who will pay for all the pipelines?” – financial resources, human capital, attention, and effort required to advance and maintain open-source code effectively.

From an ideological perspective, Krešimir suggested that the community should contribute back to open source. However, he acknowledged that the practical aspects of how and when to give back can be complex. He referenced Matt Mullenweg’s call for community efforts to allocate “five percent” of their energy toward supporting the system. For instance, if a team consists of a hundred developers, five of them should be consistently dedicated to working on WordPress core issues.

Addressing the challenge of sustainable funding and support for open-source projects, in Krešimir’s view, requires a collective effort from the community to allocate resources and actively contribute to the continued development and maintenance of open-source tools:

The problem is that “toxic scorekeeping” – as some authors have called it – is neither realistic nor fair towards open-source contributors. Take Neuralab, for example. We don’t allocate developers to work on WordPress core, BUT we assign developers to work on various integrations and modules that give rise to the whole ecosystem.

Our PM team is working tirelessly on meetups, working with clients, and educating the market – so how do you measure the value of this?

All in all, the problem of budgeting for open source software is one the most pressing concerns for modern society – as you currently have a tremendously extensive IT system that will fall apart unless Jeremy from Ding Dong (Texas) pushes a bug fix on his popular open-source JavaScript library.

Open-source software as a public good

He proposed that society should begin viewing open source projects as public goods, akin to essential infrastructure such as roads, trees, and water. While these public goods are often taken for granted, governments and non-governmental organizations (NGOs) actively manage, fund, and maintain them. Krešimir emphasized that a similar mindset should apply to open-source software to some extent.

This would involve recognizing the importance of these projects to the broader community and providing the necessary resources and support to ensure their sustainability. Secondly, Krešimir highlighted an issue related to budgeting and resource allocation within the open-source community. He mentioned that he closely monitors the Ethereum community’s approaches, particularly quadratic funding and Gitcoin grants, as potential solutions to this problem.

These mechanisms can serve as realistic budgeting tools for future open-source software endeavors. By leveraging these innovative funding models, open-source projects can secure the resources needed to continue development and maintenance while maintaining a fair and decentralized approach to support.

Terraform was sloppy and dishonest

Commenting on the recent controversy surrounding Terraform’s license change, Krešimir highlights that there are alternative strategies if the goal is to limit direct competitors and their commercial use cases. He pointed to Meta’s approach with Llama 2, a large language model, where they chose to open source it while requiring a special license from Meta if the model is used in an application with more than 700 million monthly users. This approach balances open-sourcing the technology and protecting against certain commercial use cases.

The lessons from such incidents revolve around carefully considering licensing strategies that align with the project’s goals and target audience. Open-source software creators should assess their options to protect intellectual property while embracing open-source development’s collaborative and community-driven nature.

The Terraform issue was a sloppy planning operation and a dishonest messaging case. Unity had the same problems, which they corrected based on the massive community outburst. Marc Whitten (Unity Create lead) wrote an apologetic letter toward the ecosystem and offered more granulated and thought-out license distinctions.

Unity crew even provided a calculator for estimating the tooling cost of your project’s success. Other OS projects could pick up this Unity story and learn from it – avoiding future licensing community fires.

Security and reliability: Open-source beats proprietary

In addressing concerns about security and reliability when using WordPress for client projects, Krešimir highlighted the inherent advantages of large open-source projects, which benefit from a vast global community of contributors, providing a high level of quality assurance.

All investors want to make their project as future-proof as possible, but here’s the thing – open source beats proprietary software at this game by a long shot:

Think about it: the worst end-game scenario of using open-source software is that you need to fork it.

The worst end-game scenario of using proprietary software is that you’re de-platformed and need to do a complete project overhaul. And all that on someone else’s dictated timeline.

The post On open-source as a public good, licensing missteps, and community building appeared first on ShiftMag.