5 Ways To Test the reliability of your MVP

Throwing together MVP, is a great way to test your concept and find out what customers really want before you sink more money into the game.

Building a developer culture with InnerSource

November 3, 2017

In July, we hosted the first annual Code Climate Summit, a one-day conference for leaders of engineering organizations who want to better themselves, their processes, and their teams. Starting today, we’re excited to start sharing videos and transcripts of the six great talks. First up is Panna Pavangadkar, Global Head of Engineering Developer Experience at Bloomberg LP, with her keynote: Building a developer culture with InnerSource.

Transcript of talk

I’ll just start by introducing a little bit of my background, how I got here, and why I do what I do today.

I run something that we call Developer Experience at Bloomberg. How I got there is a slightly long-winded story so bear with me.

I started off in the ‘90s working as a late night lab assistant in India, which then led me to supporting the manufacturing sector and then the financial sector. When you joined as a consultant, you literally did everything. You were an app developer. You were a system administrator. You were a DBA. You were the person who wired up the cables and got into the machine room and did everything.

That then led me to deciding to follow databases. I became a database consultant and moved to Asia in the financial sector. Long story short: I landed up here in New York City, working in the financial sector again, focusing on application development and databases, and then system engineering, and performance engineering. This long-winded story comes back to why it puts me in this unique position for Developer Experience, as I discovered that – going through these various roles in these various countries, encountering different types of developers – the one thing that I developed a lot for was empathy.

I realized that every single personality type in computer science, varied system administrators, DBAs, app dev, web developers, have their own personality types. We all have our own quirks, our own religion, and do things in a very particular way that’s unique to us. So “it’s my way or the highway” and “I’m god’s gift to mankind”.

That made me develop a lot of empathy that led me to saying, well how can we make our developer experience across the spectrum of people different? Because we all actually want to work with each other. It’s not that we don’t want to work with each other. But we are so myopic in the way that we want to develop our piece of the puzzle, that we don’t see the other person’s point of view.

Two and a half years ago, I got approached by Bloomberg to try and explain how should we be developing software. I had been at Goldman Sach’s for 16 years and done various, various roles. And as a tech fellow at Goldman we were driving technology in a particular way. When I started talking to Bloomberg it was really about how can we continue to embrace change, and keep our developers excited, and continue to develop quality software, and be the product leader that we have been for so long. So we created this team called developer experience.

So basically, my team does anything and everything from owning the tools that are required by the developers, the process, the framework, the training, the documentation. I even got a, this is a real story, I even got asked if we were responsible and we would take care of having enough male bathrooms. But don’t quote me on that one.

INNERSOURCE: LEVERAGING OPEN SOURCE BEST PRACTICES IN THE ENTERPRISE

Let me make a one second pitch for Bloomberg: Since the majority of people here are from New York City, you’ve obviously heard of Mike Bloomberg. Anybody not heard of Bloomberg the product company? All right. Awesome. So just to make sure we’re all on the same page, we’re a product company based in New York City predominantly, and we’re in the business of providing information. 5,000 engineers across the globe who work on developing the platform on Bloomberg Terminal. You’ve heard of Business Week and you’ve heard of the Bloomberg media news outlets, etc., but our predominant product is the Terminal.

I said we were in the business of providing information. As you can imagine, it’s been 30 years of development that have gone into building the Terminal, to be able to provide very high touch individuals with specialized functions to get the information they need. Whether it’s news, trade related, analysis, portfolio management, to finding out the current events that are happening. So we have to really, really work to provide low latency information and also a broad variety of information.

You can imagine that everyone is working on different functions. Could be for the equities business or it could be for the news media or it could be for some of the back-end functions, just to develop this Terminal itself.

When I got in, what we discovered was that we collaborated a lot. There was a lot of collaboration, but we collaborated the old-fashioned way. Spoke to people. Put in tickets for other people to do things. We were transparent about the fact that your ticket is going to wait for me to finish what I’m working on, or it has to get prioritized by whichever product owner of whichever team I’m working in.

I started exploring the concept of how can we bring open source best practices in house, inside the enterprise. As we started exploring that, we called it “collaboratively sourced” or we called it “internal open source” and finally some of our active developers came up with the fact that hey, this thing already exists in the market. It’s called InnerSource.

Anybody hearing InnerSource for the first time? Cool. It wasn’t a well-known term. We hadn’t heard about it. We were just wanting to bring the best practices in house. After going through a few iterations, we settled on saying fine, we’ll call it InnerSource. Of course, having spent the past 20 years in the industry, my fear was InnerSource would get thought of as developers outside the company working on it. But in any case, supposedly O'Reilly had coined the term 17 years ago, so the term existed.

About 17 or 18 companies, decided to collaborate to see if we could make InnerSource a much more popular term. But more importantly for me, was really bringing those practices in house and sort of breaking down the barriers that exist within an enterprise.

What I discovered is: Most enterprises have grown up organically over the years. It’s very easy in a startup to start with a clean, fresh slate and work on things, and be open about it, be transparent about it, be able to look at each other’s code, etc. In an enterprise that’s evolved over 20 years, you’ve grown up in silos. Thing have got added on as they got added on, so people hold on to their little bit of the codebase. That’s how they’ve grown. What we needed to do was figure out a way of breaking down those barriers and really embracing some of the benefits.

I list out the benefits here – transparency, collaboration, innovation, community, reuse, mentorship, self help – but there are obviously more benefits to open source than these. What I was really focusing on for our developers is collaboration and a lot of the community and the camaraderie that can be built up, so that we have empathy for each other. We are able to work with each other without getting protective about it. That’s pretty much the theme that started it.

HOW

So how did we go about it? Initially, it was really just talking about the concept. Just like how I asked you, who has heard about InnerSource and a lot of you hadn’t. When I spoke about collaboratively sourced, it was met with of course, a lot of skepticism. There was a lot of critiques. It was like it’s just not going to work. Like, why the hell would we do this? We are already working within our teams. We have enough work to be done within our teams. So the first thing was really about introducing the concept and saying, at least just be open to the idea that I can go across an enterprise team, organizational, artificial boundary and look at somebody else’s code and add value or vice versa. Have somebody else who may have something to offer, may have some sort of expertise, or just be interested in that area, to come and look at my codebase.

Just sharing that idea and getting the excitement created within the development community was the first step that we went about. I did think about, and everybody asked me, what sponsorship do we have? Do we have management buy in? What I had done was just tested the waters, to say, if I go and ask for permission, will it get squashed down or should I push for this collaboration social experiment and beg for forgiveness later?

Fortunately, one of Mike Bloomberg’s business principles state that take the risks and beg for forgiveness if needed. So that’s how we decided to say let’s start getting the developers excited about the fact that hey if you are waiting on somebody to do something for you, you can offer to help them out. In the offering to help them out is where the whole drama lies, but the concept was well understood.

Identify early adopters

Once the concept got understood and a few of the developers started embracing the concept, that’s when we said, let’s identify early adopters. I was in this unique position to say, I own the tools. I own the tools that developers use, so let’s open up these tools and if the next person who asks me for a feature, we’re going to tell them that they can help us and contribute to our codebase and make that happen for themselves.

Two and a half years later it sounds way easier to say what I’m saying. Trust me, all my team leads hated me. Literally hated me. They were like, why is she bringing all this into this? We were functioning just fine, right? Because I mandated that we open up our own codebase.

So I identified early adopters. In your organizations it really is about finding out what’s that sweet spot, what’s the low hanging fruit, which of the less resistant applications, functions, codebases would be able to accept external contributions. Then, it really was about mobilizing people to actually start to engage and contribute.

Engage (at all levels)

This is where we were slightly unique because we already had a few years ago started off with engaging our development community a lot more. We have people who are called partners, we have people who are called champs, we have people who actually within their own areas, are responsible for being the people who engage with the other teams, continue to collaborate with the other teams, as well as pushing best practices. So it was really leveraging this champ/partner community. We have tech reps as well, really embracing and getting them to embrace it and then they started engaging with us to say, can they start contributing to these early repositories because it really was setting precedence.

Evangelize

Once we had the precedence set, because we had a few repositories where people from other teams could now contribute code, we could then start to evangelize a little bit more and even tell middle management, or our managers, or our senior management, that this concept can work. We just have to push the envelope a little bit. So really it was the engagement on all levels and the evangelization.

This is really about tooting your own horn for the project itself. So for InnerSourcing to be accepted, for people to start understanding the terminology, we created an internal function called sauc. It’s just a play on Innersource but it’s called sauc, so when you type in sauc it’s nothing but a list of repositories with pull request, books, help wanted tags, and it’s just a very, very simple gaming methodology. Not to call out people, but to call out projects that have lent themselves to being contributed to as well as extended.

Sponsorship

That’s a key, but in our case, we got sponsorship way later into the game when we had already sort of proved concept, to say this can actually work.

AFFECTING CHANGE

Organizational structure, culture and dynamics

So I mentioned change is hard. Tell me to walk on the left side of the road when I get out of Penn Station and I go berserk because I have a set pattern. I walk on the right side of the road to get from Penn Station to Park. That’s just a simple example. Try telling any one of you to change the way you write code or change the way you do certain things and you’re going to be questioning why it needs to change because it works for you. The way I develop software on my laptop works for me, why the hell should I change anything, right?

It was really, really hard to get people to accept the fact that now we are going to introduce the ability for other people can contribute to your codebase. You can contribute to other people’s codebase. Keep in mind, I’m talking about history. People at Bloomberg have been around for 20 years. So they have set patterns. They have ways of working. It’s not like we’re getting in or changing 5,000 people overnight. When new people come in, of course they want to be able to bring their new best practices with them. Being able to talk about the fact and getting them comfortable with this organizational structure should not be the barrier which holds you from going across organizational boundaries, which is something that we really had to work on. It was a lot of talking. A lot of sharing stories and convincing people that this is good for them.

There is a lot of pride in the work that we bring, the work that we have done. Sure, I took some short cuts at some point in time, but I had pride then and now, because I don’t want to feel exposed, I’m reluctant to open it up and allow people to critique it or comment on it.

So, code pride is one of the things that I found was the biggest road block because people have evolved over time and they have become better, they have embraced new things, so if you go back and open up something that somebody wrote 15 years ago, and start saying this person doesn’t know what the hell he was writing about. Yeah, maybe he didn’t. Maybe he or she had no clue what they were doing at that point in time, but they have evolved now.

What became really interesting is creating a culture where it was okay to talk about code that was written earlier, but it was not okay to say nasty things. It’s easier said than done.

We use IB, Instant Bloomberg, as our internal chat. I can’t police multiple chat rooms to say people shouldn’t say nasty things to each other. I’m guilty of saying, this is just ridiculous stuff, I’m not even going to bother commenting on it or they shouldn’t have done it this way, but we had to start creating cultural awareness that you cannot bite somebody else’s head off, you cannot be nasty, and creating the informal policing.

I talked about champs. I talked about tech reps, I talked about evangelists. Creating that culture where developers feel that they can hold accountable other people who may be getting vicious, or even slightly aggressive, on IB or mail or even comments in the codebase itself. Really embracing the fact that you’re coming from different places and you’re contributing at different times and therefore, passing a judgment is not acceptable, and we have to find more constructive ways of changing that codebase and making that change.

Accepting contributions is hard work

As soon as we started getting over that barrier, the next thing was, well, accepting contributions is hard work. And then taking ownership of somebody else’s contribution, because I may still own the product and I’m responsible for when the tool breaks. It then became the concept of saying, well we have to then define how am I going to discuss the feature request coming in, or how am I going to deal with the idea, the suggestion, the code contribution coming in, and what are the rules of engagement? What are my guidelines? Or, what’s my point of entry? And what are we willing to engage with and what are we not willing to engage with.

Now, in the whole Agile transformation, it’s tough because you need the product owners to buy in, you need the team to buy in, you need to be able to set aside the time to accept contributions that weren’t part of your regular stream of work coming in.

Trusted committers

This is where we started to talk about expanding our trusted committers beyond the organizational or product team. Could we grow our list of trusted committers beyond the organizational boundaries? This was really, really hard work. It of course meant that there was a lot more coaching involved. There is a lot more shadowing involved. A lot more people who are getting familiar with your codebase, before they can actually help out with code reviews, by being able to review your pull request, etc.

CHALLENGES

Risk

It’s complicated. There is a lot of risk to it and the risk is if I’m owning a production function and you’ve contributed code to it, and something breaks, I’m going to be held accountable for it. I’m going to have to support it. I’m going to have to get up at night and deal with whatever broke because you didn’t test some edge condition. It’s easier just to say no we can’t do this. So that risk was the biggest one that we had to overcome, to start to encourage a higher standard of acceptance such that we could take this risk of getting contributions from other people.

Commitment

The next one is commitment, both time and team.

Time is the easier one because – and I got into trouble for saying this in Europe, but – everyone does 120%. Some people even do 140%. It is basically going beyond your day job and providing some contributions to other teams or even functions you’re interested in, but Europe has some very strict guidelines around the 80/20 and just padding 100% of the time that they work on, so I was told to work on trying to figure out how we could adjust our external or additional contributions to within 100%.

So we went back to this concept of 80/20, 90/10, call it what you want. We didn’t really advertise it internally, but we took a few teams and said, let’s try it out, to see how much does our work really suffer, if we do set aside 10% of our time to work with other teams or things that we may be interested in personally. The product buy-in on this was really, really tough, as well as some of the teams just didn’t embrace it initially.

I won’t say this was a solved problem, but we continue to work on it and I truly believe persistence is going to pay off. Over time, both project owners as well as the teams will realize that having that 10% flexible time for me to work with other projects that I’m maybe interested in, is actually a motivating factor for me because I don’t mind the drudgery stuff I may be doing or I don’t mind some of the other things that may come on my plate, because I have that 10% excitement of what I want to do. Or try out a new thing. Or be able to look at a new exciting project that’s going on in some other part of the firm and be able to do that.

It also led to this whole confusion between projects and products and projects done by teams versus what the product ownership is. The reason I bring that up is, even though the Terminal is one big product, we have multiple products within the Terminal, and then we have multiple projects that go across multiple products – so there’s no one size fits all. So we would have to figure out what the right distribution of work across projects and products is. As I said, in an enterprise having evolved over time, time accounting or people accounting became a question, to say, where does a developer’s time go?

Again, we went back and forth on this, saying we shouldn’t worry about where a developers time goes, we should worry about the progress that we’re making with moving the product forward or the project forward, and the innovation that we’re bringing in, the new functionality that we’re bringing in, which is what our higher end clients need.

That is again a lot of proving by actually getting some initial teams to be able to participate in this sharing concept, move the product forward, and getting the product owners to actually talk about the wins. We had some crazy user stories being shared internally about just functional changes that we were able to move forward much faster because multiple teams were now able to collaborate at a completely different level.

Rules of Engagement

I spoke about rules of engagement. I spoke about people defining, so we didn’t set a one size fits all. We didn’t say this is the participation criteria across the board, we said, every team can now put in a contributing.md and I said team but I really mean a repository. Any repository, you can define your rules of engagement. You must have a contributing.md otherwise you’ll get a default one. And in that, your rules of engagement and your acceptance criteria for contributions. Then what we started doing was scraping all the repositories to find these contributing.md’s as well as started to showcase where people were being forthcoming about defining their rules of engagement really well and their acceptance criteria as well as where it was then possible for others to start contributing to it.

Buy in

I already spoke about the buy in. We had to get and we cheated again a little bit on this, we went around the product owners and found out which product owners would lend themselves to this concept of inner sourcing, who would lend themselves to saying, some portion of my time, 5%, 10% of my developer time, can be spent and we had various sort of negotiations with them which is to say, fine, I can move tickets in some other project as long as it helps my project move forward. If I’m waiting on somebody, I have the leeway to contribute to that particular project and move it forward for myself.

So we engaged with some of the earlier product owners. Once we had gone through six months with them, we got them to talk to other product owners and showcase how it was beneficial - not just in terms of moving the product forward, but in terms of the developers engaging with the other development teams on a much deeper level. We were engaging and collaborating at the codebase.

It also helped with keeping us motivated, and having options. I now like what’s happening in the other team, and I have mobility options to actually move to the other team and help them move things forward. We had various occasions where somebody moved to another team for six months, helped the move a particular area forward and then move back. It just opened up a variety of avenues for us.

It’s my baby

Finally breaking the myth about it’s my baby. How many of you still hold onto stuff saying that it’s your baby? I used to be one of those people 10 years ago. You have to learn to let go. Literally, it’s not going to get better continuing to be your baby, right? At some point of time, even parents let their kids go. So, the breaking down that concept of “this is my baby and I’m not going to let go” was probably the toughest one. So we had to continue to push on those people who thought it was their baby and work with them on an individual one on one basis. I will claim we still have a few. I think we’ve broken down most people to at least open the doors. They still think it’s their baby but they’ve opened the doors. We still have a few more to go and that’s been the toughest one.

DIVERSITY

Individuals

I started my talk with what got me to this place which is I had experiences across Asia. So in India, it’s a very hierarchal society. It’s changing, so don’t throw darts at me right now, this was 20 years ago. We had just started. The computer boom had just started in the mid 90s and it’s very hierarchal. You get delivered a set of tasks. You move forward. Nothing. You’re not allowed to question or offer a suggestion.

Unfortunately, I was sort of badly placed there. I was born and brought up in India, but I was badly placed there because my dad sort of encouraged us to really do whatever the hell we wanted. We were two girls. When I started working, it was really tough for me to hold back because if I didn’t agree with something, I would say, this is just wrong. I’m not going to write it this way. That was my individual experience. However, I discovered – as I moved into system administration and database administration, I was one of 50 to 100 guys sitting there – I was okay working with them because I had grown up that way. But the other girls that started joining our teams, were not okay with it. They found it difficult. That’s when my head started clicking and I said every single individual is different. I could deal with it but some of the other aren’t dealing with it.

Then I discovered that it’s not a gender thing. It’s individuals. They are individuals who are soft spoken. There are individuals who don’t mind putting their ideas out there. There are individuals who are more thoughtful. There are individuals who will speak off the cuff and we have to account for those individuals, for those different individual traits when we start collaborating and we have to try to create a practice where everybody is sort of self-policing themselves so that we are more inclusive. That’s something that just doesn’t come naturally. But we had to start talking about it and as I held more and more intimate 20 people, 30 people sessions on pointing out behaviors within instant messaging, pointing out behaviors with updates on tickets, pointing out behaviors with code reviews that were nasty, or appear to be nasty. I am a direct person. I can ask a direct question. I didn’t think twice about it. But the person on the other end or a newcomer on the other end, may perceive it as hey I’m not going to touch this thing because the next thing I do my head is going to get bitten off and I just don’t have time to engage with it.

That really is something that each one of you, individually, if you’re just conscious about the fact that the other person might be coming from a different place, we can collectively improve the developer culture across the board. Just by being conscious of the fact that somebody is coming from a different place and may have a different criteria in mind.

(By the way the picture up there is a fish tank at Bloomberg and I always get fascinated because every fish behaves differently and that’s why I wanted to put that picture in there.)

Building a culture of mentoring/coaching

Building that culture of mentoring, of coaching, is every individual’s responsibility, and just making people conscious, all developers conscious, of the fact that this is what’s happening. I found a very unique way to do it. Get a bunch of people in the room, of varying experience and at different levels in the organization. So two years’ experience to 20 years of experience and ask very provoking questions on how they would react to a certain statement out there or how they felt when something happened in IB and instant messaging or what would they think if they had a newbie question to ask. Who would they ask that question to? How would another person who was sitting there react to that newbie question?

When we started having these conversations, it was very interesting because people discovered, just observing and hearing other stories in the room, behaviors that they probably needed to change themselves. It wasn’t anybody judging it was just sharing stories. And we still do that to bring developers together even in meetups, we ask those questions, especially around being more inclusive, about the varying range we have.

Community driven

As I said, it’s all community driven. We leverage the champs, the partners, the SI partners a lot. I encourage developers to be their own police so we don’t have top down mandate. We don’t have a management decree coming down that thou shall do this. It is all based on grass roots efforts. We do have support now though.

TEAMWORK

Of course, it’s not, even though we are all individuals and every single individual contributes to it, nothing moves forward without us moving as a team including this collective developer audience as a team.

[Indicates slide outlining roles within team and a picture of a dog sled race team] The reason I very specifically picked this sled racing team is to point out the very, very simple difference. They are not all eight equal dogs. Each dog has its own personality. If they are trained, they are trained for the position they are running at. So the leader dogs versus the end dogs, have very different roles to play and part of the training goes into training those dogs that way. Those dogs don’t behave out of their roles. They behave in their roles.

I don’t mean to compare us to a sled dog team, but the reason I point this out is because when we’re functioning in a team, you will realize that and you probably already know this, that everybody plays a different role, apart from the official role. So some are more mentors. Some are more coaches. Some can ask more questions. Some are more outspoken and will take over the meeting or take over the design discussion and it’s their way or the highway.

What I’m really asking for in this is the roles should be really determined for the team as to who is doing what, but we should really embrace the differences and ask people – or make people comfortable – to participate in the team, even though the roles are clearly defined. Where people take over meetings or where people may be bullish about something, find somebody to coach them, mentor them, to change that behavior so that the team itself can evolve and become a better team.

TOOLS

When I go back two and a half years, I said okay, what are our silos? Why are we so siloed? Where is the collaboration happening? We didn’t have the appropriate tools. Tools did play an important role. Repositories were permissioned individually. I won’t even go back to whether we were using CDS, Purecase, SVN. Earlier versions of Git. We are now on Git but the reason I bring that up is because repositories are individually permissioned traditionally. That’s how we grew up in silos. So the first thing we did was say, okay, we’re going to open up our repositories.

“Oh no, no, no. You can’t open up my repository because I have sensitive stuff there.” What sensitive stuff? “Oh we store passwords there.” I’m like that’s not sensitive stuff. Take your passwords out. The repo is not the right place to store the password and keep a closed repository. This is a true story by the way. But it always came up as “oh we have sensitive code. We cannot open it up.” As I started questioning what is the sensitivity of that code, it always boiled down to one of three reasons. Three invalid reasons and I’ll tell you the one valid reason.

“I have some secure stuff there that I shouldn’t have put there but I put it there so therefore I can’t open it up beyond my team.”

“I have some…” am I allowed to say shitty code? “I have some really badly written stuff here. We’ve made some bad decisions. We have to clean it up before we can open it up. So we’ll clean it up and then we’ll open it up.” Of course it’s never going to get there.

And last but not the least is “oh, because these are low level APIs and we don’t want them to know what we’re doing and be able to leverage some of the other stuff, we can’t open it up because they can’t see the decisions we’re making because then they’ll directly access our codebase.”

The one valid reason which is probably true across the industry is 10% or 20% of the codebase probably was truly specific to competitive business advantage, maybe some algorithms. Maybe some business logic, etc. Right? That was the key, the glue, the thing that sold your product. 10%, 20% and this is just an off the cuff number.

The minute we said that all repositories are open by default, we started working through these restrictions that were laid out to us and we started just saying, you’ve got to open a repository by default. If you want to close it up, you’ve got to talk to me. Then of course I’ll wear you down with asking you questions and then I’ll take you to your CIO and wear you down with asking questions.

That was our first thing. We were pretty scared and skeptical that because of this rule, we would not get people moving into this concept, but as I go back to how I started my conversation with the early adopters, with the evangelist that we created, with the buzz that got created about having a tool set that actually works, we started getting people moving their codebases over from whichever legacy repository they sat on. And we started getting more and more requests for features such that the tools would enable them to embrace this change.

Agile brought in some rules. So our Agile coaches came with some very specific guidelines. We had to then coach our coaches on some of the 'religion’ that they brought in versus some of the common sense which is just we needed to work with within our enterprise because our enterprise had grown up that way. Just to get them to recognize the differences and work with us was a challenge, but it’s something we worked through.

What we also discovered was thinking outside the box. In a traditional enterprise company, we didn’t have hackathons. We didn’t have coding days. We didn’t have space for ideation. So we started sponsoring a lot of those kind of activities. We have something called a Dev-X hack a thon which runs for a couple of days. We have it two or three times a year. We have it in London and we have it in New York. We do other cool stuff. The swag, the prizes, but the fact is that the ideas that come out of Dev-X hackathon get sponsored to get built up as a project.

So a lot of the tools integrations that we built up, were a result of the hack a thons. The idea started in a hackathon and then got sponsored and we could go ahead and build out that integration, amongst the other various SELC tools.

ENCOURAGING COLLABORATION WITH STRETCH PROJECTS

We found this to be a really, really interesting way of encouraging collaboration across teams. All the newcomers or the new classes that come in, I always encourage them, as part of their training to take on stretch projects. If they are interested in taking on a stretch project, I encourage people to work with their management teams to allow them to do those stretch projects. That seems to have helped us in moving the agenda forward because as people start to see the benefits both for the people that are working in their teams as well as the projects that they are working on, everybody has got a win, win situation.

What we also started to do was say, if I have opened up my repository, I’m going to have some issues being tracked and I can put in help wanted tags on the issues that are low hanging fruit for me and I can get others to contribute to them. I mentioned this function called sauc. You run sauc, you get to see a list of repositories which have help wanted functions. For somebody who doesn’t know specifically where they want to get started, or they may have an idea they can just go look at the help wanted issues, pick them up, and work on those. This was a really easy way for us to say, do it yourself. Self-serve yourself for moving something forward.

What we also did was shared infrastructure projects. Everything with software infrastructure which was related to the tools we opened it up. Some places it’s harder to accept contributions especially when it’s really related to compiler flags which go across the entire stack, so those are harder contributions to accept. But some of the simpler contributions are really straightforward. We also started to understand common pain points that came across because as you can imagine, we’ve opened up a codebase now. So I can look across my entire sauc repository and see everybody’s projects. If I have somebody working on containers, I can see who else is working on containers and create those opportunities to pull them together so that we don’t have everybody doing their own thing. And pull those projects together and actually sponsor it as a project so we can collectively work on that one functionality or feature or piece of infrastructure that we’re developing.

And with that, I’m going to say and encourage all of you to get started. You can look at innersourcecomments.org. I have references at the end and the three things, I called it my three pronged approach initially when I started, which is identify the early adopters, evangelize, and then get the sponsorship. I hope this has been useful for you.

Panna Pavangadkar is the Global Head of Developer Experience for Bloomberg’s Engineering group. Building a great developer experience is at the heart of what her team does, providing a development environment that enables application developers to focus on building the company’s core product: the Bloomberg terminal. Her past experience with databases, operating systems, infrastructure and application development in various engineering roles – as Technical Fellow, Vice President at Goldman Sachs (New York) and JP Morgan (Singapore) and NIIT (Pune, India) – gives her a unique perspective to understand and work to introduce and encourage wide scale change within the company’s developer and engineering communities.

[…]

The Ruby Rails Aggregator