We talk about how to buy something that's free and that's an interesting concept because we all have to deal with this being open source minded people and there's a lot of misunderstanding in the general corporation and governmental world actually how to handle open source

projects or even how a business model can exist around open source products because to most especially procurement offices buying something that's free makes no sense at all and therefore it can never work and therefore it can never be bought and therefore you can

see where I'm going. But first let me say hi this is me I'm Hans de Woude, owner of Open Novations. Open Novations is a Dutch partner for Collab Systems. So we do implementations,

security consulting, I teach at the university of applied science and basically I do whatever I like and with which I can find a customer and we're not alone we're working together with a couple of other companies and freelancers to provide services. I find it absolutely

paramount to have at least one picture of my car in every presentation and a personal challenge of mine is also to at least say something remotely connected to my actual topic about my car and the thing about my car is that in essence it is an open source

community on four wheels. It has modular parts, the parts all have open prints if you have a really advanced 3D printer you can actually print out my car, assemble it and have it working and the beauty about that is actually my car is not only an open source

ecosystem on wheels it's also an economic ecosystem on wheels because thanks to my car at least three garages in my nearby home of infinity are able to service my car on a regular basis. They all have their specialities and they can work on my car as contrary to modern

cars. I used to have a newer Mercedes ML before this and with that car I practically only could go to the Mercedes Benz dealer, well which wasn't that bad because they had decent coffee and stuff but still I like the concept of being independent and open and the thing

about my car also is that I work with computers day in day out and I want something to be as reliable as possible and as simple as possible therefore I own a car that doesn't have computers so whenever somebody sets off an electric magnetic pulse over the Netherlands

my radio won't work but my car will still drive. So what's my background in public procurement? Well basically I've been advising those governmental agencies for a number of years

now and how to handle open standards and open source and basically service type oriented products, how to procure them and I've been involved in a number of EU tenders both in defining the requirements and in the eventual selection process and I've also had the pleasure

to attend at least three court cases surrounding those tenders because eventually you will always piss off somebody and that somebody usually is the party not getting the contract. How strange. So at the moment I'm still involved in that governmental circles

especially through my association with the forum standardization which in the Netherlands is the governmental body deciding on which open standards are mature enough for adoption

in governmental realms. This actually was the body that in 2004 or 2005 adopted ODF as being the leading document standard in the Netherlands and I was the sorry soul who got to implement

ODF within the Ministry of Interior and the Ministry of Justice. If any one of you during that period of time experienced the same I strongly sympathize with you but still it was fun. Alright so how does procurement work in general? Usually an itch needs to be scratched at some

point and organizations tend to solve problems or perceived problems by adding new items into an equation. I rarely come across organizations that have a sense of urgency or perceive a problem

and then decide to cut out something because apparently in our human psychology it sounds really good to add stuff to a problem because that implies that you're actively working towards

something new or more. That sounds better than taking stuff away from a problem for some reason and basically that's why procurement will until the end of times be a popular hobby of a lot of at least governmental organizations and other parties. So you will need some requirements, you

will put these requirements out into the markets, request any kind of proposal, you will then enter a selection and a decision process. But in general the most important bit is the fact that you actually have to fulfill such a procedure to acquire a product and if this

whole procedure stands strange to you being open-source minded, well it is because being open-source minded and using open-source software, well basically what we do is we formulate our

requirements, then we go to git.colab.org, we download Colab and then we have Colab. Notice what's missing here? The rest of the procedure. So the whole open-source thing makes procurement officers a bit itchy because it goes outside of them and that's exactly what I want to talk

about because we need to figure out a way to frame the open-source propositions into viable units or we need to frame our business model regarding the open-source product into

a viable unit because to a procurement officer, if it doesn't come in a box with the women around it, it must not be a product, therefore it must be a service and services are strange but okay we can handle that as long as it's man-hours or woman-hours and we charge money for that. But that whole notion is different with open-source of course and

therefore open-source is usually also often put in the corner of bespoke software. So bespoke software being usually a risk for your organization's future sediency because

it can only be maintained by one party etc etc. And usually if this sounds strange to you, well it does but it is actually the misunderstanding that's going on in these reasons. So, procurement starts with an itch and this itch can be something that's missing,

something that needs to be replaced, something that needs to be updated, something at all. It can be an organizational demand or whatever but at some point in almost any IT gender you will see a couple of principles which basically mean whatever we're going to buy

must be exactly what we already have or at least be so similar to what we already have that we don't actually notice it's there. And for years and years and years governments and also corporations have explicitly specified that whenever they bought a computer it should

be the Wintel platform. Literally in the public procurement requirements Intel processes Windows operating system period. The European Commission had already in I think it was even 2001

decided that this was an undesirable policy because well Fender lock-in yadda yadda yadda I'm sure I don't have to bore you with all these details but countries went on doing this. Actually I was in a public tender in 2009. It was the easy 2010 tender for the Dutch

government which was a government-wide tender for the national government to basically replace all desktops and servers and printers and data center etc. And I was liaison for the

standardization back then so I had to take a stand to make sure that open standards got in there and competition was built in too. And the first requirement that the working group came up with was we need Microsoft Windows and we need Intel. That

was in 2008. So between the European Commission deciding something and the national government actually doing it there can be quite some time. But the whole concept of the tender in general is to make sure that you end up with a product that fits into your infrastructure anyway.

And a lot of effort actually is put into the contractual phase which basically means who can sue who whenever something goes south. And that's also a bit of an issue with open source licenses in general because they state that the software is free as is without any

warranty etc. And as soon as you show such a line to a procurement officer, well usually they turn green and they're like really can't be good if they upfront deny all accountability then it must be rubbish. So that's something we need to work at too.

We need to work at the perception and also we need to explain how to actually sell open source because public tenders are, and it doesn't matter what they're actually trying to procure, but they will try to buy a bridge. Whether it's software, whether it's servers, whether it's

man hours or whatever, basically all public tender procedures originate from infrastructure projects and most of the procurement officers will approach an IT project as if it were

building a road or a bridge. And that's a problem because the software architecture by nature is way more modular and layered and also has different types of interfaces and ongoing services etc. than you would have with a piece of road. So actually there's

life after the procurement process and this is a real change of attitude for a lot of procurement officers nowadays because instead of only being involved in the first acquisition they will now also become ongoing contract partners in the ongoing performance of the contract.

But modularity is a keyword that's bobbing up quite a lot lately. Especially in the Netherlands we've had a parliamentary inquiry onto why so many government IT projects tend to go over

the budget and tend to never finish and tend to not deliver whatever they expected to. And basically what they realised was, well since we are buying software as if we are

buying a bridge, we have an issue because for the bridge it's pretty simple. The land is there, the roads are there, the rivers are there, they won't go anywhere. So basically you can take years and years and years to build a bridge but usually if you don't have earthquakes or floods or other stuff the connections will remain. But in software,

especially process management software, ERP, document management, you have at least three factors outside of your IT project which influence the project. It's the IT infrastructure itself which has a legacy, it has a complexity, it's the organisation around the IT department

which will differ through time in their demands on a certain project. And also it's the political reality surrounding a project. Especially the Dutch parliamentary inquiry, one of the biggest lessons learned, not necessarily lessons well learned and well implemented

but at least they learnt, was that the influence of the House of Parliament adding changes to a project during the project realisations effectively meant that no project can ever finish.

So what happened then? Modular procurement came in and the idea about modular procurement and Open Forum Europe has a very nice document regarding the whole concept of modular procurement in IT. It's about interoperability, vendor independence,

digital sustainability by open standards and especially also define an exit strategy before you even start implementing a product. And that's another lesson learned from the parliamentary inquiry in the Netherlands which basically meant that all we've been doing for the past 20 years in IT was to buy into products and have no single idea if we were brought

into the product, what to do whenever the product would be obsolete or go away. The best example for this for instance was a document management system developed by the

Ministry of Interior in the Netherlands based on compact work expenditure software which was a plug-in for Microsoft Outlook XP and their whole organisation, every signature

in the organisation, every document proposal or anything had to go through that system. So it was based on Office XP. Do you want to know when it was implemented? 2008, which was a bit of a problem because by then compact didn't exist anymore and the product work

expenditure did not exist anymore and Microsoft Office XP was on, let's just say, terminal life support. And that's what happens quite a lot and especially in the follow-up project after that they've chosen not entirely an open source system but at least a system

built on open standards, namely IBM FileNet, which was actually implemented impressively fast considering that the first Expeditor project took them seven years and they've implemented the FileNet system in under two years, which actually was a fun project

to do, I was proud from that. But the thing with also FileNet and the approach was that instead of creating one homogenous system to rule all the documents, FileNet would be simply a self-containing unit of documents, it wouldn't necessarily integrate

with Outlook or any other productivity tool, it would just be a document management system and it would interface with different systems. And this slide was actually, let's just say, I'm not sure if this slide is still relevant tomorrow or if the UK even still

exists tomorrow, but let's just say that the UK government does something very right, especially their digital services store. And what's really nice is modular software also enables smaller units of procurement. Smaller units of procurement also imply that

SMEs can buy into that as well. And one of the core principles of the economic agenda of Europe is stimulating SME participation into procurement, into tenders. So whatever you need then is smaller units of procurement. And the UK government has defined a number

of domains in which they will seek for partnerships with smaller parties and which they allow smaller parties to actually apply through a marketplace to build such modules. It works beautifully. By now, almost 200 participants in there, among them a lot of SMEs. The

Swedes do the same. A bit different model, they publish micro-challenges, micro-tenders in four domains, and they have outlines as base principles that they require open standards

and they require proven interoperability with existing applications through open standards. And they will actually demand also, when developing bespoke software, that the software intellectual property is then transferred to the Swedish government so that it can be reused

within Swedish governments. So it's not 100% open source yet, but at least we now have reusable components from taxpayers' money, which is a plus. The US government, which I personally find a really interesting development because, well, the US for me was always

a bit analogous to, or synonymous to, well, the big software houses, the usual suspects, and therefore, well, I would not have expected them to adopt such a policy. But basically, what the Department of Homeland Security got up with a couple of years ago, and by now it's the standard for IT development and IT procurement in the US government, is basically what they said

was, we throw away waterfall and we now adopt agile, and we want modular reusable units. So that's interesting. It's actually a readable memo as well, you might even take a look at it.

And in the Netherlands, we also, even in the Netherlands, I even would say, because traditionally we would really suck at EU tenders, we would make them as big as possible, including the kitchen sink and everything. But by now, yeah, actually, the book in there is

there for a reason, because we would procure anything as be it without our works, which are interesting stuff to look at, by the way, if you ever in the Netherlands, I can recommend that. But Piano, which is the procurement expertise center for this government, came up with a guide called micro-challenges, which basically is a guideline for cutting up big tenders into smaller

modular units. And they're now actually advocating, downsizing the procurement projects instead of advocating bigger projects. It's an interesting paradigm change. And even in the Dutch ARBIT,

which is the government guidelines for IT procurement, we have a couple of articles that actually, if you read those well, the obvious conclusion would be open source fits perfectly, right? So, but there is one thing that open source is, or these open source projects

are quite bad at, and that's about, let's just say, anything outside of software development. There's a lot of interest and attention in recent times going to user experience,

and user friendliness and code is absolutely spearheading that by making all their products have a very consistent look and feel and thinking about usability quite a lot. But we need more, especially with regards to the adoption of open source in these markets,

because all these niche markets have different compliance models and guidelines. And the thing is that actually they're not that different. Basically what they all want you to do is adopt a risk management strategy and make sure that in your system you have some way

of accountability. Who done what at which time, and who can tell me why that was a good idea. So traditional vendors, they simply state that they are compliant to all these different schemes, which in fact they aren't. And that's the nice thing about it, because if you actually

read the compliancy statements from Microsoft, Amazon, and Google, and I can go on quite a bit, and actually I did read them, you will not find a single concrete promise in there at all.

It's all could be, should be, would be, might be, in a nutshell. But it reads beautifully. I mean all that a procurement officer will read from this, oh I have the word FIPS compliant in there, it must be good, etc, etc. So what should we do? We should do the same. Open source projects need to think about how to promote themselves in these branches. And

it's actually not that hard. It's just a different set of documentation, it's just a different set of promotions. It's just a different way to enter a market. So open source projects traditionally are very inward focused based on their functionality. And in their community

they're very open and transparent, but by themselves communities are a bit like world gardens. We need to go outside there. And we also need to promote a model of procurement. I mean, who is a business owner here? I am, and I see a couple more. Excellent. So who works for business?

The rest probably. Help make this happen. Go to governmental networking events regarding tenders, because they are there and actively ask for modules of development. Because, strange enough, governments and especially the procurement offices of government,

now knowing that modular development and modular procurement is on the agenda, they actually want to learn. But you're the ones having to teach them in that aspect. I've been doing that for this government for years by now. I've been giving workshops all over the place in how to do modular procurement. And the best thing is that giving those

workshops has become a business model for me as well, because now I get paid to do that. Sweet. So adopt at least some basic outline of a risk management strategy in your open source project policies, because that's important as well. You should at least be aware of that

those things are required when participating governmental tenders. And this has some quite readable documents on that. And also we have the OSSTMM methodology regarding risk management, which gives a very clear indication of how you should approach risk management in general.

So it's also readable. But in general, make sure that the world knows that you're doing this. So what do we usually do? We create great software, but we lack formal structure in the organization. And we need to work on that. And we need to describe our governance structure. And we need to describe how things work. We

need to be able to point to a set of documentation and information that a procurement officer can read and learn to understand the business model. So how do you buy something that's free? Not by itself. But you can buy the business model around it and you can make money from

it. And we should. We make great software. We should make money out of it. And we should battle the issues and misconceptions that arise whenever the word free comes up. Because free usually is not associated with freedom. In procurement, free is usually associated with

worthless. And freedom is usually associated with anarchy, et cetera, et cetera. And we have to explain that message better. Because it is the economy. And we need to start adopting models

that make us be able to sell our great products. And there are some excellent examples of companies who do that. For instance, they all have a premium enterprise support model. And it works just fine. There are different models as well. You have OpenStack and Drupal.

This basically is an array of organizations collaborating on a certain project and providing services around the project. Take a look at them and learn from them. Because governments really want to buy open source. But in that sentence is a contradiction in term.

Because you can't buy something that's free. But they can buy into the concept through our companies. And we should make them able to do so. Any questions? Go and sell open source.