Open source in a company panel. The licence is free, upkeep is not
Author:
Paweł Matusiak
·
Most B2B panels and CRMs sit on open-source libraries nobody in the firm wrote. The licence often costs nothing to download. The bill arrives later: at an update, an abandoned package, or a copyleft licence in code handed to a customer. The useful claim is narrow — open source as material for commodity layers, with a dependency list and an owner inside the firm.
A B2B panel, a CRM and a job register all contain code nobody in the firm wrote from scratch. A framework, a database, a PDF library, an HTTP client. That is open source. The licence often costs nothing to download.
After installation a different question remains. Who in the firm knows which packages went into the panel, under which licence, and who will update them when the author stops answering issues.
Open source in business software makes sense as material for layers that are not worth writing in-house. It stops making sense when a package is treated as a finished purchase: wired in, working, closed. Then free code becomes expensive at the next rebate rule, the next upgrade, a contract with a customer, or a security fix.
What a firm actually has in the panel when it says “open source”
In a conversation with the board, open source is often a synonym for “free”. In the code it means something narrower. The program has a public licence, the source can be read, and usually copied and changed on that licence’s terms. It does not mean someone will maintain it for ever. It does not mean it may be dropped into every product and handed to every customer.
A typical order panel is not an island. Underneath sit a language, a framework, a server, a database and a set of libraries for login, mail, export and integration. Some of that is a commodity layer: it does the same job in many firms and is not a source of advantage. There, open code is a rational starting point. Advantage sits higher up — in the individual price list, in the complaints flow, in how a salesperson confirms stock.
Dependence on other people’s code does not start on the day someone announces an “open-source strategy”. It starts at the first install. Someone scaffolds a project, adds packages, copies a snippet from the documentation. Two years later nobody remembers which libraries came in “for a moment”. The dependency list exists in a lockfile. It often does not exist in the head of the person accountable for the panel.
That is why the quarrel “open code or closed software” is badly framed for most small and mid-sized firms. The question that can actually be handled is different: which layers we buy as a product, which we write ourselves, and which we take from a package registry — and who in the firm owns that choice.
When a salesperson opens a customer card, they are not thinking about a library licence. They are thinking whether the price on screen is the one in the annex. If the panel lies or hangs, the problem is commercial. The source is often technical: a package for price rules that nobody has touched since two framework releases ago. The framework the panel sits on is itself usually open. A separate discussion of when that stack makes sense in a business application is about choosing a tool. This piece is about something earlier: whether the firm even knows what was added to the stack.
Example: a fittings wholesaler and a panel nobody inventories
Picture a regional wholesaler of industrial fittings. A dozen people in sales, a warehouse by the hall, standing contracts with installers and several price lists that depend on volume. This is an example, not a GESOFT client. A typical situation in which a B2B panel grew faster than any record of what sits inside it.
The panel was built when a spreadsheet of individual rebates stopped adding up. A salesperson in the field needed the same price the office sees on the invoice. The order was meant to go from a phone. Stock — from the warehouse, not from memory.
Further packages went into the panel. A PDF generator for quotations. A library for payments on prepaid orders. A chart module for the owner’s report. Some were added by a staff programmer, some by a firm that built a “quick screen for the quarter”. After those jobs nobody wrote down what remained in the project.
The jam appears at a new rebate rule. The owner wants a threshold on basket value in a chosen range, not on the whole order. The programmer says the framework version must be raised first, because the current one no longer receives patches. The upgrade breaks the PDF generator and the payment helper. The latter has had no release in a long time. The owner’s report sits on a library whose licence, if the code is handed on, does not match the rest of the stack.
In this story a “switch to something closed” in a week does not help. A dependency register does: owner, licence, date of last update. And a decision on which packages stay, which are replaced, and which should not be in a panel sold onwards. An abandoned package for payments will not disappear on its own. Either the firm takes on its upkeep, or it replaces it before the next framework patch stops quotations again.
A shared list that can be opened without digging in the repository saves an argument between the warehouse, sales and the one person who knows how to bump package versions. The salesperson is still working out the rebate in a sheet beside the panel. The warehouse issues stock against a different figure than the office puts on the invoice. Nobody that day cares about the ideology of open code. They care about the quotation, the stock figure and the invoice.
The licence is not a formality when you sell or install at a customer
An open-source licence is not a footer ornament. It says what may be done with the code: use it inside the firm, change it, combine it with your own program, hand it to a customer, publish changes. A permissive licence — typical examples are MIT and Apache — leaves the firm a great deal of freedom, including building a closed panel on top of the library. A copyleft licence — GPL, often AGPL as well — requires, for certain forms of distribution, that the recipient be given the same freedoms in the code.
This is where practice starts, not theory. A panel that runs only on the firm’s server is a different case from a panel installed at a customer or offered in a way that lets the code be downloaded. AGPL is often read more strictly for network software. That does not replace legal advice on a concrete matter. It replaces silence: if nobody opened the LICENSE file, the firm does not know what it is standing on.
In the wholesaler example a subcontractor added the report chart because it looked quick. If that library is copyleft, and the firm plans to sell the panel to another branch or a partner, the licence question returns at the contract, not at the commit. The fix then takes longer than the chart itself.
Some libraries have a dual model: copyleft or a paid commercial licence. The subcontractor takes what is visible in the public repository. The firm may be using the package on terms it would not have accepted in a purchase. The word “free” in a description is not a buying decision. There are also source-available licences that forbid commercial use, and add-ons that are free only up to a given scale.
Good practice is dull. For every new package someone checks the licence, records it next to the name and version, and knows whether the package stays inside the system or may leak in a distribution. The firm does the same when it checks whether a product photograph may be used in a quotation.
- package name and the exact version that runs in production
- licence, and whether it applies to code handed to a customer or only to the firm’s server
- the person or role accountable for updates
- date of the last version bump, and the reason if the package is left untouched
The software supply chain: lockfile, updates, trust in the registry
Code from a package registry arrives over the internet. The firm trusts the name, the publisher’s signature, the registry server and the assumption that nobody swapped the file along the way. The software supply chain is that path: from the author, through the registry, the package manager, the lockfile, the firm’s server, to the salesperson’s screen.
A lockfile — composer.lock, package-lock.json and their counterparts — records which exact version went into the panel. Without it, “the same install” six months later may fetch something else. With it, the environment can be rebuilt and a new programmer, or someone from an audit, can be told what actually runs in production.
An update is a decision, not a reflex. Holding it back leaves known holes. Raising versions blindly on a Friday breaks the panel before the order peak. A sensible rhythm is simple to describe and hard to keep when nobody owns the list.
- Someone reads a vulnerability notice or a changelog and checks whether the package name is in the production lockfile.
- The update goes first onto a copy of the panel. Login, quotation, PDF and prepaid payment are tested there.
- The production release falls outside the order peak, not on a Friday afternoon before stocktaking.
- The register keeps a record: what was raised, when, and who signed it off.
For layers that login and payment depend on, that rhythm is part of application security, not “tidying the code”. An abandoned package is worse than an old one. An old one still gets patches. An abandoned one leaves the firm with a choice: stay on a dead version, take on maintenance, or rewrite a slice of the panel.
In the wholesaler example the payment helper has had no release in a long time. An argument about the idea of open code does not help. What is missing is an owner on the firm’s side and a plan B. When the only person who can bump package versions finished the job months earlier, a vulnerability notice waits in an inbox and the panel stays on the old version.
A supply-chain attack does not require the firm to be a named target. A similarly named package, a hijacked maintainer account or a malicious script in a dependency of a dependency is enough. The installer fetches from a public registry. If nobody watches the name and pins the version, something nobody ordered enters the panel. A PHP application security audit in that situation starts from a list of what is in the project at all, not from slogans on a slide.
When an update fails in production, the salesperson rings to say the panel will not come up. A better signal arrives earlier: monitoring of login and order-save responses, before the first quotation comes back with an error. The lockfile is still needed. Monitoring buys time to roll back before the warehouse starts issuing stock “on a nod”.
The community is not a support desk with a contract
The community around a library is usually a handful of people, often after hours, plus users who file bugs. While the project lives, the firm gets patches more cheaply than by writing everything itself. When the maintainer vanishes, community dependence becomes an operational risk. Nobody is obliged to pick up the phone on a Saturday.
So choosing a package is not only about whether it works in a demo. It is about whether there are regular releases, whether someone answers issues, whether the project has more than one maintainer, and whether it can be replaced with another library. A dependency owner inside the firm — a person or a role, not “IT in general” — is needed even for a well-maintained library. Someone has to say: we update this package this quarter; we leave that one, because it is on the way out.
Upkeep of open code in a company panel is work. Reading changelogs, a test after the update, sometimes a patch the author has not yet accepted. The cost of that work is real. It can still be lower than the cost of writing and maintaining your own PDF generator or HTTP client. The comparison only makes sense when both sides of the ledger are visible. “Free” without a programmer’s hours is an incomplete bill.
A fork, a private copy of an abandoned library, sounds like control. For a small document generator it may be a weekend. For a payment helper it becomes a second product the firm did not want to sell. A small team rarely keeps such a fork alive past the next change at the payment gateway. Plan B should assume replacement, not heroic maintenance of someone else’s code.
Some firms buy commercial support for a chosen open-source layer: the operating system, the database, sometimes the framework. There is no contradiction in that. The firm admits that on that layer someone needs to take a ticket. On a chart library, usually not. On the database that holds the orders — often yes. The wholesaler in the example may have a contract on the database and still a mess in JavaScript packages. The database contract does not tidy the register.
Where free code bites the margin: rebate, stock, invoice
The wholesaler’s salesperson does not lose a day to licence philosophy. They lose it when the panel will not calculate a rebate threshold and the customer is waiting at the gate for a quotation. Then the spreadsheet returns beside the system. The price in the sheet and the price in the panel drift apart within a week. The warehouse issues goods against one stock figure; the office invoices against another.
The total cost of ownership of a free library is not zero. It is the time of the person who can update it, the risk of downtime, the cost of replacing an abandoned package, sometimes the cost of advice on copyleft. The saving sits elsewhere: the firm does not pay to invent from scratch things that do not distinguish it from competitors.
The margin disappears quietly. Not on a licence invoice, but in hours of manual recalculation and in a credit note that appears after delivery. When the only person who can bump package versions is on leave, a security update waits. That is a cost as well. It has no separate line in the books.
There is another cost, visible at the customer, not in the repository. The owner wanted a handsome chart in the report. The package pulled a heavy library into the browser. The salesperson on the installer’s shop floor, on a weak link, waits for the quotation to render. A feature nobody needs in the field slows the one everybody needs: price and stock. Dependence on the owner’s report eats the salesperson’s day.
A panel of one’s own can still be the right path when price lists are individual and an off-the-shelf program cannot handle thresholds, stock reservation and an invoice from the same order. Whether ready-made software stops adding up is decided by the process, not by a fashion for open code. Open source is then the panel’s building material. It does not replace the decision on whether a panel is needed at all.
A closed stack and code written from scratch. The counter-argument
The strong counter-argument is this: better to buy a closed stack with a contract, or write the critical pieces from scratch. Then there is an address, an invoice and someone to call when the system falls over. In-house code and closed software give a sense of control. For some layers that sense is justified.
A firm is entitled to want a contract with a response time, a backup written into the agreement, and a person who will take a ticket on Saturday. Open code does not provide that by itself. It provides source and a licence. The rest has to be organised: hosting, a view of whether the panel is up, someone on call, a restore procedure. The absence of that rest is not a defect in the MIT licence. It is a gap in the organisation.
Control in the style of “we will write everything ourselves” is still an illusion in a typical B2B panel. The framework, the operating system, the database, the encryption libraries, the drivers — they will still be someone else’s, and usually open. A firm that “does not want open source” still has it, only without a list. Rewriting the framework is not a strategy for a wholesaler of a dozen people. Buying a commercial reporting engine or a map product may be, if that layer is critical and the vendor actually maintains the product.
A large customer is often stricter than the in-house programmer. A security questionnaire asks for a list of components, for how updates are done, for who owns vulnerabilities. Without a register the sales director writes a generality or “not applicable”. The contract conversation then stalls, even though rebate and stock in the panel still work. A closed vendor sometimes supplies that list in the pack. On an open stack the list has to be made in-house. That is an argument for discipline, not automatically for replacing the whole panel.
The limit of the approach proposed here is plain. A dependency register, a lockfile and an update rhythm will not replace a hosting contract. They will not replace a backup. They will not bring an abandoned library back to life. They will not make a small team able to maintain a fork of a large package. The approach works when the firm agrees to keep few dependencies and to replace those it cannot handle. It does not work when the panel is a collage of tutorial screens and “we will see later”.
There are also places where a closed component is simply more reasonable. A payment gateway with certificates, a map with a geocoding contract, a document engine the vendor updates for the rules. Open source is not an ideological duty. It is a tool. Where the tool has no maintainer and the cost of a mistake is high, one pays for a product with a contract.
Spreadsheet, off-the-shelf program, or a panel with an open package list
Not every problem needs an application of one’s own. A few dozen lines and one price list will live in a spreadsheet if one person watches it and nobody keeps a second, “truer” copy on a phone. A standard booking, a standard invoice, a standard warehouse — an off-the-shelf program on a subscription is often cheaper to keep than one’s own code, even if that code sits on free libraries.
A panel of one’s own is justified when the process is unusual: individual price lists, a rebate threshold on a product range, stock reserved at quotation, an invoice from the same document. Then a brochure site or WordPress may be enough for the company website, while the salesperson’s and the warehouse’s work still needs an application, not a theme. Open source is material in that application. The product is the order flow.
GESOFT builds such panels when an off-the-shelf product cannot cover the process. The conversation starts from who raises the quotation, where the price comes from, and what should happen when stock does not match. In the same engagement one can do a dependency inventory: list the packages, check the licences, plan the updates, and keep out of production a library nobody will maintain.
Sometimes an integration between the existing accounts program and the order panel, plus order in the lockfile, is enough. Sometimes one abandoned library has to be replaced and the rest left alone. Sometimes only after the flow is written down is it clear that the spreadsheet still suffices, if one person calculates the rebate rather than a dozen. That conversation is cheaper than rewriting the panel “because open source is risky” or “because a closed stack looks more serious”.
The conclusion from the arguments is narrow. Open source in business software is a rational starting point for commodity layers. It is a poor substitute for an owner, a contract and an update rhythm. The wholesaler in the example does not need an ideology. It needs a list of what sits in the panel, a decision on which packages stay, and a person who will open that list again next quarter. Without the list, a free licence says nothing about whether a quotation can be raised tomorrow.
Frequently asked questions
- May a firm legally use open source in a B2B panel?
- Yes, provided it follows the licence of the specific package. A permissive licence usually allows a closed panel to be built. A copyleft licence may require the same freedoms to be passed on, especially when the code is distributed or — under some licences — offered over a network. That does not replace legal advice on a concrete contract.
- Must the code of one’s own panel be published because open-source libraries sit in it?
- Not automatically. Many common licences do not require that for ordinary use on the firm’s server. A duty to publish depends on the licence and on whether the software is distributed. That is why the licence sits next to the package name in the dependency register, not under a general slogan that “everything is free”.
- When is it better to buy a closed component instead of an open-source library?
- When the layer is critical and the firm needs a contract, a response time and someone who will take a ticket — typically the database, a payment gateway, a map, a document engine kept current with the rules. A chart library in an internal report can usually be replaced. A payment helper with no releases should rather be replaced or bought as a product with maintenance.
Related service:
Custom software for companies
Describe your project