When Meta releases Llama under restricted commercial terms, or Mistral ships weights under a non-OSI-compliant licence, are these truly “open source” models? The OSI’s Model Openness Framework attempts to answer this definitively, requiring openness across training data, model architecture code, and weights. Few models today meet all three criteria simultaneously.
The tension is real. Fully open training data raises copyright and bias concerns. Open weights enable misuse at scale. And yet without openness, the concentration of AI capability in a handful of labs creates exactly the kind of power asymmetry that the open source movement was founded to resist.
Those of us who built careers on the democratising power of FOSS — deploying Sahana to coordinate disaster relief, advocating for OLPC, championing government software built in the open — have a particular stake in this debate. The humanitarian stakes of AI are at least as high as any software we have deployed before.
Open source AI models should meet the same bar we set for any open source software:
For organisations that cannot yet contribute to fully open foundation models, InnerSource offers a critical bridge: applying open source culture — contribution norms, transparent roadmaps, meritocratic governance — within an enterprise boundary. This is the model I have been building at Citi, and it scales naturally to AI development teams who need deep internal collaboration without full public openness.
The FINOS InnerSource SIG has been mapping exactly these patterns for financial services, where regulatory constraints make full openness complex but internal AI collaboration is essential.
The next frontier is ensuring that the open source AI ecosystem does not calcify into a two-tier system: fully open models for academic research, and locked proprietary models for production use. We have seen that story before — proprietary vs open source in operating systems, databases, web infrastructure — and we know how it ends when the community stays organised and principled.
The open source community built the infrastructure the internet runs on. There is every reason to believe we can do the same for AI, if we insist on our principles now, before the defaults are set.
]]>The FINOS AI Governance Framework (AIGF) is an open-source, community-built response to this gap. I joined the project as a maintainer alongside colleagues from Scott Logic, ControlPlane, Morgan Stanley, and NatWest — bringing a practitioner lens shaped by my work as DevOps Product Owner and InnerSource Lead at Citi UK.
The AIGF is not a set of principles printed on a poster. It is an operational framework: a use-case-driven methodology that characterises risk based on system architecture, applies structured threat modelling to identify failure modes, and maps those threats to concrete mitigations and controls. The output is something a risk manager, a developer, and a regulator can all read and act on.
The framework is deliberately scoped. Rather than attempting to govern all of AI simultaneously, it picks specific use cases — code generation, document summarisation, RAG-based search, agentic workflows — and works through each one systematically. This makes it tractable and keeps the outputs tied to real deployment decisions rather than abstract policy.
The instinct in financial services is to build proprietary governance frameworks in isolation. Every institution invents its own risk taxonomy, its own approval checklist, its own model inventory schema. The result is enormous duplication of effort, inconsistency across the industry, and a race to the regulatory minimum rather than to actual safety.
Open-sourcing this work under a Creative Commons licence means that the best thinking from across the industry compounds rather than siloes. A mitigation pattern proven at one bank can be reviewed, stress-tested, and adopted by others. Regulators benefit from seeing a common vocabulary emerge. Practitioners benefit from not having to build from scratch.
This is exactly the InnerSource argument applied at industry scale — and it is why FINOS is the right home for the project.
My focus within the AIGF has been threefold:
Regulatory alignment. Financial services AI governance does not exist in a vacuum. SR 11-7 model risk management guidance, SR 26-2 on AI/ML systems, the EU AI Act, and DORA all impose overlapping obligations. I have been working to ensure the AIGF’s use-case taxonomy includes the metadata needed to answer the practical question every bank must answer: does this system require full Model Risk Management treatment, and if so, at what validation tier?
ROI and adoption. A governance framework that nobody deploys is worthless. I have been developing a structured ROI model that translates AIGF adoption into measurable business value — reduced time-to-approval for lower-risk use cases, lower incident remediation costs, improved auditability — so that CTO offices and AI leadership can make the case internally.
Agentic tooling. I have been advocating for an AIGF MCP server that allows institutions to use agent-assisted workflows to generate a customised governance framework — one that respects their existing risk infrastructure rather than overwriting it. More on this in a separate post.
The AIGF sits at the intersection of three things I have spent my career on: open source community governance, enterprise-scale risk management, and the ethics of technology deployment. The question of how we govern AI is not primarily a technical question. It is a question about values, accountability, and who bears the cost when things go wrong.
Getting this right matters — for the institutions deploying AI, for the customers whose data and decisions are affected, and for the broader project of ensuring that AI development remains accountable to human judgment.
The framework is incubating at FINOS and actively welcoming contributors. If you work in financial services AI, risk, or compliance — or if you care about open governance of AI systems — I would encourage you to engage.
]]>Get the answer wrong in one direction and you smother low-risk productivity tools under years of validation burden. Get it wrong in the other direction and a material AI system influencing credit decisions or market risk estimates slips through without the independent review the Federal Reserve expects. Neither outcome is acceptable — and yet, without a structured classification approach, most institutions are making this call case-by-case, inconsistently, under time pressure.
I have been working within the FINOS AI Governance Framework to address this with a use-case taxonomy that includes the metadata fields needed to make this determination systematically.
SR 11-7 was published in 2011, when “model” meant a statistical model: a quantitative method with inputs, outputs, and a mathematical relationship that could be validated by a qualified independent party. It was written for VaR models, credit scorecards, and CCAR stress testing — not for large language models, RAG pipelines, or agentic systems that generate free-text outputs from opaque embeddings.
SR 26-2, issued more recently, begins to update this picture, extending model risk management expectations explicitly to AI and ML systems. But it does not resolve the threshold question: which AI use cases are “models” for SR 11-7 purposes, and which are tools?
The answer depends on how a system influences decisions — and on how material those decisions are.
Rather than attempting to define “model” more precisely in the abstract, the AIGF use-case taxonomy classifies each use case along four axes:
SR 11-7 Applicability — Not Applicable / Limited / Moderate / High. This captures the degree to which the system’s outputs directly influence quantitative analysis, risk assessment, or regulatory reporting. A code generation assistant is typically Not Applicable. A system that produces risk summaries used in credit committee decisions is Moderate or High.
Decision Influence Mode — Informational Only / Human In The Loop / Human On The Loop / Autonomous. This reflects how much human oversight stands between the AI’s output and a consequential action. Autonomous systems — where AI initiates actions without pre-approval — carry the highest governance burden regardless of their stated purpose.
Materiality Tier — Low / Moderate / High / Critical. This captures the potential financial, reputational, or regulatory impact if the system fails or produces systematically biased outputs.
Validation Tier — Basic / Standard / Enhanced / Full MRM. This is the output: the level of independent validation and ongoing monitoring the system requires, derived from the three inputs above.
The paradox of good governance in AI is that not having it is usually slower than having it. Without a taxonomy like this, every new AI use case goes to a risk committee that must invent its assessment from scratch. With it, lower-risk use cases (code assistants, internal search, document summarisation without decision influence) can be approved quickly against a pre-agreed standard — freeing governance capacity for the high-Materiality, Autonomous systems that genuinely need Full MRM treatment.
This is the argument I have been making in the context of the AIGF’s ROI model as well: structured governance is not the enemy of AI adoption. It is the precondition for sustainable adoption at scale.
The classification metadata is currently being developed as a proposal within the FINOS AIGF community. The next step is crosswalking it against the use cases already documented in the framework to validate that the taxonomy produces consistent, defensible outputs — and then socialising it with regulatory contacts and peer institutions through the FINOS community process.
If you have views on SR 11-7 applicability thresholds, or experience applying MRM governance to generative AI systems in practice, I would welcome the conversation.
]]>The programme deepened my work on Generative AI projects and Open Source AI initiatives, in particular the FINOS AI Governance Framework — an effort I am proud to maintain alongside a remarkable cross-institutional community.
What I carry forward from this experience goes beyond technical skill. In the GenAI era, sound judgement and delivering sustainable solutions that provide a net positive impact matter as much as any model architecture or platform choice. Perhaps more.
My thanks to Anthony Warden, Ramkumar Ayyadurai, Daniel Jepp, Miriam Silver, and the many colleagues across multiple regions who gave generously of their time, guidance, and trust.
#EngineeringExcellence #Citi #Innovation #Mentorship #CareerDevelopment #ResponsibleAI
]]>Every major bank has a Model Risk Management function, a Technology Risk team, an AI Centre of Excellence, and at least one half-finished AI governance initiative of their own. They have existing risk taxonomies, approval workflows, and vendor assessment questionnaires that took years and significant internal capital to build. Asking them to replace all of this with a new open-source framework is not adoption — it is replacement. And replacement almost never happens.
This is why I proposed an MCP server for the FINOS AI Governance Framework — an agent-assisted approach that generates a customised governance framework by combining AIGF’s deterministic building blocks with an institution’s existing governance components.
Model Context Protocol (MCP) is an open standard for connecting AI systems to external tools and data sources. An AIGF MCP server exposes the framework’s content — its use-case taxonomy, threat models, risk characterisation methodology, control mappings, and regulatory crosswalks — as structured, queryable resources that an AI agent can reason over.
With an MCP server in place, an institution’s governance team can run an agent-assisted workflow that:
The output is not a generic copy of the AIGF. It is a bespoke document — ready for human review and adaptation — that shows exactly which AIGF controls the institution is already meeting, which it needs to add, and which it may reasonably defer given its risk profile and regulatory context.
The proposal is explicit that human review is required before any recommendations are acted upon. This is not a disclaimer — it is architecturally important. AI governance frameworks deal with consequential decisions: which systems require independent validation, which AI outputs can be acted on autonomously, which third-party models are permissible. These decisions carry regulatory and reputational weight. The agent’s output is a first draft and a structured prompt for human judgment, not a substitute for it.
This mirrors the governance principle I have been advocating within the AIGF more broadly: AI systems in high-stakes domains should be designed with human on the loop, not human out of the loop. The MCP server workflow is itself an instance of the governance model it helps produce.
The MCP server proposal is, at its core, an argument about how open-source governance tooling should relate to enterprise adoption. The alternative to customisation is compliance theatre: institutions nominally adopting a framework while quietly ignoring the parts that conflict with their existing processes. Customisation — done transparently, with audit trail — produces genuine adoption and genuine improvement in governance quality.
It also demonstrates something I find compelling about the current moment in AI tooling: the best use of AI agents is not to replace human expertise but to make expert knowledge more accessible. The AIGF represents hundreds of hours of cross-institutional expertise on AI risk in financial services. An MCP server makes that expertise queryable and actionable for practitioners who need it — at the speed their deployment timelines demand.
This is the direction I want to see open-source AI governance move: not documents that sit in repositories, but living frameworks that integrate into the places where governance decisions are actually made.
]]>The talk sets out to answer one of the questions I am most frequently asked when advocating for InnerSource inside a regulated financial institution: how do you actually prove it is worth it?
The honest answer, for most organisations, is that they cannot — not yet. They have intuitions and anecdotes. They know that reusing a shared library saved a team weeks of work, or that a cross-team contribution improved a platform that five squads depend on. But they lack the consistent measurement infrastructure to turn those observations into numbers that a CFO or CRO will act on.
That is the gap this framework is designed to close.
The framework defines four key areas where InnerSource generates measurable business value:
1. Cost savings through code reuse. When an engineering team consumes an InnerSource component rather than building equivalent functionality from scratch, the cost delta is real and quantifiable. Automated tooling — dependency graph analysis, contribution telemetry — captures this at scale across the breadth of an organisation’s inner ecosystem.
2. Time-to-market improvement. InnerSource accelerates delivery by reducing the duplication of effort. Teams that contribute to shared platforms rather than maintaining private forks converge on faster release cycles. This is tracked through lead time metrics aligned with DORA, adjusted for the cross-team contribution patterns specific to InnerSource.
3. Maintenance cost reduction. Fragmentation is expensive. Every private fork is a support burden; every undiscoverable internal library that gets rebuilt is waste. InnerSource, when properly instrumented, collapses that fragmentation and reduces the long-tail maintenance cost that accumulates invisibly across engineering organisations.
4. Engineering health. The dimension hardest to capture in a spreadsheet but perhaps most important for talent retention and platform quality: the degree to which InnerSource practices — open contribution norms, public roadmaps, meritocratic governance — improve how engineers experience their work. Survey instruments calibrated against contribution activity data give this dimension the rigour it deserves.
Across all four dimensions, we combine three measurement modalities: automated tools that extract signals from version control, dependency management, and CI/CD systems; structured surveys that capture what tooling cannot see; and analytical models that translate raw signals into business-relevant numbers.
The goal is not a metrics dashboard for its own sake. It is to produce actionable insights that engineering and business leaders can use to decide where to invest in InnerSource infrastructure, which components warrant the governance overhead of formal InnerSource programmes, and how to communicate ROI to stakeholders who are not close to the engineering culture.
This presentation builds directly on the FINOS InnerSource Value Metrics White Paper that I co-produced through the FINOS InnerSource Special Interest Group — a cross-institutional effort drawing on practitioners from financial services firms navigating the same measurement challenges.
]]>Reference to Magdalen Means Business Website: https://magdalenmeansbusiness.magd.ox.ac.uk/power-of-software/
]]>Abstract:
COVID-19 lockdowns caused fossil carbon dioxide emissions to decline by an estimated 2.4 billion tonnes in 2020, as reported by the data in the Earth Systems Journal. Whether this was Mother Earth’s way of intervening and saving us from a larger calamity might never be known. The pandemic and global warming alike are crises that will continue if we do not work together globally. Without cooperation, new strains will soon develop, and our locked down environment will continue in the rapid onset of disaster.
In a similar way, businesses have to work in unison to enact change and address Environment, Social and Governance (ESG) issues. But unlike COVID, root causes are hard to trace precisely, and will instead show up in an increase in flooding, famine and fires. We all know that the continuation of economic development without concern for ESG issues will only negatively impact the communities and planet we live in. All the wealth accumulated will have even less of an impact on happiness and stability.
Whilst groups such as Greenpeace and Extinction Rebellion’s brave and yet drastic measures might cause headlines, driving a global ESG and responsible investing program might be a more structured and profitable way towards the same goals. This is because even if you abhor any form of tree hugging, investing in ESG can actually result in many traditional business advantages from lowered total cost of operations (TCO) as well as improved scalability, employee morale, and stakeholder engagement. In this article, we hope to explain the many no-brainer business benefits of aligning to ESG.
Read full article here: https://oxfordbusinessreview.org/gaining-a-business-advantage-by-aligning-to-esg/
]]>ICT is increasingly playing a larger part in lubricating the democratic process and has tremendous potential to further enhance it. However much has also been said about the exploitation of software such as Facebook and Twitter to spread fake news and negatively deviate the public opinion of an electorate. We sometimes lose sight of the tremendous good software can provide to improve transparency, bridge communities and bring more power to the people. Unfortunately, software is complex for the lay voter, so how do we make sure it does the right thing and has no “Wizard of Oz” behind the scenes pulling the levers of bias?
In this article I hope to explain that a software development paradigm that has its origins in freedom and giving more power and rights to software users (aka ‘the people’) is also conceptually aligned with building our government systems in a democratic nation or republic.
This software is called Free and Open Source Software (or FOSS or Open Source for short), where Free stands for Freedom and its examples include popular browsers like Firefox, Operating Systems such as Linux and free online encyclopaedia Wikipedia. Firefox might not be your preferred choice for a browser and you might be using Chrome or Internet explorer, however there is a big difference in how Firefox is built. While the other two browsers are built by companies such as Microsoft and Google who have the final say, Firefox is built by a diverse community of volunteers and while the aspiration of the former two companies is to make a profit, the motive of the Mozilla Foundation which coordinates Firefox is to protect your privacy and to make sure the Internet is kept free. So if privacy and protection of your rights is your priority, then I recommend you go with Open Source Firefox.
To pick an acute example in Government, if there is any software that should go through similar scrutiny in a democratic nation it is election management software. No bias should be introduced into the election process and that includes the software which runs it, lest it be accused of playing a role in king-making.
Such software should not belong to one company; it cannot be opaque on how it works and it should be built by a representative diversity of people representing the electorate. Such is not possible with popular software that you getfrom companies such as Facebook, Twitter, Microsoft or Apple. Such software should adhere to three principles of the title above that I slightly modified from the famous Gettysburg quote by Abraham Lincoln.
Principle 1: Software (Owned) of the people
While most software in the world that you are used to such as Microsoft Office belongs to one company (you never own it, instead you lease it), who decides how the software should work. The software which runs Government policy adn the election process should ideally belong to the people. Any citizen of a nation where it is being used should be able to get a copy of the code and analyse it or get someone to analyse it on their behalf. For them to do this freely they need to have ownership of the software for free. Open Source software is built on the premise of using copyright law to make sure that all users have the right to get the software code and inspect it freely by law. Anyway Government software is ultimately built with Tax payers money so it should be a public good and you should have every right to inspect it.
Principle 2: Software (Built) by the people
This software cannot be built by one company, one ethnic group or one political party. Rather, it has to be built by a diverse group of interested parties. Any citizen who has the required software development skills should be welcome to participate in its development as a public service. The entire process of decision-makers should be very transparent so any biases are removed, if they get introduced intentionally (or unintentionally, as often is the case).
Open Source welcomes open participation, but one problem is that opening up so largely leads to analysis-paralysis which occurs when there are too many decision-makers (or naysayers) and less actual doers. This is the political equivalent of a hung Parliament. Instead, what has proven to work time and again in Open Source is a meritocracy of doers. In other words, everyone is welcome to participate but those who contribute the most get greater power to make decisions. IMO Fair enough as it still does not let us take away the right to audit the result.
Principle 3: For the people
The entire electorate should be invited to test the software if they wish to make sure it is suitable for their understanding of what a democracy should be. They should be welcome to provide feedback as users and be able to review the decisions made transparently. Only through this public trial and review will trust in the software be built.
Open Source makes the users (or Citizans) a valued part of the community and your inspection here does not have to be at a skin-deep level. You (or a developer you trust) have every legal right without asking for permission to take it apart and inspect it for anything you are unhappy with and recommend and contribute alternative approachs.
Free and Open Source software and the foundations that operate them follow the principles above and though the exact process by which the Open Source software is governed might vary slightly, it is by far better, more transparent and much more auditable by the public than proprietary software.
Security not through Obscurity
Many might come to an opinion that exposing the source code and working of such election software will make it vulnerable to hacking. Whilst that might be the case with a physical safe, this is not the case with software as just as there are people who can find hacks, there are also many who can participate and contribute a patch to address that vulnerability immidiately (unlike a safe). This is one key reason the Open Source Linux operating system and BSD Operating System are the most secure Operating Systems in comparison to their proprietary counterparts.
Governance of software for Governance
The exact governance model for Open Source varies through at the end of the day the end-result is transparently auditable by copyright law. On one side of the spectrum are commercial open source models for companies like RedHat/IBM/Google/AWS and on the other is the pure community oriented meritocracies such as the one run by Debian and Apache.
The latter is more aligned to Gov Software as it has a lot more transparency where decisions are voted on and documented transparently and includes deciding the annual leader, electing sub-commitees, on the roadmap, new polices, design and all the way down to what specific lines of code go into the product, but all these decisions are made a lot faster digitally.
In Summary
Free and Open Source Software has it’s root in Freedom and is naturally aligned for the development of Goverment software, partiularly that which run the election and policy making process. With such software all Citizens have certain inalienable freedoms protect by (Copyright) law to ensure there is no bias and to improve trust. You find suprising parallels to democratic processes in how such Open Source global communities like Apache and Debain run, but decisions here are made a lot faster digitally. One wonders weather we can make Government itself run a lot more effeciently as a Open Source project :-)
References
Defintion of the Four Freedoms of Free and Open Source Software https://en.wikipedia.org/wiki/Free_software#Definition_and_the_Four_Freedoms
A specific version fo this was published to the Financial Times http://www.ft.lk/columns/Software-owned-of-the-people-built-by-the-people-for-the-people/4-695920
]]>Marvim was my attempt to fix that.
Marvim is a Vim plugin that gives macros and visual templates a persistent home outside the editor. You can save any macro or yanked template to a named repository, retrieve it later with auto-complete search, and organise entries by namespace — either manually or automatically by filetype.
The interface is deliberately minimal:
That is the full surface area. The storage is plain files on disk, which means the repository is portable: you can version it, copy it across machines, or share it with a team via a mounted network path or a dotfiles repository.
Every macro is stored under a namespace. By default Marvim uses the current filetype as the namespace — so a macro saved while editing a Python file lives under python/, and a macro saved in a Vimscript buffer lives under vim/. You can also specify any prefix you want, which makes it straightforward to organise by project, task type, or team.
The recursive directory search means you can nest namespaces as deeply as you like and still find what you need with a partial name match and Tab completion.
The feature I find most useful in a team setting is the shared repository. You can point Marvim at a shared network location or a directory inside a shared dotfiles repo, and the whole team gets access to the same macro library. Common transformations — reformatting log output, extracting fields from structured text, refactoring boilerplate — become shared institutional knowledge rather than living in one person’s head.
Marvim works with Vim 7+, Vim 8+, and Neovim. Installation via Vundle:
Plugin 'chamindra/marvim'
Or via Pathogen by cloning into ~/.vim/bundle/marvim.
To customise the storage location and hotkeys before the plugin loads:
let marvim_store = '/path/to/your/macro/store'
let marvim_find_key = '<F2>'
let marvim_store_key = '<F3>'
The v0.5 Beta (September 2019) refactored the internals for Vim 8 compatibility and added proper help files and a markdown README. Earlier versions (0.1–0.4, 2008) established the core feature set: Windows compatibility, recursive lookup, GUI menu support, filetype namespaces, and auto-complete navigation.
I wrote the first version of Marvim in early 2008 during a period when I was spending most of my working hours in Vim editing large codebases and configuration files across multiple languages. The recurring frustration was not the recording of macros — that part Vim does beautifully — but the forgetting. Complex macros that took several attempts to get right would disappear, and rebuilding them from scratch days later was exactly the kind of friction that makes tools feel fragile rather than trustworthy.
The macro-as-file model also opened up composition: because each macro is just a text file, you can inspect it, edit it directly, and share it as you would any other resource. It fits naturally with how I think about open tools — transparent, portable, inspectable.
Marvim has been downloaded over 4,600 times from the Vim scripts repository and carries a rating of 163 across 53 reviewers. For a small utility plugin written to scratch a personal itch, that uptake has been gratifying — and a reminder that friction in a frequently used tool is worth taking the time to remove.
The source is on GitHub and the plugin is listed on Vim.org.
]]>