Intersource is GitHub culture and open source principles – GitHub Satellite 2019

Intersource is GitHub culture and open source principles – GitHub Satellite 2019


[MUSIC PLAYING] THOMAS CURRAN: So good morning. I’m Thomas Curran. Welcome to the session. It’s about intersource. And just as a background,
perhaps for you. I am a co-founder
and co-CTO of ORY. ORY is a very popular open
source project on GitHub. Please take a look at it. The topics are very much
in the security realm– open authentication, open
ID connect, AP security, and of course, we
love your support. What I want to talk
about today is actually how you build inside
your enterprise or inside your company a
community of developers that work on GitHub and collaborate
on GitHub more or less like an open source
project would work. So I have done some different
projects in the past and had different roles
in larger companies. And I’m going to
use that experience to draw on as I go
through the next 10 slides and help you understand some
of the opportunities you have to use GitHub in your company
and not only the tools and technologies but also
some of the methodologies. So for the managers
out there, I mean, one thing that’s often
asked besides the price of any new software
platform infrastructure is, why do you need this? And most companies today are
using some kind of source code control, some kind of
configuration management, some kind of
deployment pipeline. All these things are
absolutely typical. So the question of why GitHub
is a very valid question. And I made a post last year. We had a similar talk at CBIT
I’m very happy by the way that I was one of the last
speakers in the last CBIT ever. So that was good. One of the things GitHub
does, besides solve all these software issues,
is it lets you find things in your company. And you know this is not
a very funny problem. Most organizations, especially
they have email systems. They have databases, et cetera. But for source code,
it’s extremely difficult to find and maintain
across an organization a lot of the intellectual
property and just any property that software developers have
done combined with the fact that most companies today
don’t do that themselves. I mean, they do a lot of stuff
outsourced and so bringing that into the company and
being able to have one very easy thing,
being able to search across the different products
and projects and source code in order to understand
risks, security issues, opportunities to reuse
software, et cetera. These things are very important. Another thing that you obviously
need and don’t often have, especially if you’re
in a managerial role, is insight into who does
what in the company. Now again, this is no joke. I mean, if you’re managing 1,000
or 2,000 or more developers, it’s very important to
know what people are doing. And sort of getting companies
to real time is a big challenge. So being able to
understand what people do and then spotting and
developing and helping talent much the way maintainers
do in open source projects is a very good opportunity. And of course, the
last thing today you could argue software
being a very imperfect world and science to some extent,
speed is very important but also the ability to be
resilient and change things and move fast is a goal
for many operations that are software companies. And of course, many
companies, banks insurance, production of cars, et cetera,
these companies in the past have not moved that fast. Some of the reasons are their
customers don’t want that, or they have many reasons. But in the end– and today especially– there’s
no reason for any company to be slow anymore, especially
if you have GitHub supporting all of the DevOps
infrastructure that we’ll need. And we’ll talk about that. So the first thing I would
say insight and learning, from open source is, how do
you build software products? Now again many
organizations are structured around business lines different
sort of IT conventions. You have a database department. You have a security department. You might have Q&A, which is
separate from those as well. And one of the things
and the learnings I think we can draw on from the
last 30 years of open source is that that
doesn’t really work. You need an integrated product
team with the skill sets that are sufficient, first of
all, to build the software. , That’s not only coding. That’s also we’ll get into
that– a lot of testing, QA, and of course, the operational
part of it as well. And those product teams need
to be managed as if it’s really a multi-dimensional– what’s the right word–
sort of different skill sets put into one organization so
that the team can operate. And again, this is not
just about technology this is more about how do you
organize your teams to how do you organize your
developers to take advantage of the technology platform
that GitHub brings to bear. Now you might have seen it
today this morning, et cetera. A lot of even the new
things that GitHub is doing is really focused on
bringing the power to these teams and the
operational capabilities that they have to
deliver software. Another thing that’s again,
just based on my observation and work with some
large organizations is that often even if they
have a team or people that are good at things,
they are often not organized in a way that lets
them bring that capability to bear on any
specific product– by the way, even if
they’re not working on that product themselves. So community of practice
is a methodology, an approach to
building competencies inside an organization
in a way that’s orthogonal to any other
hierarchical structure that you may have. Why is this important? Again, today, we have a
lot of new technologies that affect the way you
build and deliver software. I’ll just give you an example. Docker might be a good one,
or cloud might be another one. And having people
that you know like to go home and look
at these things and do things when they
come back to the office. Why not organize
them into community, support those
communities, give them some cookies, or some coffee
and a place to do stuff? It’s not that hard, but
I think the main thing is that, especially on
GitHub and especially the way you can build
communities using GitHub, these practice
communities help really drive a lot of the new
inventions and the way you experiment with
deployment systems. So please look into that. Next thing it was
again observation. Let’s face it, a lot of
so-called IT organizations or big enterprise
production departments are really managing projects. Oftentimes, you find that
people are not that familiar due to other job responsibilities
with the software stack that developers are using. GitHub gives you
a very unique way of being able to interact
with the technologies with the software. You can set things up. It can be highly automated. We’ll get into that. But the good news is GitHub
is a platform that also makes learning by doing a very easy
task to get into, especially for people that are
not day-to-day involved in a project. And open source has really
made itself, evolved almost like an animal evolved to be– you want people to do
stuff for your project. It has to be easy to get into. For instance, in ORY, we
have a five-minute demo, and we really time it. So you can go there. You can look at everything. You have all the tools. We use Docker to deploy it. Similar things inside companies,
even with all the security, firewalls, et cetera, you have
new opportunities to do things. And learning by doing I
think is a very big benefit of having, for instance,
GitHub Enterprise deployed. The next thing you want to be
very cautious about, I think, is collecting data,
but you want to also be very ambitious about
the amount of information you can collect over time
because, one, you help teams by getting that information. Two, GitHub gives
you a lot of things that you would
not otherwise have as an actor in any
kind of organization. So one of the nice things
about GitHub repositories, as an example, is
you can see the build health of any repository. You can also collect that
data and make that publishable to other people that might
be involved in the process. Now a lot of companies do this
on a very sort of siloed way. And I think the advantage
of a tool like GitHub is you’re able to
really look at this data in a consolidated view
across the repositories. Now when companies deploy
GitHub in the beginning, again, as I mentioned, you’re
not starting from scratch. You have subversion. You have Bitbucket. You might have PBCS– some type of environment that
you would have been using prior to deploying GitHub. And all of those
environments also come with their own
sort of data set and the way they
manage configuration. So creating something that’s
consolidated in GitHub will take a little bit
of time and energy. And let me just explain
some of the things that I’ve seen companies do
one thing that, again when you’re deploying new platforms. You have often the opportunity
also to insert new processes and new ways of working. GitHub, as an example,
keeps the whole idea of working in parallel
that’s manifested in GitHub is designed to let
teams work very fast but also keep sort of in sync
with branches, et cetera. So pull requests become a
very new and important dynamic for companies and
especially teams in order to augment their
day-to-day work without getting left behind. So how was it before GitHub? It was you checked
out some code. You did some stuff. You were a little bit nervous. It didn’t build. So you didn’t really
want to check it back in. So you went for a week or maybe
more of basically frozen code in a repository on GitHub
and now, of course, for Linux was really disastrous. So that’s why git
became a tool that led to a lot of people
work in parallel ways without needing to create
what we would call a long pull request, long transactions. So instead, one of
the, for instance, data points you
might want to look at is the velocity of pull requests
across all repositories. This gives you also a
sense of other things that you might want to look
at and try to help teams with. As an example, you find people
that move from Subversion to GitHub in companies. They used many different
deployment systems, and they might have 10,
20, 30 repositories because of that deployment
infrastructure that they’re using to
operate their product. And one of the things that
I think big companies that are mostly software companies– Facebook, as an example– they really learned how to
build mono repositories. So you can consolidate all of
that code base into one place and then basically datafy
that whole repository and give the entire
flavor of what’s going on to people that
are potentially affected. They could be SREs. They could be DevOps. They could be just programmers
or managers, et cetera. But you want to be able
to give the entire dynamic of a repository and
an infrastructure to everyone affected by it. And so GitHub Enterprise
or GitHub the product gives you some opportunities
to collect and analyze data around that. Now the other good thing
about the GitHub system is that there are
many other, obviously, open source products
but even any products that are hooked into GitHub and
give you additional information and data about what’s going
on in the product development. So as an example, if
you’re using Coveralls for code coverage or if you’re
using Cyprus for integrated testing, you have quite
a lot of data points that you can then bring
back into some system. Things like Prometheus then give
you a bigger infrastructure, Grafana found for
operating on that data. All those things are
built using GitHub and have a very good interface
with the rest of the GitHub APIs and services. That’s really what you
need to do in order to start automating things. So automation, of
course, depends on data. A lot of companies today
have elaborate Gardner group based reports on RPA, Robotic
Process Automation, and all this stuff they want to do. And you look at it. And today, I mean, again,
going into some companies– it just seems like, well,
isn’t that what you’re doing? Isn’t that software development? I mean, you’re
taking this process. You put some stuff into Excel. You fill out some forms. You put it on a website,
and then you check it and see if everything’s OK. And you need a scripting
tool to do that. Well, the problem is, again,
but automating processes when they get disjuncture
from what else is going on in the business, it becomes
by itself a future time bomb because that
becomes something that’s hard to maintain, et cetera. So one thing about automating
processes and one thing’s important about getting
GitHub into your enterprise is that you have to go all in. And believe me, I’m
very radical about that. Everything goes and GitHub
or else you don’t do it. The reason for that is
then you have visibility– again, search, talent,
et cetera– but you can also augment the data with
new processes, new scripts, and look at all the
stuff that’s coming out, console, Terraform, all of
the deployment technologies. Imagine now applying
them in your company and being able to automate
many things that people do. Compliance– there are people
in the financial industry, in banking, insurance, food
production, et cetera, step by step by step by step,
they have to check things. And it’s not just
seat of your pants. That’s good. We all benefit from that. But you need an
infrastructure that helps you implement the
compliance over time, and GitHub can also do that. Why? GitHub creates audit trails. GitHub lets you go back and
forth, almost along a timeline. GitHub produces the
interface, the testing tools. GitHub also produces
the interface to Jenkins or
Circle CI or Travis. Having all of those
things integrated gives you a much better
data set about compliance than you would get by asking
two guys in the compliance department to take a
look at this repository. So believe me,
automation of compliance is a very big opportunity
that companies have today when they deploy GitHub Enterprise. And by the way,
we’re not talking in this slide about
deployment, but you want to basically automate
almost everything possible. And think about open
source projects. In order to really get people
excited about any open source product, they need to
be able to see it work. Really, the automation needs
to be in place in order for the audience to
have immediate feedback about their contributions. And I think companies
more and more are coming to that
point where even developers and other parties– again, integrated teams, product
teams, people from marketing– also want to see stuff work. And I think that’s important
for integrating and working with the GitHub
Enterprise infrastructure but also just getting
that community of people that you need involved in
more and more products. A lot of companies
talk about this today. They want to interface
with customers. They want to
understand customers. But really, isn’t that part of
a bigger issue which is they don’t really understand
the products they produce? And they can’t because they
don’t get the visibility. They don’t have the contact. They don’t know where
to go to ask people. Even the website,
a lot of times, today, even in modern
companies, it’s very seldom that you can
just call up someone, say, how does this work? I’m on a chat system. I have a call from a
customer– so bringing the community aspect of GitHub. Again, I don’t know
I saw $36 million today if that’s right or wrong. Let’s say it is right. So lots of people
are in a community across the globe that are
working on one infrastructure. Think of getting everyone in
your development in GitHub on an enterprise. So first of all,
this sounds strange, but it’s not strange
if you’re in a company. You can communicate with someone
that you didn’t know that works in another department. You don’t need to send
an email to his boss and ask him if it’s
OK to talk to him. You can do everything
in one GitHub community. And I think that’s
super important. The other thing is, again,
when you’re automating and when you’re using
DevOps, many tools you have the whole repository build up
and tool integration that you can do in one place, which makes
it much easier for companies to see what they’re
doing across the board. But it also makes it easier for
maintainers inside your company to get the automation effects
that they would otherwise be expected to have
from implementing a system like GitHub Enterprise. Again, tool chain– look,
we’re in a probably, again, one of the best areas
I can imagine in software. I’ve been doing this
for 30 years or so. There’s so many new tools. There’s so many people building
stuff, individuals, open source teams, small software companies. Everyday, more or less,
you get something new that comes out that you
want to look at and try out with your software. The GitHub community, the public
GitHub community, I think, is very ambitious about
embracing things and testing things. And by the way,
if it’s not good, you get your teeth kicked in. Peer review is
extremely important, and it should be happening
inside your company as well. You should be able
to without having a lot of questions asked to
have an infrastructure where you can make a contribution. As a software developer,
you’re honestly one of the most important
pieces of employment that the company
probably has today and getting and keeping
you and making you happy is extremely important
for every business because software really
is eating up the world. So having this capability to get
new things and new inventions, be able to try them put
them in a GitHub tool chain, on a DevOps tool chain,
and having that capability to interact with
the system gives you a whole new way of working. And I think we’ll see
in this era of software that that’s really a
good thing for business. And by the way, you
have a proving ground of now 36 million people
that have tested this and see that it’s actually OK. To get the big benefits,
though, the big bang out of a lot of
these things you need to be able to get to real time
from a business standpoint. What does that mean? That means you need to be able
to implement communication infrastructures that
don’t work on email because email kills
almost any good idea. It’s bad for
software development. It’s bad for
software developers. It’s also cumbersome. It tends to reinforce
unnecessary hierarchies in business. And most of the time, it’s
just a pain in the ass to read. So you have all this email,
and you want to do your code. And instead, you
have stuff to do that’s disjunct
that’s out of sync that was yesterday’s problem. And that’s called email. In order to get
your developers– and this is very important part
of integrating with GitHub– is to get the information
that GitHub produces into your company in some way. A lot of people
probably use Slack. I’ve used and implemented
Slack in numerous companies. It tends to be a very big
moment of truth for businesses because they thought they
knew what they were doing. And then they implemented
a system like Slack. People start
building communities because they’re
allowed to do that. They get information that they
otherwise wouldn’t have had. And they can do it
all very quickly, and they can operate on that
information in a way that’s also archived and synchronized. So first of all, you
can do every automation from GitHub in Slack. So everything, every time
you do a pull request, every time you do a release,
all that information can be provided via
robots into Slack. If you’re dealing
with customers, Slack also helps you do that. Slack is not part of the
GitHub Enterprise platform just to make that clear. It’s part of another
platform that’s revolutionizing the way
companies and employees and companies communicate. One thing that Slack
does do though is it gives you also branches too
and capabilities or channels to work with companies
that you would partner with as a
business or customers. At ORY, we use Discord to
communicate with our developer community. Discord, for those that
haven’t heard about it, is popular in the
gaming community. It’s extremely targeted, I would
say, to that type of community. But for us and working
with software developers around the globe
that are in ORY, we find it a very good way
to get immediate feedback, real-time information
about what’s going on with the
software we built, and the customers and
community of contributors that we want to connect with. Those are just two examples. There are other things
out there that are able to facilitate and help. But I think a very
important thing when you decide to go
with a platform like this, be realistic about the
real-time opportunities that companies like
GitHub platform will provide to your business. And then you have to really
exercise on doing that. So it’s a change on
many different levels. And by the way, it’s just
like websites and blogs. Managers also go on Slack,
and they have channels. And people can read the
stuff that they talk about. But they can also
get some advantages by seeing what developers
are doing, what’s deployed, what customers are
saying, et cetera. Again, that gives the
whole company a way of getting feedback and
in some sense, a way of interacting with customers. I’ve been around quite a long
time in the software area. And I don’t think you really you
can do and build great software by just asking customers
what they want. I don’t think that’s really a
great approach because software by itself is art. It’s not science. It’s something that you need
to think about, imagine, and create. But feedback helps,
especially if something’s broken and especially if
you want to get information about new features
that you thought of and creating a
scenario and a system. By the way, using
GitHub maybe even using a public GitHub repository
outside of your enterprise gives you a capability and
gives customers a capability of working together. I’ll just give you an
example, a year ago, I was helping a big organization
with their data infrastructure and helping them build
a public data set. OK, and to build a public
data set is not trivial, but of course, in
this case, it was built with one of the
let’s just call it bigger cloud, cloud
infrastructures. Now in order to work
with that cloud company, we needed to have a
way of giving them the capability of cooperating
and developing and testing all the source code and some
of the data that was provided. And every day, the
teams could get feedback from each other,
what was working. They would try stuff. They are located in Seattle– doesn’t matter. They could try stuff
in their office. We could do stuff
here in Germany. And having that interaction
and that sort of way of working was extremely effective. And GitHub was
the base for that. And I can say honestly there
wasn’t even a discussion. We had one phone call. We set up the project. We got everyone on GitHub. Everyone already had
their GitHub users. The company isn’t
Microsoft, by the way. So this is, again,
how developers work. And how you get
interaction and feedback for new software and
new inventions today depends a lot on your ability
to structure things and work with things and get your
company involved in that. Now, we talked about compliance
we talked about security, but let’s also just
talk about mindset. The single biggest challenge
that every company has. It’s not technology. It’s not policies. It’s the way you
think about things. And letting employees
work in a way that where they can collaborate
with Google or Microsoft or GitHub and do stuff
and exchange information is very, very difficult for
Joe Manager to understand why does that work. I might lose my job if somebody
provides the wrong information that mindset is
not going to change because you implement
GitHub Enterprise or any other technology. But that mindset will
change because you’ve changed the way you
work, and the potential to work in new ways is a
highly an effective way of shifting the thought
process in companies. So that’s a benefit that you
would get from implementing this whole infrastructure. So when I say that that’s
because the silos and companies are built around
politics power money, not technology, not
software, not developers. So some of these structures that
you want to break down you also need structures to break
down the old structures. And one of the things I
think I would encourage along with the implementation
and rollout of intersource, in general, is to really have
a dedicated product development lab. Now everyone here knows
you can do that virtually. You don’t need to go ask
Joe Manager for a budget or get some permission
from someone. You can set up a lab as part of
an organization inside GitHub and then get people to come
and collaborate on new things. Let me give you some examples. New programming
languages, you want to set up an infrastructure
with JavaScript and have some simple
apps deployed. Oh by the way, my
manager wants to see how you program an
app on the iPhone or program an app on any phone. Just simple things
where you can then get people to come, show, push
this button, look at this code, make it change to a pull
request, try this out. It’s not going to break anything
customer is going to see this by getting people in this
lab and teaching them how to do things
is a critical part again because of
the mindset, because of the fact that we
don’t have the luxury and business of going
back to school every day. I think that’s a shame. I think people should
be learning much more. But again, using this
infrastructure to set up a lab and give people the
permissions is important. When you implement
GitHub Enterprise, there are many
different ways to do it. I’m speaking here from
my own perspective and experience make
one organization. Don’t try to make
the organization that was there today or
was there yesterday– don’t try to implement that
organization and GitHub because you’ll fail. You’ll fail because the
benefit of intersource and getting to intersource as
a sort of business philosophy requires you to open up
the whole kimono, now you might have
some secret sauce. If you’re Coca-Cola
or whatever company. And you can protect
different repositories, but the benefit of implementing
new types of software production platforms is that
you get maximum involvement from everyone in the company. Even people that don’t do
software should be on GitHub. And the reason for that is
they can do other things. They can write documentation. They can write customer stories. They can add things,
including issues. They can look at how
the software is working, Don’t look at GitHub
Enterprise and intersource in general as an experiment
that you use to reduce cost, big mistake. Look at this as a
way of all-inclusive changing the philosophy about
how people view and look at your software today. Again, just one example– a lot of times,
companies can’t maintain the software they have. The reason for that
is they have people that worked on that software
that are no longer alive or no longer in the company. So giving those
repositories an option to have other people look at
it– and I’m happy to admit I developed stuff
on the mainframe. I can look at that
today and still make some assessment of whether
it can be changed or not. A lot of companies
have opportunities to open up what they’ve
done in the past to their current employee base
and gain information from that. So thank you very much. I hope that that
was helpful for you, and I look forward to
being around and talking to you about any of the
topics here or, of course, my favorite topic of today ORY. And I have even brought
the whole company with me in case you have some
security and API challenges that you want discuss as well. Thank you very much. [APPLAUSE] [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *