Bonus Interview- Brian Behlendorf - Apache Foundation

دوره: Using Databases with Python / فصل: Databases and Visualization / درس 6

Bonus Interview- Brian Behlendorf - Apache Foundation

توضیح مختصر

And one day we discovered the group that put out the web server that we were using basically folded when all their developers left to go join a brand new company called Netscape. It turns out to be not that hard to be able to work together when people have the same common goal, which is let's build a product that does all of this great stuff. So I think that rule, that right to fork, limits the kind of excesses that we see whenever we start to talk about how do groups make decisions.

  • زمان مطالعه 0 دقیقه
  • سطح متوسط

دانلود اپلیکیشن «زوم»

این درس را می‌توانید به بهترین شکل و با امکانات عالی در اپلیکیشن «زوم» بخوانید

دانلود اپلیکیشن «زوم»

فایل ویدیویی

برای دسترسی به این محتوا بایستی اپلیکیشن زبانشناس را نصب کنید.

متن انگلیسی درس

We got our start in the early days of the web as a group of disaffected webmasters who were using a piece of freely available web software. But I had difficulty with it. We were fixing bugs, we were sharing these big fixes with each other like baseball trading cards, if you will. These patches, as it’s called. And one day we discovered the group that put out the web server that we were using basically folded when all their developers left to go join a brand new company called Netscape. So a bunch of us decided that hey, we’re dependent upon this software. We don’t want to become full-time web server developers, but we want to be able to use this thing that we’ve had for free, and be able to improve it, and all that kind of stuff. We looked at the license of the code. And the license said, here’s this software, do whatever you want with it. Don’t blame us when it breaks. Right? And we said, hey that’s a pretty good bargain. Why don’t we pass the same bargain onto the next group of people? Right? So, we formed a mailing list. Right? And this was mostly, again, webmasters, and people working at some early Internet service providers or website design companies or places like Amazon or the Internet Movie Database. And we combined our patches together and decided to call it Apache Server for that reason, and it went forward. And really the model of how we worked was based upon us as a group, as peers. Proposing ideas, vetting each other’s ideas and patches, and fixing bugs as a group, as a team. None of us had met in person, well some of us have met, but as a group we didn’t meet in person until 1998, really three years after we got our start. And long after, by the way, we had become the most predominant web server product on the planet. And yet at this time still no money, no dime. Not direct to us from this piece of open source software, but plenty of us made our living off of building things on top of this piece. And that’s really the story, I think, of successful open source projects writ large. Which is people working together on common technologies to solve common problems, so they can go off and make money on other places. Or so they can have fun, they can try new ideas, they can be experimental. Right? And that’s really the same story of Apache and of Linux and all these other open source projects. It turns out to be not that hard to be able to work together when people have the same common goal, which is let’s build a product that does all of this great stuff. One thing that we did do that made it easy to make some of these decisions was to have a very modular API. Which made it easy for us to be able to say, hey, if you want that special cool feature, do it as a separate thing and make it successful and we’ll decide whether to bring this into the product once it’s become successful or not. Right? Another key thing that plays into this that is true to all open source projects is that an open source license like we had on ours, that Linux has, et cetera, carries with it something called the right to fork. Which means that if I were to go all Colonel Kurtz on the project and start saying we’re going to go here and no one else wanted to follow. Well, all of those other people could decide to pick up the code and go start a different project somewhere else. If they couldn’t kick me out, which is probably what they would have tried to do first. Right? This right to fork means that you don’t have to have any tolerance for dictators. You don’t have to deal with people who make bad technical decisions. You can take that future into your hands and if you find a group of other people who agree with you, you can go on and create a new project around it. So I think that rule, that right to fork, limits the kind of excesses that we see whenever we start to talk about how do groups make decisions. And when conflict arises, how do you deal with that conflict? And it means that style of leadership isn’t so much one of control and plotting moves ahead of time, but instead one of being able to get people on your side. Convince them that you’re going to value their efforts, value the contributions that they make.

مشارکت کنندگان در این صفحه

تا کنون فردی در بازسازی این صفحه مشارکت نداشته است.

🖊 شما نیز می‌توانید برای مشارکت در ترجمه‌ی این صفحه یا اصلاح متن انگلیسی، به این لینک مراجعه بفرمایید.