The first good thing, welcome.
My name is Marcel Kotzman from, you see my company, Robert Bosch, but what is more important
is I think my community and I have also some chokers in the audience for the questions later,
so I'm happy that you're also here.
And well, that went too fast.
Our community was formed a few years ago already, so what we're doing here, I think
we were ten people in the beginning.
Also we had exactly the same discussion we had this morning some years ago, so it's
good that we have now a bigger audience.
And this is also my, if you want to go out and have a takeaway then please have this
takeaway, please join us in our tooling community, sharing creates value.
I really like that name from the beginning because that's really what we are here for
and I think this is an all over non differentiating thing, right?
So we all profit from having here a better as bomb tooling processes, etc.
The title of my talk is about doing this at scale, so here's where my organization comes
in because we're not doing this for fun or yeah, it's more hygiene topic, so every developer
says yay.
But nevertheless, what is important for my company is be good citizen in the open source
community.
So that means on the one side if you use something we want to give back, so therefore we also
doing open source on our own, so that's what we called from the beginning, eat your own
dog food, so if our developers need to suffer doing all this open source paperwork, we
should also have a clue about that.
And so in the beginning we also that you know beginning doesn't mean not for Bosch,
Bosch began much, much earlier, but when we started with this automation, our journey
began here with typical Java Maven project.
So before I can tell you all the details, I just said okay, I make this fact sheet and
this will also accompany us through the presentation and that you just get the idea on the left
side, no right side, here we have also a fact sheet that I took from the NASA and that made
it really complicated now for the presentation preparation because that's so interesting
once you dive into this you get distracted very, very quickly, so here I also put the
link.
So now we got the idea, for me Java Maven this is a community, so we have projects approach
us okay we need some kind of support to doing this S-bomb stuff in the beginning and mainly
triggered by the license compliance and so in the beginning we didn't have that fact
sheet right, so we just started on and then we're done.
We were done, we said okay now we created the S-bomb automatically, the FOSS compliance
bundles etc.
So I said okay mission completed, no.
So then the next wave came up right, so oh yeah here web apps, JavaScript, NPM, blah,
blah, blah, so here again fact sheet, so some things looked similar and also here the build
mode is very important because you could ask why should you automate all this stuff if
you release once a year for something, no, but we had this high requirement from the
beginning to do this CI CD, but here for JavaScript our paradigms didn't work right because as
most of you potentially know if you use it or my previous speakers use one dependency
you get thousands of transitives right, so that didn't work, also this that you have
this one to one, yeah one source is one binary didn't work, so we had hard time but we somehow
well 80%, 90% so here I would rather use my chokers later but I think we handle it now
somehow.
Also when we started to do this we said okay because as I said the developers were not
super keen on doing this, we tried to push this by centralizing that, so looking now
from the end that was perhaps not that good idea rather to decentralize this because
now we also centralize all the problems that we already here heard the whole morning and
the whole afternoon right, so this is all on our desks.
And here this was also the biggest learning when we said we had a vendor solution at that
time still, said we need this, we need that, so it was hard, so this is also where the
community the open source really helped us because then we could also do what we needed
at that point.
The other thing so here I put Mars, yeah is that we still had all the other projects
right, so we couldn't just say okay now a mission completed but they also continued
and doing new things, well this is innovation right, so you will never stop so we were going
from one orbit to another and also this little wordplay there is intended because most of
the time you will know that we use OSS River to get this.
And that you know so who is the crew in this, this is I'm not the developer, so therefore
my joke is later and I'm rather looking from the process perspective but we also had then
the development team, we had developers, we needed to talk about this and here the next
stop was then embedded C cone and thing, so okay that is a completely different planet
right, so here and also I learned where Saturn is a gas planet so there is no even a surface
where it can land on so you need to stay continuously in the orbit having some probes
that you send out and also again differences so also you don't need to read all this stuff
it's just for giving you the idea and here I made an, I went back in the history and
get okay when we came in because also Thomas and Sebastian they were pretty, well busy
already in the beginning where we had this starting point which was already supported
in the beginning and then you see also the history so even more planets coming up and
I'm still convinced that this is not the end here at the right side and now this is at
scale because this is just the background right at scale for me means with all those
planets there is a scaling then in the horizontal if you want because as central as I said earlier
we centrally supported here our two teams that we needed then to scale in the horizontal
really supporting this ideally for all the teams with all their different planets and
here from the experience that we had in the team is it was very helpful then within the
team but also with the customers to have those fact sheets so this always developed more and
more to say okay for onboarding say what are we talking about right so what are you doing there
so either as well for the for the developers that we contacted as well for us in Germany
that was very helpful on the other side also the when we started talking with them so how do
you do it today we started the in the documentation why because we needed to have we also having
teams from automotive right they need to have audit rails all this reproducible documentation so
we documented it that was good because then we also could reuse the concepts but then we
iteratively improve them and came finally to say okay hey that's good this we can standardize
we can reuse this and then this is the evolution then you can also once you'd standardized then
you can start automating you cannot start automating directly from the beginning so you
should have this information and the other thing is if you especially if you say okay I started
from from sketch again then you might reinvent the wheel but the other thing is with all the
tools also I think Anthony showed it earlier so you have a list of of of links several tools so
which one is this the right one so also here the concept documentation was very important as
all with the help of fact she's then to see okay what is then the correct the correct solution for
my for my problem and our next stop you see embedded IoT Linux so here's also invitation join
us here we still have a lot of fun in front of us to manage this because here again we have
completely when when we had built less approaches where we could say we had this discussion earlier
okay source code is the truth perfect this would be then we just take the repository analyze it but
here we obviously have a build based approach that we need because the build also does a lot of
things and I just learned also compiler blah blah blah all this other stuff and then coming back to
the to the point and it's the last point here in the background so now the learning is we need here
those fact sheets in order to not lose time in upfront to say okay we're what we are talking
about then we also came to a generic architecture model and this is also what you see then in our
tooling group so that ideally we use the same wording for that and the standardized representation
but the other thing is once I have this so where can I find find this if if I have a good
match and then I took here this example from online shopping if you take want to shop close and
I that I found what was a nice thing I say okay I would love to have this also for us right so am
a man woman or a kid do I need clothes or shoes and check its blah blah blah and then you get
the selection of what you can buy but at that point where you need also to give now to narrow
down the selection okay you need to measure okay what size do you have and now okay this looking
at my belly this is then exactly where he said you here you need the the semantics okay where do
I measure this right and this is what is then where we need the genetic architecture model for
yeah now you see the story what we do we prepared this already the our new project eclipse
up oapses so and I as I said it has several aspects so for those who are not familiar with what is
up oapses I also copy pasted the definition again if you dive into this world you will probably
need some some hours even or days because that's very very interesting but I also liked the link
here so therefore I also put the two definitions so up the abscess is that fast fast from the center
of attraction right the high point in an orbit and up oapses the other thing is then
the fast fastest away from the body it is orbiting so therefore I made this little picture it's
it's potentially wrong so please but then you just say there you here you have the center of attraction
left side and the up oapses is this point so the really when you in the orbit that is fast away
from this planet and I think that fitted very well because if we switch between the different
plans you need to switch the orbit and that's the best point because then the attraction of the
original is is so low and here you will not really find a lot of contents yet because this will be
in the next days and weeks but the also the proposal the text here I put the link so what is inside
so this is more or less the trailer of a film if you want so you can see the film later we I also
give you some hints in the in at the end but just that you know what we are talking about and therefore
I saw as I'm the process guy I said sorry I had also I also wanted to be a part of this projects
and collaborate so therefore there are some process level documents on and that would rather
cover this horizontal scaling right so that you can say okay now let's have a common way how we can
map this the other thing is that we are using a lot the OSS review toolkit and here that would be
then the vertical level because here we need to scale also as we need to run really really a lot
of scans every every day and here we have performance issue in the way we use it past
and here you see this would be also some code contribution that we would do is that you can
expect and the upper part as I try to use the the icons a little bit is then really the idea what is
the goal that you can just come say okay what are my needs and what is already there so to really
jump start your process definition ideally just copy pasting then the the the templates and you
can directly start ideally then via our tooling group mapping the tools that are available
on the technical level so here we're using word so if you are a single project then
anyway not in a target group of my talk today so then just go to or page or then if you have
built based issue then you join us in the tooling group you will find your solution if you have an
organization that has the same issues than my organization that you really need to use that
at scale then you would invite you also then to join us in the eclipse apoapsis project
and here there the old server you can what what we will contribute there you can really just take
it and build up your own service in-house to automate then this software composition analysis
we're coming heavily from the open source compliance but we also have security aspects and
we heard also safety export control so everything that will be there and this is also why I said
okay this is important that this is not this is just another puzzle piece if you want but this
very important is the cooperation with the spdx here we also call for action invitation we have
this new operations profile workgroup so we are invited also to join us there
that will start in the next days I think the first first meeting on the one side and we have this
dependencies to the open chain tooling group where we do the capability map so also that we do not
need to reinvent all the wording so this is already there so you can already check it out
and on the technical level here this is also where the maintainers are the same right
in the uss3v toolkit where we have strong connections and then also you can see the technical dependencies
but as I'm the process guy and I have a lot of chokers in the room but we have not that much time
I will tell you later I explicitly asked my colleague so for those who are interested I have an offer
later to you so on the process level side so this will be then this is just a work in
progress thing where we have the generic architecture that we map against the capability map from
that we already developed with the with the tooling group so that we have then the ideally the same
semantics so just that you have this picture in mind as I said we're coming from open source
compliance so therefore the current capability map is open source compliance related so for if we
then also go further with security then I think we also need to define further capabilities then
the question is if we do this in our group or in other groups but we will do it together well
that's that's for sure the other thing is this and therefore I originally called this abstraction
layer so it's abstraction layer not in the sense of a software that we create but rather on a
process level that you say okay we have different stakeholders we have different products and here
this is where the operations a work group from spdx then will will it will help yeah to say okay
to rather say am I a man woman kid etc so where I'm in on the one side on the other side also
having some standardization to have those fact sheets so is this the perfect solution or next to
a perfect solution or at least something I can start with because here and this is where my
organization is potentially special here we are in the middle of a supply chain typically in the
automotive industry so we also we are not alone we cannot just say okay we will use this or we
have legacy therefore we have to have flexibility for you that would be then the possibility to
still keep the flexibility and say okay I have just as Anthony showed I have choice right and
that's not bad of the on the other side and therefore we started this touring group is that
we are only we were only a small group so we said we cannot maintain thousands of redundant things
so we should focus and especially if we still have gaps on the other side so then rather say okay
let's consolidate on the one side and then use the resources rather on another place
then also the blueprints as I said so we're here we have everything we heard today beginning with
deja-court from from Philippe now a phosology I saw here the colleagues also software c60
or obviously false light so there are so many things where you you're totally lost right so
there hey I know there's a solution but I don't know does it fit for me or not so I this is something
we should tackle and the other thing that's funny because we also talked about this also the question
so who am I right so am I rather developer I need rather this for my use case or or I'm rather
try to manage this thing or audit thing so here this is important that we document that somewhere
so I would offer to the start here but I'm open also to do this somewhere else especially as this
will be necessary also for us to do the testing later because with a well-defined use case it's
easy then to start then the test case yep thank you the test case definitions and the better the
test the better than the solutions the on the technical output so the ord server what will that
be so the goals of the server is that we have a unified API that you can use so if you run really
at scale from your CI CD you can just call this API and it will all do do all the rest more or less
easy setup integration you can read it on your own what we do not have yet but is one of the goals
is frontend because this was typically then the the issue if especially if we were compared as
those as River to a kid community with the vendors the vendors typically come up with a new and find
ceo I blah blah bling bling bling and we will just well we have a tool that just does the do the
business right but so we we know it's it's important and you see then later in the outlook and here I
would potentially also have a choker then in the in the audience what what will come so that you see
how would such a setup look like so you have a development team who wants to use this software
composition analysis service so they can just use the API the ord server would do the rest of
here you see then the different workers Martin called that from ord ord analyze the downloader
scanner so these are the typical steps that you need then ending then with a reporter but we have
teams that only needed parts of that then also sometimes the one thing uses a lot of performance
so therefore the balancing is very important and that's what what you can then do
with the server here we have some usage blueprints that we already will prepare with the project
also in the use case collection the things that we use then for testing it and then another use case
as I mentioned would then also be those those dashboards those your eyes people that want to
know more this will also work then with the server just here the MVP that you will be able to expect
then in the next weeks to be in our repository the repository was already there so we're preparing
currently the initial contribution and this is the next step and that was I said so now you would
say I want to know more about this ord server how does that work so there's an invitation we have
twice a month the tooling group meetings every first and third one Wednesday the first
Wednesday in the morning for the rather Asia Pacific region the third Wednesday era and the
european sorry the european afternoon will also to cover better the time zones with 50 us and
yeah so please check out the open chain global calendar so if you if you're interested and the
next one I will moderate and Martin will be there so for all detailed questions regarding the technical
stuff and we can also discuss the the other parts so I would really be glad if we could have some
follow-up discussions in our existing communities then as I said this is yeah depending also on the
on the load the initial contribution that we prepare ideally we should have it ready then for the
community days so we plan ord community days beginning of March I hope I have put the right
link so please register if you're interested because then we have also a detailed session about that
and about the front end so we will not provide the front end in the beginning but we already in
discussion with double open project so that they are also interested in providing something but as
this is an api so everyone would be welcome to have their python shawasaki whatever you want
but yeah at least we will care that we have a cool server in the background thank you very much
stay tuned so here are all the links especially so really the who didn't know about this especially
Anthony I would really welcome you if you also could present your your benchmark that you did
that was really great because we also have the python inspector in the ord analyzer how we would
get there and these are things that we really do in the tooling group thank you very much
we'll have to answer a few questions
address that noise yeah so the question is that we have a lot of noise and transitive dependencies
I would directly rephrase that so you have dependencies in the build scoped in the test
scope whatever and then you get the build of materials with thousands of things and there are
irrelevant repositories that's how we call them so here this is a process level thing right this
is where we typically come in and check with the teams please unscope that so here we have
configuration as code is in the in the ord principle so you can directly silence down that
that noise by just excluding then scope things like that but also that depends which planet you're
coming from right at scale um at scale this is uh yeah so I would forward you to my joker here
which is thomas so again here we should talk about which planet you're coming from right and
we can also reuse a lot of this uh in a in a central database this is where also the previous
talks were about sharing then creations package configurations uh here you're also more than
welcome to uh all collaborate thank you thank you again