How we made the Jenkins community
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 90 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/40296 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSDEM 201345 / 90
2
5
8
10
12
13
14
15
17
19
21
24
25
28
29
31
32
34
36
39
40
43
44
46
50
51
52
54
55
57
58
62
65
66
67
78
79
87
88
00:00
BitECosRight angleProjective planeProduct (business)Line (geometry)Lecture/ConferenceMeeting/Interview
00:39
Java appletDisintegrationServer (computing)Plug-in (computing)Radio-frequency identificationSoftwareWeb applicationJava appletSoftwareProjective planeDigital rights managementContinuous integrationMultiplication signOpen sourcePlug-in (computing)QuicksortBitInstallation artFIESTA <Programm>Water vaporView (database)Selectivity (electronic)Physical systemUsabilityComputer animation
02:27
MathematicsTelecommunicationPatch (Unix)Software testingLine (geometry)Different (Kate Ryan album)Thermal expansionCharge carrierData structureOpen sourceTelecommunicationProof theoryGoodness of fitPatch (Unix)Software testingContext awarenessQuicksortProjective planeDifferent (Kate Ryan album)Data structureCodeComputer programRootFormal languageMathematicsMultiplication signTime zoneTerm (mathematics)Presentation of a groupCodeOverhead (computing)Direction (geometry)DemosceneForcing (mathematics)Bit rateGroup actionStatement (computer science)Extension (kinesiology)ChainHypermediaRight angleImplementationRoutingOnline helpLecture/ConferenceComputer animation
06:49
Module (mathematics)Game controllerLevel (video gaming)CodeMaxima and minimaTelecommunicationDemosceneSoftwareFood energyModul <Datentyp>Goodness of fitProjective planeQuicksortOverhead (computing)Endliche ModelltheorieDesign by contractLecture/ConferenceComputer animation
07:30
Radio-frequency identificationFreewareLibrary (computing)SoftwareModul <Datentyp>Level (video gaming)QuicksortMultiplication signLibrary (computing)CodeExtension (kinesiology)SoftwareWordCASE <Informatik>Projective planeOpen sourceComputer programCartesian coordinate systemForcing (mathematics)Revision controlLecture/ConferenceComputer animation
09:10
SoftwareLibrary (computing)Extension (kinesiology)Point (geometry)ImplementationInternet service providerCore dumpArithmetic meanINTEGRAL1 (number)CodeExtension (kinesiology)Core dumpMereologyPoint (geometry)Run time (program lifecycle phase)Plug-in (computing)InfinityInheritance (object-oriented programming)Endliche ModelltheorieJava appletFormal languageSet (mathematics)Structural loadSoftwareMedical imagingComputer programCellular automatonProjective planeSpeciesView (database)System callSocial classProduct (business)TunisObservational studyDesign by contractWebsiteStrategy gameExpressionLecture/ConferenceComputer animation
11:35
Data modelExtension (kinesiology)Public domainCore dumpObject (grammar)Inheritance (object-oriented programming)MathematicsFunctional (mathematics)Core dumpHypermediaTouchscreenIntelEvoluteWeb applicationDatabaseExtension (kinesiology)RandomizationProcess (computing)Data modelMereologyDesign by contractProjective planeRevision controlPublic domainMobile appElectronic mailing listImplementationPlug-in (computing)Object (grammar)DemosceneGoogolExpressionLogicSelf-organizationData structureVotingArithmetic meanGoodness of fitNumbering schemeStaff (military)Observational studyWordCASE <Informatik>Lecture/ConferenceComputer animation
14:04
Inheritance (object-oriented programming)MathematicsExtension (kinesiology)Code refactoringRadio-frequency identificationPoint (geometry)MereologyLogicWeb 2.0Game controllerContext awarenessInheritance (object-oriented programming)Polymorphism (materials science)Revision controlRight angleTurtle graphicsExtension (kinesiology)MereologyDesign by contractSocial classPoint (geometry)Virtual machineProtein foldingQuicksortToken ringPatch (Unix)Code refactoringFunctional (mathematics)Core dumpWordCommitment schemeFactory (trading post)Cycle (graph theory)Multiplication signThermal expansionProcess (computing)Field (computer science)Lecture/ConferenceComputer animation
16:48
Modul <Datentyp>Division (mathematics)Product (business)Web serviceSystem callProjective planeSign (mathematics)Interpreter (computing)Royal NavySet (mathematics)QuicksortResultantIntegrated development environmentForcing (mathematics)Module (mathematics)Design by contractVideo gameProduct (business)Labour Party (Malta)Game theoryStructural loadBitBoundary value problemSoftwareCompass (drafting)Point (geometry)Film editingRepetitionDivision (mathematics)Cartesian coordinate systemModul <Datentyp>Web 2.0CodeWage labourRun time (program lifecycle phase)Extension (kinesiology)Group actionImplementation
18:48
Modul <Datentyp>Division (mathematics)Product (business)Core dumpData structurePlug-in (computing)NumberPoint (geometry)AbstractionDesign by contractMultiplication signCore dumpCASE <Informatik>Endliche ModelltheorieProper mapBitCategory of beingSpeech synthesisData structureComputer programParticle systemFamilyQuicksortMassModule (mathematics)SummierbarkeitServer (computing)Lecture/Conference
20:10
Core dumpData structurePlug-in (computing)Modul <Datentyp>TelecommunicationFunctional (mathematics)1 (number)Server (computing)Web crawlerTelecommunicationFeasibility studyMaxima and minimaExtension (kinesiology)Lecture/ConferenceXMLComputer animation
20:48
ForceBoundary value problemCodeAeroelasticityPlug-in (computing)Computer fileSoftwareMereologyWebsiteDesign by contractContext awarenessSheaf (mathematics)QuicksortBoundary value problemPersonal area networkForcing (mathematics)TelecommunicationCollaborationismModule (mathematics)Extension (kinesiology)Computer animation
21:49
Boundary value problemForceCodeAeroelasticityPlug-in (computing)Computer fileCodeAbstractionDesign by contractVideo gameMereologyComputer fileCycle (graph theory)Projective planePlug-in (computing)Physical systemLecture/ConferenceComputer animation
22:36
Boundary value problemForceCodeAeroelasticityPlug-in (computing)Computer fileTrailSpeciesCodeCASE <Informatik>QuicksortExtension (kinesiology)NumberDifferent (Kate Ryan album)DivisorLecture/ConferenceComputer animation
23:31
ForceCodeAeroelasticityComputer filePlug-in (computing)Data modelPlug-in (computing)Line (geometry)CuboidSoftwareNumberBit rateComputer fileRight angleQuicksortInternetworkingProcess (computing)Software developerLecture/ConferenceComputer animation
24:53
Data modelCodePoint (geometry)SharewareSoftware testingTest-driven developmentComputer programPatch (Unix)CASE <Informatik>Different (Kate Ryan album)Correspondence (mathematics)Multiplication signSoftware developerMusical ensembleLecture/ConferenceComputer animation
25:54
Data modelCodeHill differential equationCodeSummierbarkeitProjective planeIntegrated development environment1 (number)Moment (mathematics)State of matterImplementationMereologyLecture/ConferenceComputer animation
26:37
Ideal (ethics)CodeObservational studyProjective planeTerm (mathematics)Contrast (vision)State of matterDisk read-and-write headOpen sourceFilm editingProcess (computing)QuicksortRight angleCodeComputer programBitTelecommunicationSoftware developerComputer animation
28:27
ScalabilityCore dumpMechanism designIntegrated development environmentMereologyOrder (biology)Sensitivity analysisObservational studySoftware developerCore dumpError messageIntegrated development environmentNumberPlug-in (computing)Computer programProcess (computing)DemosceneForm (programming)FlagClient (computing)Lecture/ConferenceComputer animation
29:19
Torvalds, LinusRadio-frequency identificationRollback (data management)Core dumpComputer programNumberSoftware developerPlug-in (computing)Online helpArchaeological field surveyDifferent (Kate Ryan album)Data conversionCommutatorMereologyVapor barrierRight angleProjective planeArithmetic meanSpeech synthesisRobotLecture/ConferenceComputer animation
30:42
Radio-frequency identificationRollback (data management)Metropolitan area networkMultiplication signIncidence algebraControl systemMereologyPoint (geometry)ComputerLecture/ConferenceComputer animation
31:18
Torvalds, LinusRadio-frequency identificationRollback (data management)Point (geometry)MereologyIncidence algebraControl systemComputer programInformation securityCASE <Informatik>Plug-in (computing)Projective planeMathematicsSoftware developerDifferent (Kate Ryan album)Denial-of-service attackComputer virusState of matterRadiusLecture/ConferenceComputer animation
32:24
Torvalds, LinusRadio-frequency identificationRollback (data management)Plug-in (computing)Plug-in (computing)Vapor barrierQuicksortRepository (publishing)Open sourcePower (physics)Lecture/ConferenceSource codeComputer animation
33:12
Plug-in (computing)FlagPlug-in (computing)Software developer1 (number)MathematicsProjective planeMultiplication signKey (cryptography)Right angleLecture/ConferenceSource codeComputer animation
33:56
Food energySet (mathematics)Task (computing)BuildingPlug-in (computing)MassTelecommunicationJava appletQuicksortMereologyGoogolExtension (kinesiology)Universe (mathematics)Level (video gaming)Observational studySingle-precision floating-point formatForcing (mathematics)GravitationProcess (computing)Lecture/Conference
35:03
Open sourceGravitationSingle-precision floating-point formatMathematicsQuicksortSource codeCodeRepository (publishing)Projective planeForcing (mathematics)Core dumpMiniDiscRight angleComputer programLecture/Conference
35:53
TwitterMultiplication signWater vaporGravitationProjective planeProxy serverOpen sourceData conversionDebuggerComputer animation
36:31
TwitterDrop (liquid)Event horizonBlogData conversionGravitationContext awarenessDigital photographyBlogCodeProcess (computing)Software developerWater vaporTwitterArithmetic meanSmoothingStorage area networkLecture/ConferenceComputer animation
37:44
Drop (liquid)Event horizonBlogTwitterPlug-in (computing)Covering spaceCodePlug-in (computing)Projective planeGravitationUser interfaceNetwork topologySelf-organizationLecture/ConferenceComputer animation
38:45
Data structurePoint (geometry)Staff (military)Office suiteForcing (mathematics)Software maintenanceSoftware developerGravitationExpected valuePlug-in (computing)Cycle (graph theory)Arithmetic meanRight angleLecture/ConferenceComputer animation
39:42
Plug-in (computing)GravitationRepository (publishing)MereologyProcess (computing)Cycle (graph theory)Mechanism designDemosceneRepository (publishing)StatisticsCodeMultiplication signGravitationTerm (mathematics)Patch (Unix)Software maintenanceSource codeGame controllerStaff (military)Control systemLecture/ConferenceComputer animation
41:25
GravitationRepository (publishing)MathematicsRepository (publishing)Patch (Unix)Projective planePower (physics)Arithmetic progressionGoodness of fitDynamical systemSoftware developerComplete metric spaceQuicksortLecture/ConferenceSource codeComputer animation
42:37
Reduction of orderTelecommunicationMultiplication signGoodness of fitElectric generatorSensitivity analysisPhysicalismEstimatorComputer fileForm (programming)Office suiteSoftware developerCodeExtension (kinesiology)TelecommunicationScaling (geometry)Open sourceLecture/ConferenceComputer animation
43:30
Reduction of orderTelecommunicationExtension (kinesiology)YouTubeLecture/ConferenceComputer animation
Transcript: English(auto-generated)
00:00
So I'll just leave it here. So with that ado, I'd like to get started. Our first speaker today is known as KK, which I think is a bit easier to say. But how do you pronounce your own name? Yeah, OK. So my name is Kosuke.
00:21
That's actually my name in Japanese. Right. And he's going to talk to us about the Jenkins community. OK. Thank you very much. So I'm Kosuke. I'm from the Jenkins Project. I guess I'm the creator of the project. I don't know how many of you here know what Jenkins is.
00:41
So thank you. Well, just briefly, it's a Java web application that's used for automating builds and tests and all kinds of other things. And in software like this, it's typically called Continuous Integration Server. It's under MIT license, and it's been around for about eight
01:03
years. So it's all in all, it's a pretty popular project nowadays. We track about 53,000 installations around the world. And to enrich this ecosystem is the 600 plus plug-ins that's developed by more than 500 people around the world.
01:21
And then that puts us the most adapted Continuous Integration Server in the market. So while in this conference, there's a lot of big open source projects. So I guess perhaps it might be a bit arrogant to ask ourselves why Jenkins was able to come this far.
01:40
But I guess I'd like to think that the Jenkins has obtained certain amount of adoption, which I'm very proud of. And there's obviously the usual things that I think contributed to this success, which is actually producing the software that works, at least most of the time, or simply being at the right place at the right time.
02:01
I think there is definitely that aspect as well. But at the same time, I'd like to think that there are certain key ingredients in the way we created the community that sort of is, in my view, broadly applicable to other open source projects. So my goal here today is to talk about some of the things
02:21
that I think really worked well for us in the hope that the people here, presumably running your own open source projects, would be able to pick up some of the ideas. So I think the whole thing, the way we design communities, start with this realization is that the communication
02:43
is inherently painful. The fact that I'm struggling to give this presentation is proof enough that the communication is painful. But if you think about how the contribution to the open source project typically works, it goes something like this.
03:01
If you're working on any non-trivial change, you're probably forced to ask the people running the project to see if they are willing to take it. And then you have to sell the idea that why it's useful beyond you and whatnot. And once they are OK, you actually have to start working on the change. And then once the code is done,
03:21
you have to also defend that patch. There are different things people can do to implement the same thing. Maybe the project wants you to write the tests and documentations. You might have to give in certain aspects to rewrite some of the patch, because the existing community didn't like some aspects of it, even though it might be working OK for you.
03:41
So all in all, it adds to a lot of work. And then know that some people get dissuaded from all these things that they have to do to get what they want to do. And beyond that, I think the programmers are very picky people. There's all sorts of things that can go wrong when we try to communicate.
04:02
Sometimes it's simple things like the indentations and coding conventions. And I know some people get really upset when the patch doesn't follow these things. But there's also lots of things reasonable people can disagree about in the design, how they anticipate the future extensions, whether they think the performance is important
04:21
to trample over the cleanliness of the code and so on. So again, all these things adds up to the additional overhead when you're talking about having other people contribute. And negotiating this kind of thing is painful enough even when you know the people that you're working in, like in the corporate setup. But it's downright impossible when you have to work
04:43
in the context of the open source project when you just don't know each other. We don't have any context around us outside the coding. We don't know what food they like, we don't know how they look, we don't know how many children they might have, and so on. We sometimes don't even have common goals.
05:03
We might have some rough ideas about where the project should be, but people might have disagreement over this. We definitely don't have any command structures. We can't simply tell someone else to do something, even as I lead in the project, I don't get to tell other people in the Jenkins community to do this or do that.
05:22
I have to sort of influence more carefully. And then on top of that, there's all these things like the time zone differences and language differences that adds up to the pain of the communication. So if I may make a bold statement, I'd even dare say that the communication is in fact the root of all the pains
05:41
or the old evil in the open source project. So in my mind, the less the communication is better, if you can get the same thing done with less communication, that's better. And so what we really sort of try to make happen in the Jenkins project is like what can we do to reduce the need for the communications?
06:02
It's a realization that we don't want to stand in the way between people who came up with the ideas to their implementations. If someone is crazy enough to invest their own time to implement some feature on top of, say, Jenkins, I'd rather just have them do it without me getting in the way in terms of the code, maybe,
06:21
or the design or the discussions. And I think it's also the realization that the innovations happen everywhere, not just among the existing community members. And so the least we can do is to try not to stifle them by forcing them to do more than they have to. So henceforth, I think in my mind, the question is,
06:41
well, we still want to be collaborating in the sense of generally heading to the same direction, at least similar directions. But how can we do that without forcing communication? Or how can we do that without, with as minimal communication as possible? So that's sort of what I really wanted
07:02
to put into the Jenkins project. And I think it start with the modularity, that is, when you have the large piece of software decomposed into smaller chunks that can be individually built and tested and so on, and then if these things are nicely, reasonably shielded behind the contracts,
07:20
then if each people can work within their own module, that certainly reduce the communication overhead. And then that's good. But this alone is not enough. But the reason I appreciate the modularity is because it gives rise to the extensibility, which is the main thing that I want to talk about today. It's sort of the modularity taken to the next level
07:42
where your code gets opened up to the rest of the world. And so that's how the other people could come in and then write stuff without you doing things. And if there's one word that I'd like you to take away from my talk, that would be extensibility. I think this really is the only thing that matters.
08:01
Because this is the one that enables all kinds of social tricks and engineering tricks that we put in the Jenkins project. I think as long as your project had some of these, I think you should be able to do the same. And we spend a lot of time doing this, creating this proper infrastructure to enable extensibility.
08:20
This investment was certainly not free, but it was definitely worth it. And as with everything else in the open source community, these things can come over time. You don't have to do everything in one go. But I think there's many facets to extensibility, so I wanted to sort of talk about some of these. I think the one that I think of, the first one that I think of is the programmability.
08:43
It's being able to sort of use any software as a library, not just by humans. That it's a realization that there's always a layer above your program that's trying to drive your program. And I think it's obvious for library projects because that's the main use case.
09:02
But for the applications, people seem to tend to forget that. The worst offender in my, like one bad example, one offender example that I can think of would be Gmail. They don't really let you tweak their UI. You can't really have the add-ons or anything that's working with Gmail. They might have IMAP integration, but that's basically it.
09:23
And another example might be the GIMP example. I mean, it's a graphic manipulation application, and it does have some command line capability, but it's not clearly known enough to the point that it gave rise to this whole software in the community known as the image model.
09:41
Another important part of the extensibility, I think, is this ability to load code at run time. It basically involves in defining some contracts, so these extension points that allows other people to look into it. And then that might be the abstract base classes. It might be a set of methods that have certain names
10:01
or whatever that is depending on languages. In some languages, this is really easy. Like, you know, the script in languages, loading code at the run time, it's like there's, I mean, every code gets loaded at the run time. But for some other languages, this is actually not as easy as it might sound, like, say, Java or C. And then ideally, we'd like to provide
10:21
some isolation between these. I think the offender that I can think of that does not offer the code loading capability would be the iTunes. You know, they have a programmability, but you can't really tweak the iTunes UI by having stuck into it. I saw in that sense, the thing you can do with iTunes is limited.
10:40
The other important aspect of extensibility, I think, is to treat extensions as the first-class citizens. The user shouldn't be able to distinguish between what's provided by the core versus what's provided by the extensions. In fact, it's so much so that in Jenkins project, if there's something that the core can do
11:01
that's not possible for plugins to do, then that's almost considered as a bug, right? So this, because this allows the, so the plugins to be essentially, we have the infinite amount of capability. So the, I guess the offender in my dictionary in this respect would be the Outlook.
11:22
So they do have the programmable API. They have the ability to load code at the run time. But the thing you can do in Outlook is actually substantially limited for the other ones. They can only add stuff into this, add in pain, not to any other ribbon bars.
11:41
So you can immediately tell which is the core functionality and which is not. And so it creates this discrimination between these things. And so that's, in my mind, is doing, not doing good enough. And yet another part of the extensibility is the data model extensibility.
12:01
So this is because the extensions need to be able to store the stuff, just like the core does. So in a way, it's a logical extension of the previous principle that I mentioned. You know, sometimes it's about adding additional data to the existing core domain models, like say, in Jenkins project, you can, if you install a GitHub plugin,
12:21
you can associate the GitHub project to the Jenkins job. So that's an example of storing things. And then also, the extension needs to be able to define their own domain objects, and just like what the core has. And this is kind of really tricky in many domains, like especially the web applications. And being a XML guy in my former life,
12:43
I find XML really useful here because the X in XML is extensibility. It's really good at storing this kind of random semi-structured data. And I think this, another place this imposes challenge, I think, is the database schema. You no longer have a linear evolutions.
13:02
You have all these core versions, and every plugin has their own versions, right? So managing the schema consistently is the versions of the plugin in place, I think, would be major work. About yet another part, I'm not sure how to sort of phrase this nicely,
13:21
I think it's the notion that you want to embrace the heterogeneousness of some things. Because if you have a good contract, a good contract should enable different implementations that satisfy the same bar. So often what people want to do is to take something that already exists and slightly tweak its behavior
13:42
to their case, and then make it something new that can be used with the rest of the software. And so, in other words, whenever we see a list, I see a list in something, you know, like I guess the apps in the Google apps. I mean, this is like the example of the heterogeneousness that we want to have.
14:01
We want people to be able to add one more thing in here. And if possible, by taking one of the existing stuff and slightly modifying it. And so that's where the inheritance had come into play. And again, I find it surprisingly tricky to get this right in many contexts. Like, you know, for example, in the web app, the controller logic normally doesn't really appreciate
14:23
this kind of heterogeneousness or the polymorphism. So providing a different UI for those different concepts and so on, it's not very easy. So this is one place, this is one of the places where I spend a lot of effort in Jenkins to make possible. And again, if you take these earlier principles
14:43
to the logical conclusions that the extensions are the first class citizens, you also need to make sure that the extensions by themselves could provide additional contracts to allow other extensions to fit into it. In other words, it's like the extensibility
15:01
all the way down to the virtual machine. So in Jenkins, to enable that, we provide an idiom that allows extensions to use it. That's the same idiom that the core uses to define extension point. And I think the part of this is cultural. We sort of, people aren't used to the notion
15:21
of defining these extension points unless sort of they are pushed into it. So we have to do some hand folding initially. And I think that partly this is a everlasting refactoring work. A good example that I can think of is in Jenkins, one of the functionality it has is whenever a new commit shows up in, say,
15:41
some version repository, we want to start a new build. And one day, a patch showed up that said, well, we have actually Jenkins making some commits, and so if those commits trigger a new build, it's gonna cause an infinite cycle, so we want to be able to ignore certain commits if that come from certain user.
16:00
Sounded like a reasonable request, so we added it. And a few months later, another part came along that, well, we like this idea of the exclusions, but instead of using username, we'd like to exclude certain paths. And next thing you know, somebody else came up that, well, if you have some tokens in the commit message, that's what we want to ignore.
16:21
And so pretty soon, we have like three or four different ways to exclude some commits. And then that's when we realized that, oh, this should have been the extension points. And so there's lots of these examples that initially we couldn't really anticipate that people wanted to plug things in. And so we still need to be able to do so after the fact.
16:43
And so continuing this effort would help you create this extensibility turtle recurgence. And while I still can't really put my fingers on exactly what extensibility is, that's why I had to resort to naming some of these key things. But it's also easy to tell what's the sign
17:02
of the fake extensibility or the fake modularity, as I call it. The first one, I think, is that the division of labor alone is not enough of a modularity. I see that in most of the big projects, in any non-trivial software project,
17:22
you have more people than say, you have multiple people involved in the project. So they have to divide up the labor, which means certain kind of, well, the contract would have to emerge between those people's boundaries. But that alone does not create good enough modularity, because what often happens is that you end up
17:42
creating this contract that actually custom paid off it, just for these two modules, that does not possibly allow any other implementations. So again, I used to work on one of these large projects in my previous life at Sun Microsystems. And I was in this group that does the web services,
18:01
and then there's the people doing the, the initialization sequence, the load application code. So we have to fit into the web app, the web services initialization to what they do, so we have to develop some contract. But the end result is that the contract that we created was really just for the web services,
18:23
and it couldn't be used for any other purposes. And that doesn't really, that just doesn't cut it. And I think, come to think of it, I think one of the things that fosters that kind of the environment is sort of the implicit assumption that you have this fixed set of modules that becomes the final product,
18:43
that no one else is not adding anything at the run time. Right, because if the whole thing consists of a certain known number of modules, and then if, you know, if you know these people, then they are the one that you're working with, then, I mean, you start to, you fail to see the point of defining
19:01
these general abstract concepts of this contract that goes actually beyond what you might immediately need. And so you end up just creating something that works between you and the other guy in the other side of the corridor. So in Jenkins, the way it works is we have a core
19:22
which sort of creates the bare-bone structure of being a CI server. Unfortunately, it's still pretty big, so that's why I put the sum there. I wish this was smaller and all, but I think this, as is the case with most of the other software,
19:41
initially Jenkins wasn't particularly extensible, right? So I mean, these things came over time, so by then we had sufficient amount of accumulation that prevented us from proper modulizations. But at the same time, internally this big chunk of mass is actually divided up into smaller pieces, they're called modules.
20:01
And then technically speaking, these things are the same as the plug-ins, it's just that they cannot be uninstalled. But around the core, to live over around the core are the planets, that's the 600 plus plug-ins. And these are the ones that actually provide
20:20
the functionalities that's useful for the users. And then that's what makes Jenkins the CI server. So, I think with that kind of gimmick, I think I'm ready to answer the question that I posed out here, that is, how can we collaborate with as minimal communication as possible?
20:40
And without communication, it's even feasible. And that is to create all these silos, and then that's harnessed by the extensibility. We want to divide everyone up into the small sandbox, their little silo that they are happy with, but somehow they can be put together to form the whole software.
21:01
And normally the silo, I think, is sort of forked in the context of something bad, but I'd argue that the silo equipped with extensibility is a good thing, because first, it sort of forces the contracts at the boundary, which is one of the foundation for enabling collaboration with that high degree of communications.
21:23
When you have, when individual silos are small enough, it becomes a lot easier to keep the generalized contracts that prevents these custom-picked module contracts that only work between two guys. And this is, I guess it's a manifestation of the principle of the continuous X things.
21:44
If you find something painful, you just do it frequently enough and often enough, and then it becomes a part of your work, part of your daily life. So if the defining contract or defining abstraction is too painful, you just do it all the time, and then do it at every possible boundaries,
22:02
and then that makes it easier. And of course, the smaller code, when you have an individual silo that's smaller, the smaller code is easier to work on and easier to hack. Most of the Jenkins plugins would probably consist of less than a dozen files, and each of the files aren't particularly big. So for someone new to the Jenkins ecosystem
22:22
that's thinking about faking the behavior of certain things it's a lot easier to look at, say, five files as opposed to like a massive 500-file project. It's just easier to comprehend, easier to build, easier to test, easier to run, and so on. I think the another important aspect of creating silos
22:43
is that it allows you to sort of embrace all these special use cases. Without sort of clattering the general purpose code. I think that one of the reasons that people have to discuss about the future designs is because there's always this tension between these special use case
23:02
that only serves small number of people from the general things that should be kept. And so when we could accommodate these special use cases in a different silo, and then only those who need it is gonna use it, then it eliminates one of the reasons
23:20
why you need to have such a heated discussion about what's to be added in the future. So if you didn't have the extensibility in Jenkins, adding these half a dozen different ways to exclude commits in the subversion plugin might not have been feasible, because it clatters the UI and the whole thing,
23:41
but by allowing people to move them off into separate plugins, we could accommodate them quite all right. So it makes everyone do what they wanna do. It allows us to get out of the way. People can do what they wanna do, and then still use the rest of the stuff. And so in this way, we can enable the niche features. And I think that most of these 600 plugins
24:02
only have a small number of users, but for those people using it, it's a critical piece of the plugin. And so that's what we want. That is, in any large software, you want people to be able to fill the gap between what they'd like to do versus what's capable. And then we want to enable that
24:22
besides asking them to clatter the otherwise general purpose stuff. And this extensible silo, I think, requires less communications, because every developer gets his own sandbox, which is their silo, which is their plugin to hack on. And so as long as you own that little piece of the land,
24:41
you don't have to ask anyone else for the permission to add stuff. You can just go at it, and then you just implement whatever you want to do with it. If somebody else doesn't like it, they can have their own sandbox. So again, it removes one of the needs to discuss and collaborate between different people.
25:02
Everyone can do whatever they wanna do. There's not much to talk about. And it also helps everyone to work at their own pace. People like me, I do the conference, test-driven development, so if I wanted to show something in the next conference, I'd hack some features, I might not write tests
25:21
by the time the demo exists. Some other people in the Jenkins community would be far more disciplined. They might do, say, test-driven development. They might demand that every patch has the corresponding test case. But again, we could accommodate all these people with different opinions, because we are simply working on different sandboxes.
25:42
And like I said, the program was a big event, so if I have to see someone else's code, it's really not good for my peace of mind, because I see so many ugliness that, oh, how is it done this way, or how is it done that way? I'm sure you have the same experience. And then to see the same thing from the other side,
26:01
for someone new to the project, they no longer have to feel ashamed of potentially, I guess, the newbie code. If anything that works, it'd be fine. And then if someone has a problem with it, let's just go do this stuff on their own side.
26:21
And then I think the other important part is by creating this siloed environment, you can actually foster innovations, because every lucky idea that people might come up with, they get a shot at the implementations. As a new guy into the project, you don't have to sell your idea to someone else. And as a people, as an existing developer in the community,
26:43
like myself, I don't have to turn down anything. It's a lot easier to come across as a good guy if all you're doing is to encourage them to work on something in a new plugin, as opposed to tell them that, no, I don't think we can take it, because it's not general purpose enough.
27:02
So there are many features in Jenkins that I originally didn't anticipate to become popular, but nonetheless they did. So sometimes you just can't tell. And at the other times, I think as a programmer, and maybe this is because of my Asian origin, that I find it easier to communicate in code
27:21
than communicate in English. I'm sure you have this experience that you have this whole thing mapped out in your head, but it's just so painful to serialize this retro-related concept into English wars and sentences and try to convince the other guy that this is something they should let me do.
27:42
I've been contributing to many open source projects, and I always felt this pain. And also, there's a little bit of ego involved, right? I mean, people should by now know me, or how dare can you reject my party, this kind of thing.
28:01
So I think this allowing people to experiment new things into the plug-in that sort of enables people to get the job done, and also allows the project to foster experiments. And only after they proved themselves, we could sort of really start to highlight these things. And similarly, if some of these experiments fail,
28:21
we don't have to drag these. This plug-in where the experiments were made could lie dormant, and if we're ever using it, can keep using it, but it doesn't add on any cost to drag us down the road. Another part that I really like about the accessibility is that it highlights these higher order programs.
28:42
You know, with enough silos, with things divided up into enough silos, the core developers also start working on plug-ins, like myself, again. I work on a number of Jenkins plug-ins. And so I really get to put myself into the shoes of the plug-in developers.
29:00
I get to see the pains that they have to go through, and anything that I do to improve those processes, you know, be it simplifying the build process, adding the IDE support, writing the error checkers for the common mistakes, and so on, these things all start to equally benefit every plug-in developers. And so whereas if the core is the bulky piece,
29:23
the work that's done on the core is not gonna help the plug-ins by themselves. So in this way, you keep making it easier for people to write these silos, and then that makes development more scalable. You can use a smaller number of people working in the core to support larger number of people writing individual plug-ins or the silos.
29:41
And that, I think, is crucial because, you know, I think we all don't have enough committers in the program. I think the other key part, and this one is not technical, but it's more of a social thing, is by creating these silos,
30:00
it allows us to drastically reduce the barrier to the entry of the project. So I was, in fact, just having this conversation a few hours back in the Jenkins stand, that, you know, I was telling these people that, well, in Jenkins project, you just have to tell me your GitHub ID and then your Jenkins committers.
30:22
And then this is so much, I mean, it's so much so that we even write the IRC bot that adds the new people as a committer. And so that's why we were able to grow to that many, you know, number of people contributing. And then in many projects, I think this is,
30:41
this is quite, I think this is quite surprising, but this works for us, partly because when one people aren't collaborating, if you don't have to work with these people, you know, you don't need to have to carefully interview these, you don't have to see if, you know, they are nice fit, they're existing committers. So there's most of the reasons that typical projects
31:03
demand a long time for someone before they become a committer, it's simply gone. And again, it's also because of the silos, any possible damage that these new committer can do is highly compartmentalized. And so it really doesn't affect that much.
31:20
And also, part of the point of using border control system is so that we can roll back changes. So in fact, I can only think of like two or three incidents where we have in the past where the new committer, you know, made some programs or caused some confusions among these new developers.
31:40
And in all but one cases, we are simply able to roll back the changes they've done. You know, that we said, well, if we're ever working on the plugins before, take some seniority. Just because everyone is a committer doesn't mean everyone is equal. So if some plugin is actively maintained by some people, their opinion will be tramplers.
32:01
And again, that's okay because if the new people has problem with it, they could simply work on a different sandbox, right? So in all but one cases, we were able to successfully roll it back and then that was it. And so in my mind, like for most of the projects, unless you're like a Linux kernel, the project that we have is not having enough commuters.
32:23
And so we shouldn't be chasing people away with the stick. We should be instead making the contribution as easy as possible by reducing the barrier to the entry. And this coupled with the fact that the writing plugin, Jenkins plugin,
32:40
I mean the Jenkins plugin is small enough, but it's the main reason we were able to grow to that 600 plugin size. Yeah, and then also I noticed that when you give people new power, people sort of behave more cautiously. Just because they can commit to the repository doesn't mean they actually could. So they nonetheless want to make sure
33:01
that they are not stepping onto someone else's code. And so it really works well. And another reason this works well for the open source projects like ours is that when people move on, when people who did the original plugin moved on to something else, this allows us to have the continuous inflow of the new developers who will pick up
33:22
where the previous guy has left off and then carry the flag forward. And it also encourages small contributions. I think those are the ones that we want to have more often than having the massive changes that rewrites everything once every two years. Right? And then I also realized that now that I look back
33:42
that if I see these key contributors in the Jenkins project today, they came up to the project the first time very casual fashion, most of them. So when you think about how to grow people into the key member of the community, you have to start somewhere.
34:01
And then so, because you can't really tell who becomes the significant contributors, you just have to try it with everyone. But with that said, so far I was focusing on how can we do the work without any communications? But if there's absolutely no communication whatsoever,
34:21
then everyone ends up doing things in their own parts of the universe and they fail to sort of come together into the single mass that is the community. So the one good example that I can think of which failed to form the planet is the Ant plugin in Java build tool.
34:43
So Ant is a Java build tool and it's got excellent extensibility that allows people to write tasks. But so if you see like a GitHub or Google code, you see lots and lots of these little Ant tasks that's written by all these different people, but there's no single community around it because there's no place to go.
35:00
So they simply reach around the world, many of them dead. So instead what we want to have is some kind of this center of gravity that pulls people and that creates the community. That it's something that sort of bring all these different efforts into one thing, that the one mass, that the magnificent planet
35:21
that is the Jupiter. And I think in the traditional project, the source code repository is the center of gravity because for people to collaborate, they have to be able to commit the changes. So you create this artificial thing that's a single source code repository
35:41
and then people walk around it and that becomes it. But I think it doesn't have to be that way because as I said, for all the reasons, having people collaborate on the single code base is actually incredibly painful. So what are these center of gravities in the Jenkins project, right? So let me get some of the easy ones out of the way first.
36:02
So the first one, for whatever reason, I discovered that the IRC is an excellent the center of gravity. It's probably because it's the closest thing we have to the water cooler in the open source project. It is a place that people can come to, let's say as opposed to Twitter,
36:20
it's a place that you can go to see all the others. And you can also kind of be present and absent at the same time. So most of the time, you're not really paying any attention to what's going on there. But if interesting conversation starts, you could. Or if somebody else talks to you, you can. And then I think that we cracked the joke
36:43
and did some non-productive things in there, but apparently these things is very helpful for building human relationships. It helps create this context around people beyond the code. And those things go a long way in making work happen smoothly. The other thing I think that really worked well
37:01
as the center of gravity is the outreach effort. I guess people here would probably know this better than I am, but there's an incredible value in having people actually meet together and talk to each other face to face. So we've been doing meetups around the world, in Tokyo, in San Paolo, in London, in Copenhagen,
37:22
and so on. We've been having hackathons so that the developers can meet each other. And we also find that it's actually incredibly important to give projects some voice. Having a blog that people can come to, having a Twitter account so that when we want to do something, we have a means to reach to our users.
37:42
And for this, I have to say the mad props to the guy who's in this picture. He's the one that spearheaded this kind of thing. I'm the guy who writes code. I didn't realize how important these things are unless, until it actually happens. But above all these things, I think the most important
38:03
thing that creates this gravity in the Jenkins project is the update center. It's the user interface built into Jenkins that allows people to install plugins. And then the flip side of it is that to list your plugins into the update center, you have to co-locate your plugin
38:22
in the GitHub jenkinsci.organizations. And then we make it so that the commit access, a single commit access would grant you access to all the plugin you've all seen. It's not just the one that you're working on. And so it's a way of encouraging you to start working
38:42
on other plugins or start maintaining those. And then once you become a commenter, for the reason I mentioned earlier, you can also add other people into these projects. So the reason this works in my mind is because it creates an incentive for the developers to come to this community.
39:02
Because the users, they expect to install plugins. They expect to find plugins in the update center. So as a developer, naturally you want your stuff to be used by other people. That's how we derive pleasure, how to write in code. So that makes people want to come.
39:21
And again, when you have this inflow of developers, it makes it easier for us to find new maintainers. And then as more plugins gather in the update center, the expectation from the users that they find things in the update center gets stronger. So it creates a positive feedback cycle, which is exactly like the gravity.
39:41
So initially it starts small, but as it accumulates more plugins and as the users start to see more value in it, it creates this visual cycle that brings more people into the community and accelerates the whole process. And then so also, initially, the other part that makes this gravity stronger over time
40:03
is that this mechanism behind the scene to create and run the update center gets better over time because we invest in terms of the coding. And so NASA, we built the mirroring mechanism. We built the statistics stuff built in. We created the issue trackers
40:21
linked to the documentation and so on. So all these things stand over time, make update center a very valuable place that's very hard to replace. You know, it's the distributed burden control system. You can very easily move the source code repository elsewhere. But this kind of center of gravity that is the update center
40:41
and the fact that we have all this mess of people in one community, that's something you can't really move to another place. And that creates this community. That in my mind is the center of the community. So on this topic, I have to say there is this one emerging challenge for which I don't have answer for.
41:01
Back then we designed this whole thing. We were still in the subversion repository. And then since then, we've moved off to Git, as with probably many of you. And back then, the fact that the subversion was centralized was also acting as a part of the gravity. Because again, for you to,
41:22
it was just way too painful to maintain custom patches on top of somebody else's subversion repository. So if someone wanted to make changes to the plugins, they really wanted to do so in the upstream repository, that is in the community. But it's surprisingly easy to maintain your own patches and then keep it parallel
41:41
with what the upstream is doing. So there's a somewhat less of an incentive for you to join the project. I think the another thing is the pull request that had some profound impact on these dynamics in the community. You know, on one hand, it's great that the contributions are easier. So in fact, we receive a lot of pull requests,
42:02
so much so that we can't even keep up with. But also, it creates this mentality that lets people throw the stuff over the wall. They think the work is done where they contributed the pull request. But in reality, someone in the project will have to take a look at it, and then the patch needs to be brought to the completion.
42:22
That's a lot of work. And also, when we enable a contribution without them joining the community, it sort of reduces the inflow of the developers. So there's a lot of people who is contributing to Jenkins' project by sending us pull requests.
42:40
But they don't see themselves as the member of the community because they don't belong there. And so we are getting less new people in the community, which makes it harder over time to maintain those things. So this is something I don't have a good answer for. I generally like it and all that,
43:01
but this is something I need to forget. Okay, so really, all I'm trying to say is that we gotta scale the development, right? In open source project, we don't have enough people, we need more code to be written. The extensivity will enable us to do that. And then we can reduce the amount of communication
43:21
we have to do through the extensivity. We can let people do whatever they want to do with extensivity. We can get out of the way. We can get out of the way between people and what they want to do with extensivity. Really, all I'm trying to say is just extensivity, extensivity, extensivity, extensivity, extensivity, and hopefully I made this deep, I'll applaud.
43:42
So that's really all I'm trying to say here, the extensivity. Thank you very much. Thanks.
44:00
Anybody wish to ask a question? No? I hope I, I hope I didn't, anyway. I hope, well, I enjoyed the rest of FOSTEM and thank you very much for coming. Thank you.