* more explicit on products are open source * explain overlap between all products and services: buckram * how are client services open source exactly? Surgery, offshore structures, bridges and spacecraft. When we simulate life-critical engineering, we need to understand the accuracy of our tools in each specific scenario. To do this, we need to know the underlying theory. A number of years ago, an entire oil rig collapsed in Norway, as a result of this lack of understanding. When I was working in engineering, we needed to check which established theory was used by a common proprietary tool we used for all those applications. They told us that was commercially sensitive information. If there were accepted open tools, transparent and without vendor lock-in, could we justify buying from that closed provider again? At that point I realised that closed source, as an economic model in critical industry applications, has a finite life. Now think of all the contexts where transparency and accountability are critical in software - hospitals, government, courts, data security, cybersecurity. That may seem positive for free software's future, but only if it is self-sustaining without the closed source ecosystem - core developers not having to rely on proprietary or research-only employers to keep them fed. I believe open source is normally more economically efficient and socially beneficial than closed source, so FLOSS should be a safe business bet in the long-term. I quit my job several years ago to test this, and discovered you need to eat in the short-term. First a couple notes

So this is the story about how we found a model that's kept us afloat so far. How many of you have played table-top adventure games, or classic RPGs? Pathfinder, Dungeons & Dragons? These games often involve a group of people meeting up occasionally to role-play characters in a guild or syndicate, with a diverse range of skills and personalities - wizards, warriors, even pairs or trios of characters played by one player. Together, they go on quests for gold, rescue kidnapped kings &s; queens, defeat monsters. A couple of my coworkers introduced me to this world about the time I set up my own company. We didn't have everybody turn up for games every month, so even with one big theoretical adventurers' syndicate of all of us involved, some quests would involve some adventurers, others would involve others - we tried to pick quests that matched the available skillsets of each month's group. Two wizards would have a magical quest, a wizard and three warriors would go into battles. You've probably guessed that I'm going to tell the story of our business syndicate using these adventurers.

Case Study

Before I go into our general approach, here's a concrete example from a project we've only just started. Try and bear in mind this case study when we go forward. In 2018, my microcompany led a consortium bid for R&D funding. This was to build a prototype open data discovery platform for community journalists, who often struggle to engage with accountability information released by governments. This was to be entirely open source, based on our team's experience of open data. We wrote the bid closely with user research and community journalism partners. We planned out focus groups, performance measures, provisional budget, risk mitigations and tried to get up to speed on the field all before the bid. When we were awarded the funding, we paid a lawyer to write a legal consortium contract for the project partners. Last week, in Belfast, our UX partner ran our first focus group with journalists. The two development companies have been doing proof-of-concept work and produced a basic feasibility study. Over the next six months, we will build out and get feedback on this prototype, and research ways of getting it moved on to a v1.

open source is only one critical piece of an open technology jigsaw

in software development, open source can stand alone - a software developer needs software, they develop open software, software developers improve open software
but it gets muddy when you move to anything involving design - can you have open source without open licensed assets? some say yes, some say no
when you move into business, it gets so much more complicated again - customers that care only about software solutions, will still go for black box solutions with reassuringly big pricetags and lock-in. customers that care about open software, such as government bodies or increasing numbers of tech start-ups, care about it because it's open, and that affects source, data, standards, services, research and security
However, for the moment, I'm going to stay off business models and clients, and explain how we used "open" to give us a unique selling point

Every "U"

is an "SP"

using FLOSS philosophy in building up business relationships

Focusing on open IP is a constraint our competitors didn't have
As we had our one prime directive, we had to be pragmatic about what we worked with, who or where
So we looked at where closed IP was a constraint, and the opportunities we had our competitors didn't
In particular, why don't four people build one big house instead of four small ones? Because they have to work out how to share it
Closed IP companies working together is messy, but stop trying to put commercial value in exclusive IP, and you open up a world of options
As soon as you can have separate microentities working together, without lock-in to each other or exclusive IP rights, doing projects on a consortium basis, rather than a subcontract hierarchy becomes possible
If you are working locally, you may find regional work tends to be development-light and low budget - therefore, design agencies tend to be easier to grow than development companies, and consequently are big enough to attract any larger development projects
Agencies are then tied by the need to bring in developers without enough dev-heavy projects to build a full-time devhouse. Freelance developers have very little buy in to agency customers, and are often resentful of the mark-up agencies apply to their hours. Conversely, agencies are under intense pressure to deliver projects without technically-adept PMs to set scope and expectations, and find many freelancers to be unreliable and fixated on technical detail - consequently, they need a high margin on subcontractor costs to offset the high risk. I'm sure the most feared words a prime contractor can hear from a dev who has disappeared off the radar for 3 weeks or a 6 week project are "sorry, something came up, no longer able to finish this - don't worry, I'll only bill you for the time I've done".
How do you resolve that? If clients buy in to the fact at least some IP is not exclusively theirs, and any such IP is open, everything changes. This can be achieved through a simple consortium model, or just carefully worded subcontract. Any freelance developers can then be building their own (open) IP bank and commercial profile that allows them to build up multiple agency clients, a one-person company of their own. Agencies can see they are bought in through their open IP, and have access to any of that IP, so have not practically lost out. Developers starting to grow a profile, can gradually get a foot on the customer-facing ladder, where they can win work and subcontract design components back to an agency. This is often the kind of work agencies see as a risk to take on themselves, so prefer not to be prime contractor - tough technical requirements, light on design, but it suddenly means they have developers who are as dependent on them to deliver as the reverse. Add another dev or two and you have the bones of a consortium - highly specialist microentities and small businesses, able to jointly bid for work.
In particular, the main obstacles monolithic small businesses, your competitors, have is their inability to find and keep specialists. In a consortium model, unlike a coop or partnership, no one individual or business is responsible for anyone else's income - this brings challenges, but it also vastly increases the scope for bringing in specialists, and with specialists come high value larger projects, with fewer competitors. It also allows everyone to set their own working expectations, price themselves in or out of individual pieces of work, commit to one project at a time. Consortium members must either be useful enough to the group that they keep a stream of subcontracting coming in, or find projects themselves - as most members are specialists, these will inevitably fund several members.

One key benefit of R&D funding, and a major selling point for getting people out of contracting into a consortium is product-building
Open source allows a lot of decisions that have to happen up front in an exclusive IP world to happen at the end - every one can take the copyright and do what they want with it, but one company or a subset may wish to commercalize it - that is the point of R&D, but with open source, making the commercial decisions at the end is much less messy than it would be otherwise. Trademark is a slightly thornier issue - this is one we have realised needs to be handled differently, having more in common with attribution than code. No guarantee is given on entering an R&D project that you will have access to the brand at the end, unless you are part of the resulting new product company, but all the source code is open to you regardless. You can start a competitor with a new brand, if you so desire.
Open product vendors, outside freemium, generally trade on market position, first mover advantage, expertise and lack of lock-in. This means that, fittingly for a consortium, product money will primarily be through services and consultancy. We are still early on that path, but while this is much lower margin than a unicorn product, it's also much more sustainable, and through SLAs, allows us to charge directly for our development time improving it.
A side-point here, touching on politics - I've said open source consistently. If you're working in web, GPL is MIT spelt badly. Free is only as free as it is to the end user - if your end user is a developer using your tools as libraries, go permissive. However, if you are writing for consumers and want your tool to always be open for them, avoiding cannibalization by a closed source competitor, seriously consider AGPL, along side a clear public statement of what you consider a combined work. It is the only OSI approved license that provides some protection from opportunists seeking to show how open source people are daft by beating them with their own stick.

how we reach agreement on the balance between private, open and free with clients

Realistically though, product is important but a benefit of a consortium is that you don't have to operate as an island of directors with a product - you are able to have some members working on product, some with clients and some on both.
Our client work facilitates our product work - it allows us to fund development on overlapping features. Clients tend not to be too worried about this if it's done transparently. Bizarrely, we have found non-technical clients far quicker to get on board with the idea than technical clients used to traditional models.
We have found that the key phrase for non-technical clients is "non-sector specific". That is, we open source "non-sector specific" tools and improvements. Their main fears are around competition and dilution of brand - neither of those are inherent obstacles to open sourcing code, as long as it's not specific to a sector. For instance, a set of infrastructure scripts, or a report generation microservice.
We put this prominently in quote documents, and it appears in our contracts. We have had resistance and push-back, but as long as the our own project lead is bought it, we have not lost work. Nonetheless, one of the hardest jobs, especially when dealing with hard-nosed commercial PMs, is standing your ground - if you aren't a natural negotiator, make sure someone in your group is and instruct them not to let a restrictive IP agreement be bounced through. If it helps, see all client work that you don't get any open IP out of as fasting. You can keep fasting for only so long before your consortium is going to fade away.

Infra, data, sysadmin, devops & cybersec
Product, UX, UI, SEO, comms, copy, socmed
Tender writing, bizdev, finance, marketing
FE, BE, app, systems, HW, design & AV
Training, research, funding, administration

Isn't this a...

variety of skillsets is essential, and open source facilitates this

Now you have a consortium, how can you make _that_ a USP to give an edge on competitors, and keep getting work?
Monolithic small companies struggle to find and keep specialists - as a consortium this is much easier, everyone is responsible for finding and maintaining their own To avoid being dependent on an individual
Dev and design is a start, but training, tender-writing, administration, product management and UX, business development, marketing, content writing, various stacks, languages and platforms. Diversity of skillsets gets projects - frequently you're often competing against contractor groups, and what they cannot offer is what consortia and agencies can, end-to-end skillsets. Projects big enough to have budgets for scalable Kubernetes-based machine learning infrastructure have budgets for focus groups and user research - offer both credibly or lose out to a UX house who can hire a Watson consultant.
However, diversity of skillsets is also a huge vulnerability - one collaborator can hold a whole consortium to ransom. There are two main mitigations, legal through tight per-project consortium contracts and, even more importantly, through overlap. We had resistance to this as people didn't like having someone else with their skillset competing for work with them inside a consortium - however, opinions very quickly changed as individual members led projects, or saw six months of their income at risk because one person took ill. A practical result of this, given realistic member counts, is that every company should be bringing more than one skill to the table, even if it isn't their forte - for example, Python and JS, training and content writing, back-end and infrastructure, front-end and graphics, tender writing and scoping, UX and budget drafting.

How does this beat...

variety of skillsets is essential, and open source facilitates this

Now you have a consortium, how can you make _that_ a USP to give an edge on competitors, and keep getting work?
Monolithic small companies struggle to find and keep specialists - as a consortium this is much easier, everyone is responsible for finding and maintaining their own To avoid being dependent on an individual
Dev and design is a start, but training, tender-writing, administration, product management and UX, business development, marketing, content writing, various stacks, languages and platforms. Diversity of skillsets gets projects - frequently you're often competing against contractor groups, and what they cannot offer is what consortia and agencies can, end-to-end skillsets. Projects big enough to have budgets for scalable Kubernetes-based machine learning infrastructure have budgets for focus groups and user research - offer both credibly or lose out to a UX house who can hire a Watson consultant.
However, diversity of skillsets is also a huge vulnerability - one collaborator can hold a whole consortium to ransom. There are two main mitigations, legal through tight per-project consortium contracts and, even more importantly, through overlap. We had resistance to this as people didn't like having someone else with their skillset competing for work with them inside a consortium - however, opinions very quickly changed as individual members led projects, or saw six months of their income at risk because one person took ill. A practical result of this, given realistic member counts, is that every company should be bringing more than one skill to the table, even if it isn't their forte - for example, Python and JS, training and content writing, back-end and infrastructure, front-end and graphics, tender writing and scoping, UX and budget drafting.

If it works without mandating open, it isn't this

Starting out

e.g. ktn-uk.co.uk/funding

Key points

Contract Equation: Cost = Risk + Time + Skills
No-one is guaranteed work
Anyone can "coordinate"
90% structure is per project

Tattooed on my forehead

Fair => rigidity and consistency
Life is a negotiation
Reliance must go both ways
Less you charge, the harder the client
People must run projects to relate
Never undervalue non-dev disciplines!

Resources

https://github.com/flaxandteal/...
../consorting-docs
../fosdem-2019-consorting-with-industry

Future

Overseas Event (Hong Kong)
Second Phase - 2-3 year
Open Industry Network
Focus: SLAs & Product Sales

WHY?

Can work on FLOSS as part of an income
Not waiting for an OSS employer
Burst your tech bubble
Follow your own, not group, passion

If you want to keep revenue coming in without being stuck living hand-to-mouth as a freelancer, you need to get comfortable with funding frameworks, innovation funding, business writing - if you don't like it, you can take that as your one Prime Directive, but if not, you've got to suck it up and learn. Technological Readiness Levels came out of the European space programme - they go from concept down at 1 through early R&D to prototype to beta testing to in-market product
This slide focus on open access - who knows of open access? It's about making research results, and research data, freely accessible. Why is that important? Because it enables a form of sector-wide collaboration between academia and industry - instead of point-to-point collaborations between individual research institutes and multinationals behind closed doors.
Academia is not great at getting prototypes to market - SMEs haven't the funds for blue sky research. Ideally, open access gets those ideas out of academia, along with concept code. SMEs can pick up on that and enhance the open source, or develop their own - this helps build links with researchers, and encourage them to collaborate without dropping millions of pounds in academic consultancy fees. By supplying their data and outcomes openly, this provides researchers with opportunities for further publishing and joint work - you can see some of this in action in blockchain research, and so forth. However, without academia benefiting through open source, APIs and data, all SMEs can offer is mountains of cash - good reason to stick to open source.
There are a number of funds, which will help you work with academia and build products, especially open products, both locally and nationally. A lot of our income has been through open data in particular - if you replace academia with public sector, and open access with open data, you can see similar effects. Funders are much happier with this model - the major European frameworks now mandate a percentage of funding that must go to SMEs - as it encouraging a range of competing SMEs is healthier for consumers than subsidising a multinational to entrenche it's monopoly through exclusive research.