Who – Steve Webber
What – What Is Open Source And How Does It Work
When – The Success Of Open Source (the book this chapter comes from) was published in 2004
The Gist – This chapter covers the architecture of Open Source as a development practice and why it exists. It later covers the type of intrapersonal structure that comes with an open source project and how all of that is managed and kept tame.
The Good –
- I’ve known about the dangers of having too many people working on the same code base, but this article mentioned Brooks’ law, and putting a name to that concept makes it a whole lot easier to refer to it, and knowing that it’s a widely-accepted industry term definitely reinforces that it’s a phrase that I’ll continue to use.
- I was stoked to see the Red Hat name all over this article too. One of the main reasons I’m taking this course is to familiarize myself with the FOSS culture, so when I graduate I’m not going into a position with Red Hat completely ignorant of FOSS dev practices. That stuck out to me as something that made me really excited about reading this article
- The “8 Principals of what people do in the open source process” is actually a really rad way of outlining the motivations and processes for people who contribute to FOSS projects. Knowing the sheer magnitude of projects like Unix it’s really cool to see this objective sense on what makes FOSS unique. As someone who is completely new to this field, it’s a really simple and clear-cut explanation of a lot of the aspects that confused me
The Bad –
- I’m having trouble picking apart bits of this article that I don’t like (it’s like splitting hairs and I don’t think it’s fair to the author but I’ll do it anyways for the assignment) but I will say there were a lot of concepts here that were hard to remember, but specifically giving a better idea of how corporate software development works before going onto explaining FOSS dev practices would have helped a lot. There are a lot of comparisons made to corporate dev (like the silo problem) that would make a whole lot more sense to someone with extensive corporate dev experience, so having some more background on that would have helped my understanding.
- I think the author also has a very biased opinion on Torvalds. I don’t know enough about Torvalds to dispute anything the author says, but this book does speak a whole lot of (well deserved) praise to Torvalds without devoting much more than a paragraph or two to other systems of managing such a large project (though I don’t know that there are any other FOSS projects at the same scale as Linux that have different managing architectures)
- The chapter also talks a lot about the circles of development around Linux (lieutenants, maintainers, inner circles) that were a major part of why I never had any interest in contributing to Linux in the past. It definitely seems (from the outside) like a very exclusive club. Low level first-time developers are likely to submit patches or make pull requests of code that’s not perfect, and just thinking about how many hands your code would get passed through before it could get accepted (and the number of people who would be able to tear your code apart) is VERY intimidating. Some of the wording on this article perpetuates that feeling for sure.
- I’d love to ask the author a few questions about the contents of this chapter, and especially ask about some big issues in modern dev that weren’t touched upon like the MASSIVE gender gap in dev and how that’s affecting the industry as a whole (out-of-scope for this chapter’s topic?)
- Where would the author suggest a first-time contributor start? This has got a lot of good info explaining the industry and getting the reader up to speed, but the major next step is involving themselves, and I’d be curious to hear what the author has to say on that!
- Without a project lead as emotionally invested and honest as Torvalds, how would the author imagine the development of Linux going? Would the community still be able to be as active and successful in the development of Linux without a single leader to help guide them?
My Review – This is definitely a great introduction article to FOSS that helps outline the major concepts, the major problems, and the processes that guide software development in this unique way. Veterans might not get much value from reading this, but as someone very new to FOSS culture and practices, this is a great place to start. Two thumbs up