├── 2017-Spring-UMSL.md ├── 2019-Spring-WashU.md ├── LICENSE ├── LectureNotes ├── Building.md ├── CI_CD.md ├── CommunicationsTools.md ├── Communities.md ├── CommunityModels.md ├── Dependencies.md ├── Documentation.md ├── Foundations.md ├── GettingInvolved.md ├── IntroAndHistory.md ├── Issues.md ├── Licenses.md ├── Releasing.md ├── SDLCMethodologoies.md ├── SourceControlAdditional.md ├── SourceControlOverview.md └── WhatIsOSS-ForStudents.md ├── Presentations.md ├── README.md ├── UsefulLinks.md └── syllabus.md /2017-Spring-UMSL.md: -------------------------------------------------------------------------------- 1 | # Seminar in Information Systems - Open Source Software Development 2 | 3 | ## Course Overview 4 | This course is intended to familiarize students with the concepts of Open Source software development and modern development practices. Specific areas of focus are: 5 | * History of Open Source 6 | * Communities and governance 7 | * Technologies used 8 | * Source control 9 | * Communications tools 10 | * Issue trackers 11 | * Legal aspects (licensing/foundations) 12 | 13 | Additionally, students should expect to be challenged in areas of personal development related to the business environment such as giving presentations, writing position papers and analyzing failures. 14 | 15 | ### Administrativia 16 | Daniel Ruggeri - druggeri primary.net 17 | Tues/Thus 5:30pm - 6:45pm, 104 ESH 18 | INFSYS 3898 (Undergrad) 19 | INFSYS 6891 (Graduate) 20 | 21 | #### Textbook 22 | Open Source Software ~ *Karl Fogel* 23 | ISBN: 0596007590, ISBN-13: 978-0596007591 24 | Download free at [http://producingoss.com/](http://producingoss.com/) 25 | 26 | ## Assignments and Grading 27 | In full transparency, the assignments dished out as well as how they are graded is shared in this section 28 | 29 | ### Homework 30 | Homework assignments will be passed out from time to time involving reading, researching or taking some action. These assignments should be completed by the next class 31 | 32 | ### Presentation 33 | Each student will be required to give a short presentation about a topic. 34 | 35 | The reason for this requirement is two-fold: 36 | * To ensure a certain level of mastery of the topic such that it can be explained well 37 | * To ensure a certain level of mastery *in giving a presentation* 38 | 39 | This is so each student gets experience in exercising their "marketing" muscle which is not only required in the world of business, but also the world of Open Source. 40 | While presentations will be graded on content, a significant portion of the grade will also come from organization of the content, aestetics of any materials presented as well as the ability to adhere to guiding principals for good presentations. 41 | 42 | ### Papers 43 | Communicating well is critically important in the world outside of the classroom and, similar to giving presentations, is a muscle that must be exercised regularly. 44 | Students will be tasked with writing short papers in the form of: 45 | * **Position papers** in which an opinion and supporting facts (persuasive in nature) should be presented. These documents will be graded on grammar, composition and coherence to the assignment and argument since opinions vary. 46 | * **Summary documents** which should be written in a form suitable for a manager to understand the landscape or overview of a concept they are not familiar with. In addition to the points earned in position papers, these documents will also be graded on accuracy of their factual contents and the simplification of complex topics. 47 | 48 | #### Source Control for Pointy Hairs 49 | Exactly 1 physical page 50 | I am a manager that has worked in manufacturing all of my career but have recently moved to become the manager of a software development team. 51 | I hear people mention "source control" and things like "commit", "branch", "tag" and such but I don't know what any of these things are. 52 | Provide me a one-pager that explains what source control is and gives a few key terms/definitions. 53 | 54 | #### The Best Open Source License Is... 55 | At least 2 physical pages 56 | The legal environment of business and software development is complex. 57 | It's even harder when trying to open a code base because there are so many FOSS licenses to choose from. 58 | What is the best Open Source license out there and why? 59 | Use the first paragraph to make assumptions about why I want to open my code and the remainder of the document to define your choice and explain it. 60 | 61 | ### Participation 62 | The world of Open Source is driven by community so it is important that the community within our classroom is full of individuals willing to contribute to the success of the whole class. 63 | Therefore, participation during discussions and presentations as well as within code and the project will be measured over the course of the semester and will contribute to a significant portion of the grade. 64 | 65 | ### Extra Credit 66 | Through the course of the semester, students will have opportunities to earn extra credit. 67 | Opportunities will be shared as they come along. 68 | * Contribute fixes to this course's content 69 | * Contribute fixes to a real Open Source project 70 | * Attend [ISPC events](http://mis.umsl.edu/Whats%20New/index.html) 71 | 72 | ### Breakdown 73 | * Homework 10 74 | * Class Participation 10 75 | * Paper: Source Control for Pointy hairs 20 76 | * Paper: The best Open Source Licence is... 20 77 | * Midterm 40 78 | * Final 40 79 | * Presentation: Topics Assigned 20 80 | * Presentation: About My Favorite Project 20 81 | * Total 180 82 | 83 | 84 | ## Schedule 85 | This is the planned schedule of events for the course. Since topics may run longer or come up short, expect some minor alterations. It's also important to note that *when you see **discussion** come up in the schedule, you should **expect the instructor to ask questions** that will verify your understanding/homework* as well as to cover some of the topics in depth. 86 | 87 | ### Tues Jan 17 88 | * Get to know eachother 89 | * Cover syllabus 90 | * Discuss presentations 91 | * Discuss project 92 | * **Homework**: Read chapter 1 of book 93 | * **Homework**: Create a github.com account - email me the username 94 | 95 | ### Thurs Jan 19 96 | * Chapter 1 discussion - [lecture notes](LectureNotes/IntroAndHistory.md) 97 | * **Homework**: Read Bruce Perens' [Open Source definition essay](http://www.oreilly.com/openbook/opensources/book/perens.html) 98 | * Stop at "Analysis of the Open Source Definition" 99 | * *Consider starting the Version Control chapter (below)* 100 | * *Consider starting the Source Control for Pointy Hairs Paper* 101 | 102 | ### Tues Jan 24 103 | * Discuss Open Source definition essay 104 | * Presentation about giving presentations: Dr. Rottman 105 | * Source Control - overview 106 | * Who gets the commit bit? 107 | * Communications 108 | * **Homework**: Read [Chapter 3 - Version Control](http://producingoss.com/en/vc.html) section 109 | * *Remember the Source Control for Pointy Hairs paper* 110 | 111 | ### Thurs Jan 26 112 | * Discuss Version Control learnings - [lecture notes](LectureNotes/SourceControlOverview.md) 113 | * Source Control - applied 114 | * Lab: Creating and using repositories 115 | * *Remember the Source Control for Pointy Hairs paper* 116 | 117 | ### Tues Jan 31 118 | * Source Control - Additional concepts - [lecture notes](LectureNotes/SourceControlAdditional.md) 119 | * Beware of "fork" term 120 | * Branching 121 | * Tags 122 | * Source Control - applied 123 | * Lab: Pull requests and patches 124 | * **Homework**: Source Control for Pointy Hairs paper 125 | 126 | ### Thurs Feb 2 127 | * Paper 1 (Source Control for Pointy Hairs) is due 128 | * Application environments (dev, stage, prod) 129 | * Guest Speaker: [Tom Manor](https://www.linkedin.com/in/thomas-manor-7aa2b110), RedHat - Why I trust Open Source software in my production environment 130 | 131 | ### Tues Feb 7 132 | * Source Control - applied 133 | * Another lab to wrap up concepts 134 | * **Homework**: Read [Chapter 7 - Packaging](http://producingoss.com/en/packaging.html#packaging-build-install) "Compilation and Installation" and "Binary packages" subsections 135 | 136 | ### Thurs Feb 9 137 | * Building software - [lecture notes](LectureNotes/Building.md) 138 | * Local builds 139 | * Local tools 140 | 141 | ### Tues Feb 14 142 | * Managing dependencies - [lecture notes](LectureNotes/Dependencies.md) 143 | * What is a dependency? 144 | * Why use a library? 145 | * Automated dependency management 146 | 147 | ### Thurs Feb 16 148 | * Lab - Show how Open Source software can be changed 149 | * Download 150 | * Modify 151 | * Build 152 | 153 | ### Tues Feb 21 154 | * Build systems - [lecture notes](LectureNotes/CI_CD.md) 155 | * Overview 156 | * What are they/Why do I care? 157 | * Declaration of build steps 158 | * Continuous Integration (CI) 159 | * Continuous Delivery/Deployment (CD) 160 | * **Homework**: Read Chapter 5 - [Economics of Open Source](http://producingoss.com/en/money.html#economics-of-open-source) and [Types of Corporate Involvement](http://producingoss.com/en/types-of-corporate-involvement.html) 161 | 162 | ### Thurs Feb 23 163 | * Guest Speaker: [Brian Lock](https://www.linkedin.com/in/brian-lock-9390491), Pivotal - How we as a company make money with Open Source 164 | * **Homework**: Read [Chapter 3 - Bug Tracker](http://producingoss.com/en/bug-tracker.html) 165 | 166 | ### Tues Feb 28 167 | * Discuss bug tracking chapter learnings - [lecture notes](LectureNotes/Issues.md) 168 | * Issue Tracking - overview 169 | * Bugs vs issues 170 | 171 | ### Thurs Mar 2 172 | * Issue Tracking - applied 173 | * Lab: Create an issue 174 | * **Homework**: Create your own issue 175 | * If this issue is for our class, resolve it with a pull request 176 | * If this issue is in a real project, extra points if you resolve it! 177 | 178 | ### Tues Mar 7 179 | * Go around the room 180 | * What issue did you report? 181 | * Open time - questions/review for midterm 182 | 183 | ### Thurs Mar 9 184 | Mid term examination 185 | 186 | (Mar 13 - mid semester) 187 | 188 | ### Tues Mar 14 189 | * Communities and their importance - [lecture notes](LectureNotes/Communities.md) 190 | * Community models (part 1) - [lecture notes](LectureNotes/CommunityModels.md) 191 | 192 | ### Thurs Mar 16 193 | * Community models (part 2) - [lecture notes](LectureNotes/CommunityModels.md) 194 | * Growth of open communities (non-code related) 195 | * Wikipedia/Creative Commons 196 | * Open Education 197 | * Open Government 198 | * Open Street Maps 199 | 200 | ### Tues Mar 21 201 | * Licenses!!! - [lecture notes](LectureNotes/Licenses.md) 202 | * Questions that must be asked of every license 203 | * What are the terms, are they compatible with planned use? 204 | * The "big" licenses [source](https://www.blackducksoftware.com/resources/data/top-20-open-source-licenses) 205 | * MIT 206 | * GPL 2/3 207 | * Apache 2 208 | * BSD 209 | 210 | ### Thurs Mar 23 211 | * Guest Speaker: [Chris Kampmeier](https://www.linkedin.com/in/ckampmeier), Mastercard - What is Innersourcing and why we want it 212 | * **Homework**: Read [Chapter 3 - Mailing Lists/Message Forums](http://producingoss.com/en/message-forums.html) 213 | 214 | ### Tues Mar 28 (spring break) 215 | ### Thurs Mar 30 (spring break) 216 | 217 | ### Tues Apr 4 218 | * Discuss communications tools learnings - [lecture notes](LectureNotes/CommunicationsTools.md) 219 | * Communications tools 220 | * Mailing lists 221 | * IRC 222 | * Forums 223 | 224 | ### Thurs Apr 6 225 | * Foundations - [lecture notes](LectureNotes/Foundations.md) 226 | * Their role (some examples) 227 | * US Non-for-profit types 228 | * Paper 2 (The Best Open Source License is...) is due 229 | 230 | ### Tues Apr 11 231 | * Getting involved - [lecture notes](LectureNotes/GettingInvolved.md) 232 | * The importance of credibility in the community 233 | * A path to getting engaged 234 | * User 235 | * Contributor 236 | * Committer 237 | * Voter 238 | * **Homework** Read [Chapter 4 - Social and Political Infrastructure - Consensus-based Democracy](http://producingoss.com/en/consensus-democracy.html) 239 | 240 | ### Thurs Apr 13 241 | * Guest Speaker: [Rich Bowen](https://www.linkedin.com/in/rcbowen), Apache Software Foundation - The Apache Way 242 | * **Homework**: Read [Chapter 2 - Documentation](http://producingoss.com/en/getting-started.html#documentation) 243 | 244 | ### Tues Apr 18 245 | * Development best practices - [lecture notes](LectureNotes/Documentation.md) 246 | * Documentation 247 | * MUST have files: README, CHANGELOG, LICENSE 248 | * Wiki, FAQ, Website 249 | * Developer guidelines 250 | * Translation 251 | 252 | ### Thurs Apr 20 253 | * Software delivery methodologies - [lecture notes](LectureNotes/SDLCMethodologoies.md) 254 | * Waterfall 255 | * AGILE 256 | 257 | ### Tues Apr 25 258 | * OSS Project presentations 259 | * What is the project? 260 | * Aspects about it (governance, community, etc) 261 | * **Homework**: Read [Chapter 7 - Release Numbering](http://producingoss.com/en/development-cycle.html#release-numbering) and [Chapter 7 - Stabilizing a Release](http://producingoss.com/en/stabilizing-a-release.html) 262 | 263 | ### Thurs Apr 27 264 | * Releasing software - [lecture notes](LectureNotes/Releasing.md) 265 | * Versioning 266 | * Release procedures 267 | 268 | ### Tues May 2 269 | * Final exam review 270 | 271 | ### Thurs May 4 272 | * "Guest Speaker": [Daniel Ruggeri](https://www.linkedin.com/in/danielruggeri), business guy - How to not suck at business 273 | 274 | (May 6 - end of classes) 275 | 276 | May 9 (finals) 277 | * Held in 212 ESH 278 | 279 | May 11 (finals) 280 | 281 | (May 13 - semester close) 282 | 283 | 284 | ## Thanks and Attributions 285 | This class has been shaped through input from many folks, but a few notable attributions are deserved: 286 | * [Seokchan (Channy) Yun's open-source-class](https://code.google.com/archive/p/open-source-class/) 287 | * [The Apache Software Foundation community development project](http://community.apache.org/) - ([mailing list archive](https://lists.apache.org/list.html?dev@community.apache.org)) 288 | * [Karl Fogel](https://en.wikipedia.org/wiki/Karl_Fogel)'s work on the [Producing Open Source Software](http://producingoss.com/) book 289 | -------------------------------------------------------------------------------- /2019-Spring-WashU.md: -------------------------------------------------------------------------------- 1 | # Computer Science and Engineering - Software Engineering Workshop 2 | An introduction and exploration of concepts and issues related to large-scale software systems development. Areas of exploration include technical complexities, organization issues, and communication techniques for large-scale development. Students participate through teams emulating industrial development. The projects cover the principal system development life-cycle phases from requirements analysis, to software design, and to final implementation. Issues relating to real-time control systems, human factors, reliability, performance, operating costs, maintainability, and others are addressed and resolved in a reasonable manner. Prerequisite: Junior or Senior standing 3 | 4 | ## Course Overview 5 | This course is intended to introduce students to the concepts of Open Source software development as well as deliver a software product for a real-world client. Specific areas of focus are: 6 | * History of Open Source 7 | * Communities and governance 8 | * Technologies used 9 | * Source control 10 | * Communications tools 11 | * Issue trackers 12 | * Legal aspects (licensing/foundations) 13 | 14 | Additionally, students should expect to be challenged in areas of personal development related to the business environment such as giving presentations, writing position papers and performing the full lifecycle of software development in a team setting. 15 | 16 | ### Administrativia 17 | Daniel Ruggeri - druggeri primary.net 18 | 19 | Daniel Evans - evans23 wustl.edu 20 | 21 | Mon/Wed 5:30pm - 7:00pm, 101 [Lopata Hall](https://goo.gl/maps/3rnB1baNspK2) 22 | 23 | E81 CSE 437S 24 | 25 | #### Textbook 26 | Open Source Software ~ *Karl Fogel* 27 | 28 | ISBN: 0596007590, ISBN-13: 978-0596007591 29 | 30 | Download free at [http://producingoss.com/](http://producingoss.com/) 31 | 32 | ## Assignments and Grading 33 | In full transparency, the assignments as well as how they are graded are shared in this section 34 | 35 | ### Team Project 36 | This is the bulk of the grade you will earn as well as the primary focus of the class. 37 | Each student will participate in a team responsible for delivering a software product to a client. 38 | By the middle of the semester, an [MVP](https://en.wikipedia.org/wiki/Minimum_viable_product) should be completed. 39 | By the end of the semester, the final project with client feedback incorporated is expected. 40 | * Students will share ideas of projects in the second week 41 | * The client may be any real-world use case. Non-for-profits, corporate projects, campus projects, etc are all encouraged 42 | * You may not be your own client 43 | * Your client and their satisfaction is greatly important 44 | * Teams will be self-formed by the students and will consist of five to seven students 45 | * Each member of the team will receive the same grade for the project as a whole 46 | * Choose your teammates wisely - ensure coverage of important skills (code and non-code) 47 | 48 | 49 | Grading for the project will be based on the effective execution of the following SDLC aspects: 50 | * Gathering requirements and understanding the client's needs 51 | * Incorporating client feedback into designs post-MVP 52 | * Overall project planning and timing 53 | * Time management and aligning deliverables in expected sprints 54 | * User experience and non-code materials (documentation, UI, ease of use, etc) 55 | * "Marketing" and presenting the final result 56 | * Effective use of team skills and individual expertise 57 | * Client evaluation of the delivered product 58 | 59 | The system must be delivered in whole for grading. 60 | Examples: 61 | * Projects delivering a web-based resource would provide the public URL and credentials for evaluation 62 | * Projects delivering mobile applications would provide a physical device for evaluation (sorry - instructor will not install things onto his gear) 63 | * Projects delivering software that operates on a desktop environment would provide a virtual machine image (VirtualBox preferred) on a thumb drive 64 | 65 | The final system will be presented to the class and your clients. 66 | This presentation will take between 20 and 30 minutes. 67 | 68 | ### Homework 69 | Homework assignments will be passed out from time to time involving reading, researching or taking some action. These assignments should be completed by the next class 70 | 71 | ### Presentation 72 | Each student will be required to give a short presentation about a topic related to Open Source of their choosing (approved by instructor). 73 | The presentation should be 5 to 10 minutes long. 74 | 75 | The reason for this requirement is two-fold: 76 | * To ensure a certain level of mastery of the topic such that it can be explained well 77 | * To ensure a certain level of mastery *in giving a presentation* 78 | 79 | This is so each student gets experience in exercising their "marketing" muscle which is not only required in the world of business, but also the world of Open Source. 80 | While presentations will be graded on content, a significant portion of the grade will also come from organization of the content, aesthetics of any materials presented as well as the ability to adhere to guiding principles for good presentations. 81 | 82 | Some ideas: 83 | * Why I love the (name) Open Source project 84 | * Five ways to make money on Open Source 85 | * An analysis of Open Source license X versus license Y 86 | * A guide to getting started in an Open Source project 87 | 88 | ### Writing 89 | Communicating well is critically important in the world outside of the classroom and, similar to giving presentations, is a muscle that must be exercised regularly. 90 | Students will be tasked with writing short papers in the form of: 91 | ** Summary documents ** which should be written in a form suitable for a manager to understand the landscape or overview of a concept they are not familiar with. In addition to the points earned in position papers, these documents will also be graded on accuracy of their factual contents and the simplification of complex topics. 92 | 93 | #### Source Control for Pointy Hairs 94 | Exactly 1 physical page 95 | I am a manager that has worked in manufacturing all of my career but have recently moved to become the manager of a software development team. 96 | I hear people mention "source control" and things like "commit", "branch", "tag" and such but I don't know what any of these things are. 97 | Provide me a one-pager that explains what source control is and gives a few key terms/definitions. 98 | 99 | ### Participation 100 | The world of Open Source is driven by community so it is important that the community within our classroom is full of individuals willing to contribute to the success of the whole class. 101 | Therefore, participation during discussions and presentations as well as within code and the project will be measured over the course of the semester and will contribute to a significant portion of the grade. 102 | 103 | ### Extra Credit 104 | Through the course of the semester, students will have opportunities to earn extra credit. 105 | Opportunities will be shared as they come along. 106 | * Contribute fixes to this course's content 107 | * Contribute fixes to a real Open Source project 108 | * Attend [ACM events](https://acm.wustl.edu/) 109 | 110 | ### Breakdown 111 | | Item | Points | Percentage | 112 | | --------------------------------------- | -----: | ---------: | 113 | | Homework | 20 | 4% | 114 | | Class Participation | 20 | 4% | 115 | | Paper: Source Control for Pointy hairs | 30 | 6% | 116 | | Presentation: About My Favorite Project | 30 | 6% | 117 | | Midterm | 50 | 10% | 118 | | Final | 50 | 10% | 119 | | Team Project | 300 | 60% | 120 | | **Total** | 500 | | 121 | 122 | 123 | ## Schedule 124 | This is the planned schedule of events for the course. 125 | Since topics may run longer or come up short, expect some minor alterations. 126 | It's also important to note that *when you see **discussion** comes up in the schedule, you should **expect the instructor to ask questions** that will verify your understanding/homework* as well as to cover some of the topics in depth. 127 | 128 | Most class periods will be split between lecture/discussion about Open Source Software topics or class-wide work (30 to 45 minutes) with the remainder of the time dedicated to working within your teams and seeking guidance from the instructor. 129 | 130 | ### Mon Jan 14 131 | * Get to know each other 132 | * Cover syllabus 133 | * Discuss project 134 | * Understand sprints and retros 135 | * **Homework**: Read chapter 1 of book 136 | 137 | ### Wed Jan 16 138 | * Topic: Open Source intro and history - [lecture notes](LectureNotes/IntroAndHistory.md) 139 | * Share and present project ideas 140 | * Post-it notes! 141 | * Begin forming teams and seeing what works 142 | 143 | ### Mon Jan 21 - MLK Holiday 144 | * During the time off, solidify your teams and get cracking 145 | 146 | ### Wed Jan 23 147 | * Topic: TODO 148 | * Teams and projects are set 149 | * Plan and outline sprint 1 150 | * Check-in: 151 | * You know your project well 152 | * Your teammates are now your closest friends :-) 153 | * Analysis should be well under way 154 | * **Homework**: Read [Chapter 3 - Version Control](http://producingoss.com/en/vc.html) section 155 | 156 | ### Mon Jan 28 157 | * Topic: Source Control - [lecture notes](LectureNotes/SourceControlOverview.md) 158 | * *Remember the Source Control for Pointy Hairs paper is coming* 159 | 160 | ### Wed Jan 30 161 | * Topic: Source Control - Additional concepts - [lecture notes](LectureNotes/SourceControlAdditional.md) 162 | * Beware of "fork" term 163 | * Branching 164 | * Tags 165 | * **Homework**: Source Control for Pointy Hairs paper 166 | 167 | ### Mon Feb 4 168 | * Paper (Source Control for Pointy Hairs) is due 169 | * 12:00 am 2/4/2019 (Sunday Night, Monday Morning) 170 | * 1 Page Single Spaced 171 | * Turn in to evans23 at wustl.edu 172 | * Topic: TODO 173 | * Team project presentations 174 | * Five to ten minutes, as a team 175 | * Who is your client and what is your project? 176 | * Who are your experts in the team? 177 | * **Homework**: Read [Chapter 7 - Packaging](http://producingoss.com/en/packaging.html#packaging-build-install) "Compilation and Installation" and "Binary packages" subsections 178 | 179 | ### Wed Feb 6 180 | * Topic: Building software - [lecture notes](LectureNotes/Building.md) 181 | * Local builds 182 | * Local tools 183 | * Plan and outline sprint 2 184 | * Sprint 1 retro 185 | * Check-in: 186 | * Analysis should be complete 187 | * Design should be under way 188 | * Some code should already be in development 189 | * UX thoughts should be starting to form 190 | 191 | ### Mon Feb 11 192 | * Topic: Managing dependencies - [lecture notes](LectureNotes/Dependencies.md) 193 | * What is a dependency? 194 | * Why use a library? 195 | * Automated dependency management 196 | 197 | ### Wed Feb 13 198 | * Topic: Application environments (dev, stage, prod) 199 | 200 | ### Mon Feb 18 201 | * Topic: Build systems - [lecture notes](LectureNotes/CI_CD.md) 202 | * Overview 203 | * What are they/Why do I care? 204 | * Declaration of build steps 205 | * Continuous Integration (CI) 206 | * Continuous Delivery/Deployment (CD) 207 | * **Homework**: Read Chapter 5 - [Economics of Open Source](http://producingoss.com/en/money.html#economics-of-open-source) and [Types of Corporate Involvement](http://producingoss.com/en/types-of-corporate-involvement.html) 208 | 209 | ### Wed Feb 20 210 | * Topic: Let's talk DevOps 211 | * Sprint 2 retro 212 | * Plan and outline sprint 3 213 | * Check-in: 214 | * Overall design should be gelled 215 | * Double-check analysis work - anything to revisit? 216 | * Continue coding 217 | * **Homework**: Read [Chapter 3 - Bug Tracker](http://producingoss.com/en/bug-tracker.html) 218 | 219 | 220 | ### Mon Feb 25 221 | * Topic: Discuss bug tracking chapter learnings - [lecture notes](LectureNotes/Issues.md) 222 | * Issue Tracking - overview 223 | * Bugs vs issues 224 | 225 | ### Wed Feb 27 226 | * Topic: Issue Tracking - applied 227 | * Lab: Create an issue 228 | * **Homework**: Create your own issue 229 | * If this issue is for our class, resolve it with a pull request 230 | * If this issue is in a real project, extra points if you resolve it! 231 | 232 | ### Mon Mar 4 233 | * Go around the room 234 | * What issue did you report? 235 | * Open time - questions/review for midterm 236 | 237 | ### Wed Mar 6 238 | * **Mid term examination** 239 | * Sprint 3 retro 240 | * Plan and outline sprint 4 241 | * Check-in: 242 | * MVP!!! 243 | * Major internal system integrations are in place 244 | * Major external system integrations are well under way 245 | * Overall design should be complete 246 | * Begin designing/creating documentation 247 | 248 | ### Mon Mar 11 - Spring Break 249 | ### Wed Mar 13 - Spring Break 250 | 251 | ### Mon Mar 18 252 | * Topic: Communities and their importance - [lecture notes](LectureNotes/Communities.md) 253 | 254 | ### Wed Mar 20 255 | * Topic: Releasing software - [lecture notes](LectureNotes/Releasing.md) 256 | * Versioning 257 | * Release procedures 258 | 259 | ### Mon Mar 25 260 | * Topic: Community models (part 1) - [lecture notes](LectureNotes/CommunityModels.md) 261 | * Open Source Presentations 262 | * Presenter 1: Dorian Stubblefield 263 | * Topic: Henry Ford's contribution to open source. 264 | * Presenter 2: 265 | * Topic: 266 | * Presenter 3: Joshua Gelbard 267 | * Topic: Swift - Apple's Surprise Move 268 | 269 | ### Wed Mar 27 270 | * Topic: Community models (part 2) - [lecture notes](LectureNotes/CommunityModels.md) 271 | * Sprint 4 retro 272 | * Plan and outline sprint 5 273 | * Check-in: 274 | * Client has reviewed MVP and provided feedback 275 | * Integration of code pieces should be well under way 276 | * Test cases should be in place for units 277 | * Plan to integrate client feedback into project 278 | * **Homework**: Read [Chapter 3 - Mailing Lists/Message Forums](http://producingoss.com/en/message-forums.html) 279 | * Open Source Presentations 280 | * Presenter 1: 281 | * Topic: 282 | * Presenter 2:Nirek Sharma 283 | * Topic: Why I Like VSCode 284 | * Presenter 3: Lucas Florence 285 | * Topic: Five ways to make money on Open Source 286 | 287 | ### Mon Apr 1 288 | * Topic: Communications tools - [lecture notes](LectureNotes/CommunicationsTools.md) 289 | * Mailing lists 290 | * IRC 291 | * Forums 292 | * Open Source Presentations 293 | * Presenter 1: 294 | * Topic: 295 | * Presenter 2: 296 | * Topic: 297 | * Presenter 3: Visaal Ambalam 298 | * Topic: What is Kafka? 299 | 300 | ### Wed Apr 3 301 | * Topic: Foundations - [lecture notes](LectureNotes/Foundations.md) 302 | * Their role (some examples) 303 | * US Non-for-profit types 304 | * Open Source Presentations 305 | * Presenter 1: John Bisognano 306 | * Topic: Scaling genomics with Spotify 307 | * Presenter 2: 308 | * Topic: 309 | * Presenter 3: 310 | * Topic: 311 | 312 | ### Mon Apr 8 313 | * Topic: Getting involved - [lecture notes](LectureNotes/GettingInvolved.md) 314 | * The importance of credibility in the community 315 | * A path to getting engaged 316 | * User 317 | * Contributor 318 | * Committer 319 | * Voter 320 | * Open Source Presentations 321 | * Presenter 1: Ethan Shry 322 | * Topic: GraphQL > REST 323 | * Presenter 2: Dan Schaeffer 324 | * Topic: pfSense Open Source Firewall and Router 325 | * Presenter 3: 326 | * Topic: 327 | 328 | ### Wed Apr 10 329 | * Sprint 5 retro 330 | * Plan and outline final sprint 331 | * Check-in: 332 | * Client has reviewed the updates based on their feedback 333 | * Get more client feedback!!! 334 | * Presentation planning has started 335 | * Open Source Presentations 336 | * Presenter 1: Junbin Ma 337 | * Topic: Challenges for OSS maintainers - real world examples 338 | * Presenter 2: David Huang 339 | * Topic: Be careful who you trust (npm event-stream) 340 | * Presenter 3: Louise Zhu 341 | * Topic: Mozilla Firefox and community led marketing 342 | 343 | ### Mon Apr 15 344 | * Topic: Development best practices - [lecture notes](LectureNotes/Documentation.md) 345 | * Documentation 346 | * MUST have files: README, CHANGELOG, LICENSE 347 | * Wiki, FAQ, Website 348 | * Developer guidelines 349 | * Translation 350 | * Open Source Presentations 351 | * Presenter 1: Benjamin Choi 352 | * Topic: What is Apigee 353 | * Presenter 2: Mystery Presenter 354 | * Topic: Open Source IPO's 355 | * Presenter 3:Christian Anyanwu 356 | * Topic: Why most of Machine Learning is Open Source 357 | * Presenter 4: Jin Han 358 | * Topic: Leaflet - a JavaScript library for mobile-friendly interactive maps 359 | * Presenter 5: Yipeng Wang 360 | * Topic: Why Hugo Is the Best Open Source Static Site Generator 361 | * Presenter 6: Shane Tong 362 | * Topic: History and Future of JavaScript and Node.js 363 | * Presenter 7: Julia Dickerman 364 | * Topic: Open Source's Inclusivity Problem 365 | 366 | ### Wed Apr 17 367 | * Topic: Guest speaker: [Joanna Lee](https://www.linkedin.com/in/joanna-lee-9630935) 368 | * **Homework**: Read [Chapter 7 - Release Numbering](http://producingoss.com/en/development-cycle.html#release-numbering) and [Chapter 7 - Stabilizing a Release](http://producingoss.com/en/stabilizing-a-release.html) 369 | * Open Source Presentations 370 | 371 | ### Mon Apr 22 372 | * Topic: Licenses!!! - [lecture notes](LectureNotes/Licenses.md) 373 | * Questions that must be asked of every license 374 | * What are the terms, are they compatible with planned use? 375 | * The "big" licenses [source](https://www.blackducksoftware.com/resources/data/top-20-open-source-licenses) 376 | * MIT 377 | * GPL 2/3 378 | * Apache 2 379 | * BSD 380 | * Final Exam Review 381 | * Open Source Presentations 382 | * Presenter 1: Kevin Fu 383 | * Topic: Wine (What is it good for?) 384 | * Presenter 2: Jianxing (Jason) Liao 385 | * Topic: Why is LibreOffice so powerful? 386 | * Presenter 3: Siam Abd Al-Ilah 387 | * Topic: Why I like Kotlin 388 | 389 | ### Wed Apr 24 390 | * Conclusion of Final examination 391 | * Sprint 6 retro 392 | * Check-in: 393 | * Client loves the project 394 | * Documentation should be in place 395 | * Presentation should be ready 396 | * Open Source Presentations 397 | * Presenter 1: Kevin Ha 398 | * Topic: React Native makes lives easier 399 | * Presenter 2: Aumesh Misra 400 | * Topic: What is Kubernetes? 401 | * Presenter 3: Dominique Senteza 402 | * Topic: Open Source and IoT 403 | * Presenter 4: Zahra Lambe 404 | * Topic: Open Source and Blockchain 405 | 406 | ### Mon May 6 407 | * Project presentations -- Cupples II L 015 408 | * Presenter 1: Cambridge 409 | * Presenter 2: Amazon 410 | * Presenter 3: Pupil 411 | 412 | ### Wed May 8 413 | * Project presentations -- Cupples II L 015 414 | * Presenter 1: Sicnum 415 | 416 | 417 | ## Thanks and Attributions 418 | This class has been shaped through input from many folks, but a few notable attributions are deserved: 419 | * [Seokchan (Channy) Yun's open-source-class](https://code.google.com/archive/p/open-source-class/) 420 | * [The Apache Software Foundation community development project](http://community.apache.org/) - ([mailing list archive](https://lists.apache.org/list.html?dev@community.apache.org)) 421 | * [Karl Fogel](https://en.wikipedia.org/wiki/Karl_Fogel)'s work on the [Producing Open Source Software](http://producingoss.com/) book 422 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2016 Daniel Ruggeri 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /LectureNotes/Building.md: -------------------------------------------------------------------------------- 1 | # Delivering 2 | * Turns raw code into a potential product 3 | * Demonstration to drive home the point that this is a _process_ 4 | * Download software 5 | * Unpack it 6 | * ./configure --blah 7 | * make 8 | * make install 9 | 10 | 11 | ## Overview 12 | * Code by itself is not useful 13 | * It must be made useful for machines before it is useful for people 14 | * For compiled languages, the code must be turned into machine-readable format 15 | * C, Java, .net, golang 16 | * Interpreted languages also compile... They just do it for you just before running 17 | * Perl, python, ruby 18 | * Scripts are raw commands 19 | * Bash, bat, sh 20 | * Steps to become useful (not all always apply) 21 | * *Compiling* - transforms the code from human format to machine instructions 22 | * Requires a compiler program 23 | * The compiler spits out a binary format used by the runtime 24 | * Examples... 25 | * Java: JVM 26 | * C: libc, libcmt 27 | * Python: pyc 28 | * Let's see it in action... 29 | * Commence the compiling demonstration below 30 | * *Packaging* or bundling gets the compiled code to a deployable _thing_ 31 | * Collect the various binaries into a useful object 32 | * Generally an archive 33 | * Native OS packages 34 | * RPM 35 | * deb 36 | * MSI 37 | * Regular archives 38 | * zip 39 | * tar 40 | * Runtime specific 41 | * jar (java archive) 42 | * war (java web archive) 43 | * apk (android package kit) 44 | * Dependencies 45 | * Let's talk about that another day... 46 | * Deploy it! 47 | * Stick it into an environment 48 | * See environment definition below 49 | * See runtime definition below 50 | * Highly dependent on what you wrote and how it gets run 51 | * Some examples: 52 | * Deploy your war file to Tomcat 53 | * Unzip your PHP files in docroot 54 | * Use yum to install your RPM on a server 55 | * Deploy your .net project to IIS 56 | * Extract the tarball of your Python scripts in /usr/local/bin 57 | * Use the app store to install your iPhone app 58 | * Done! Now use it 59 | 60 | ## Demonstrations 61 | * Compiling from command line 62 | * teh codez in hello.c 63 | ``` 64 | #include 65 | 66 | main() 67 | { 68 | printf("Hello World"); 69 | } 70 | ``` 71 | * Examine... 72 | * `file hello.c` - What is hello.c? 73 | * The file command tells us what Linux thinks this file is 74 | * Uses magic ([no, really... it's magic](https://en.wikipedia.org/wiki/List_of_file_signatures)) 75 | * `gcc hello.c -o hello` - Compile it 76 | * Text to machine code 77 | * `-o hello` says to write the binary to the file "hello" 78 | * `ls -l` - There's a new file here... 79 | * `file hello` - What is hello? 80 | * `cat hello` - Well that sure isn't text... 81 | * `strings hello` - Runtime library _stuff_ added to our program 82 | * `./hello` - BEHOLD!!! The world has been greeted 83 | * Compiling with NetBeans 84 | * File -> New project 85 | * Java -> Java Application 86 | * Project Name -> HelloWorld 87 | * teh codez in HelloWorld.java 88 | ``` 89 | package helloworld; 90 | 91 | public class HelloWorld { 92 | public static void main(String[] args) { 93 | System.out.println("Hello World"); 94 | } 95 | } 96 | ``` 97 | * Save the file and click the green run button 98 | * BEHOLD!!! The world has been greeted 99 | 100 | ## Vocabulary 101 | * *Compiler* - program that converts instructions from code to machine-usuable instructions 102 | * *Runtime* - a library or program that interprets programming instructions to low level actions. Often greatly simplifies the work for the programmer. 103 | * *Environment* - a collection of local (to the software) configurations, external services (databases, webservices, etc) and the runtime that serve as a delivery point for the software. Environments typically serve a specific purpose such as development, testing, production and disaster recovery. 104 | * *Package/Artifact* - the product of a software build procedure. Typically an archive or collection of the compiled software in a near-ready to ship state. 105 | -------------------------------------------------------------------------------- /LectureNotes/CI_CD.md: -------------------------------------------------------------------------------- 1 | 2 | ## CI 3 | * Compiling software was great... but was dangerous 4 | * What if my computer is compromised? 5 | * What if I am a malicious coder? 6 | * What if I don't want to do all that work? 7 | * What if I made a mistake during the process? 8 | * What if all that takes me too long? 9 | * What if I'm checking in a huuuuge amount of code? 10 | * Analysis result: humans suck! 11 | * Enter Continuous Integration! 12 | * Check code in early and often 13 | * A build plan is created 14 | * The plan identifies the steps required to build 15 | * Also identifies failure points 16 | * A failure at any point should stop the process 17 | * Acts as safety nets 18 | * Tests and whatnot are also defined 19 | * An automated safety net 20 | * Input is the code 21 | * Output is either... 22 | * A failure alert 23 | * Successfully built software 24 | * That's it... no other weird in-between states 25 | * Typical CI steps 26 | * Triggered by some action 27 | * Typically a change in the repo 28 | * Obtains the source tree 29 | * Puts it in a "cleanroom" area 30 | * A known starting state 31 | * Performs static analysis 32 | * "Reading" the code to identify problems before it is built 33 | * No "work" is done with the code - it is just read 34 | * Some examples 35 | * Bad formatting or style 36 | * Syntax errors 37 | * Obvious bugs 38 | * Unused variables 39 | * Unreachable code 40 | * Using uninitialized variables (* not perfect *) 41 | * Potential security issues 42 | * Depending on the analysis, you may choose to pass or fail 43 | * Compiles/builds the software 44 | * Syntax errors should be caught here if not caught by static analysis 45 | * Compiler warnings can become a source of stoppage 46 | * Executes unit and local tests 47 | * Run test against small components 48 | * Example: the function "add" should return 4 when given the parameters 2 and 2 49 | * Packages and bundles the software 50 | * This is the "artifact" 51 | * It **shall not** change from environment to environment! 52 | * Puts it somewhere accessible 53 | * A binary artifact repository 54 | * Similar to source code repository/object store 55 | * Holds immutable (unchangeable) objects 56 | * Each artifact has a unique URL 57 | * Keeps the feedback loop tight 58 | * Failure at any point should notify 59 | * Success at the end should notify 60 | * You know as soon as possible when something isn't right 61 | * Colloquially referred to as "shifting left" 62 | 63 | ## Continuous Delivery 64 | * An extension of Continuous Integration 65 | * A whole discipline in and of itself 66 | * A series of practices to... 67 | * Shorten feedback loop for the customer 68 | * Ensure software is always in a releasable state 69 | * Make releases less scary 70 | * The interesting part (to me, at least) 71 | * Means further automation of the deployment 72 | * Picks up where CI leaves off 73 | * Automates the promotion of code all the way to production 74 | * Steps added on to CI 75 | * Before the code is committed, developer tests locally 76 | * Further "shifting left" 77 | * Run as much unit and integration test as possible 78 | * Find issues before even checking in 79 | * Code gets checked in and CI kicks off 80 | * The artifact gets "promoted" to the next environment 81 | * Testing appropriate for that environment occurs 82 | * New environments may offer new testing opportunities. Some examples... 83 | * Development environment may "stub out" services 84 | * Test environment integrates with those services 85 | * Verify that integration here 86 | * Just like CI, a failure should stop the process 87 | * Staging environment should be like production 88 | * Do performance and load testing here 89 | * Perform security scanning and penetration testing 90 | * Manual testing, too 91 | * Eventually the code is deployed in production 92 | * With minimal human intervention 93 | * With a high degree of confidence the code works 94 | * As a much smaller unit of work 95 | 96 | ## Vocabulary 97 | * *Continuous Integration* - a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. 98 | * *Code promotion* - The act of moving the package/artifact along the delivery lifecycle to the next environment. Example: after successful integration of the code in the development environment, it can be *promoted* to the testing environment 99 | 100 | ## See also 101 | * https://www.thoughtworks.com/continuous-integration 102 | * https://continuousdelivery.com/ 103 | -------------------------------------------------------------------------------- /LectureNotes/CommunicationsTools.md: -------------------------------------------------------------------------------- 1 | # Communications Tools 2 | 3 | * First objective: Stay in close contact with the community 4 | * Several tools help facilitate this 5 | 6 | * Mailing lists 7 | * Primary point of communication 8 | * People subscribe to the list (sometimes it is invite only) 9 | * Used for discussions 10 | * Architectural (how the code works at a high level) 11 | * Development topics 12 | * Community topics 13 | * Can have many lists - most common: 14 | * users 15 | * Where users can ask questions 16 | * Where other users can answer questions 17 | * Chat about how to use the project 18 | * Request features 19 | * Share examples/configs/whatever 20 | * dev 21 | * Share ideas about patches 22 | * Discuss features 23 | * Chat about project priorities 24 | * private 25 | * Not publicly archived - avoid when possible 26 | * Suggest new committers 27 | * Address code of conduct issues/situations 28 | * Archives 29 | * All messages are saved 30 | * Several mail archives exist 31 | * Your project can also archive them 32 | * Some tools help with this 33 | * Allows searching for already discussed topics 34 | * Message Forums 35 | * Many types out there 36 | * Sometimes available on canned hosting sites 37 | * A collection of topics with conversation threads inside 38 | * Users subscribe to the forum 39 | * Can watch a "board" or "topic" and get notifications about all messages in it 40 | * Can watch individual "threads" 41 | * Can be organized just like the mailing lists above (dev, users, private, etc) 42 | * Generally also expected to be archived 43 | * Realtime chat 44 | * Several options here 45 | * IRC (Internet Relay Chat) 46 | * Slack 47 | * Hipchat 48 | * Flowdock 49 | * It's chat... 50 | * People come and go 51 | * Discussions follows whoever is participating 52 | * NOT expected to be archived (sometimes is) 53 | * Some bots integrate with the room 54 | * Answer FAQs 55 | * To notify the chat room about build status 56 | * To kick off builds from chat 57 | * To provide status of services 58 | -------------------------------------------------------------------------------- /LectureNotes/Communities.md: -------------------------------------------------------------------------------- 1 | # Communities 2 | 3 | * Generally speaking, the code cannot stand alone 4 | * Many people have to be involved in keeping it alive 5 | * Refer to first lecture notes... 6 | * Without people who care, projects fail and have issues 7 | * Projects sometimes still fail with people who care 8 | * Software is hard! 9 | * A community... 10 | * Looks out for the code 11 | * Makes enhancements 12 | * Fixes bugs 13 | * Reviews contributions 14 | * Follows strong technical principles 15 | * Looks out for the users 16 | * Holds discussions with them 17 | * Hangs out in places like IRC and email 18 | * Watches the tracker 19 | * Attends/speaks at conferences 20 | * Looks out for the community 21 | * "Polices" the places where discussions happen 22 | * Sets governance and rules for behavior 23 | * Creates a culture 24 | * Finds sources of funding or support 25 | * Money for bandwidth 26 | * Sponsors for hosting 27 | * Scouts/recruits potential talent 28 | * Behaves in a good way 29 | * Protects branding/legal 30 | * The lifeblood of the project 31 | * Having a community helps the odds of the project surviving... 32 | * If someone leaves 33 | * If a competitor enters the arena 34 | * As people become more or less involved 35 | * Open Source communities... 36 | * Have changed how software is produced 37 | * Various new build tools 38 | * Communication methods 39 | * Have changed the way proprietary companies work 40 | * See guest lecture coming about InnerSourcing 41 | * This makes sense (referring to previous lectures) 42 | * When you have motivated smart people together 43 | * The focus is delivering quality software 44 | * Stuff gets done 45 | 46 | -------------------------------------------------------------------------------- /LectureNotes/CommunityModels.md: -------------------------------------------------------------------------------- 1 | # Community models 2 | * Shared from least to greatest community "factor" 3 | * For each one... 4 | * When is it right? 5 | * Challenges 6 | * Examples 7 | * The models are all about *governance* 8 | * What is governance (see definition)? 9 | * Formally put together in bylaws, but not always done so formally as we'll see 10 | * The set of rules around the project that determines who... 11 | * ... gets commit bit 12 | * ... is allowed to make decisions 13 | * ... settles disputes 14 | * ... sets community culture 15 | * ... "owns" the project and branding 16 | * ... determines the license 17 | * Depending on governance model, this may also include corporate governance rules 18 | * Regulatory/compliance 19 | * Legal/risk 20 | 21 | # Models 22 | * Dump and run 23 | * When code is produced and tossed somewhere... 24 | * Not actively developed 25 | * No intent to build a community around it 26 | * Not watched for issues/bugs 27 | * User/code feedback not welcome or ignored 28 | * More or less a dead project 29 | * When is it right? 30 | * Just get the code out there 31 | * Basic utility code 32 | * Challenges 33 | * If the code is great or useful, contributions don't make it back in 34 | * Without a driving "critical mass" of interested devs... 35 | * The code gets copied to several repos for individual intent 36 | * No "one" place exists for improvements 37 | * Feedback has nowhere to go 38 | * Impossible to create a community without a fork 39 | * Dead projects are bad juju! 40 | * Examples 41 | * gist postings 42 | * MOST GitHub/SourceForge/etc projects 43 | * Lone wolf 44 | * A project maintained by one person 45 | * May or may not be actively developed 46 | * Feedback is welcomed in some way 47 | * Common on GitHub/SourceForge/etc 48 | * Generally not enough "critical mass" for a community 49 | * When is it right? 50 | * Project is small 51 | * Desire to BEGIN a community 52 | * Individual still wants to assert some sort of control 53 | * Project direction 54 | * Branding 55 | * Challenges 56 | * It's hard for one person to keep up if the project becomes popular 57 | * High risk of project dying if the individual... 58 | * gets busy with life 59 | * loses interest 60 | * walks away 61 | * does not foster a growing community 62 | * There may be no intent to create a community 63 | * Sometimes individuals have trouble letting go of control 64 | * Examples 65 | * TeX from history lecture 66 | * Branding note in license 67 | * Open Source, closed governance 68 | * A living project still controlled by a single point 69 | * A step up from lone wolf 70 | * Often maintained by a single "entity" 71 | * Effort is made to SHOW that it isn't just "one person" 72 | * Often much higher community involvement 73 | * Common with companies who open their code 74 | * Still want to control direction 75 | * Want to focus on specific features 76 | * The "entity" may actually be... 77 | * A single person in a company, but shrouded by the company 78 | * A delivery team in a company 79 | * An entire department of a company 80 | * An entire company 81 | * When is it right? 82 | * Same as lone wolf, plus... 83 | * Project is the foundation for a bigger project 84 | * This isn't the service I provide, but is required by it 85 | * Other projects depend on this one 86 | * Challenges 87 | * Community direction is still "owned" by a central point 88 | * Some view this model as a less-than-open model 89 | * Idealism comes into play 90 | * But the code is open, and that IS good 91 | * The "entity" can take the project any direction 92 | * Whether the community likes it or not 93 | * A fork is an option, but forks still suck 94 | * The "entity" can be torn between their goals and the community 95 | * Examples 96 | * Netflix Open Source 97 | * Lots of tools/utilities that Netflix controls 98 | * The code isn't making them money, but it sure is driving their business 99 | * ACTIVE community participation (feedback is WELCOME) 100 | * Paid membership/Invite only 101 | * The governing body is multiple entities, but access to the body is limited in some way 102 | * The "entity" that governs the project is composed of more than one... 103 | * Person 104 | * Company 105 | * *Commercial interest* 106 | * Creates a governance _community_ for the project 107 | * This makes it so no one "company/person" has final say 108 | * Splits ownership of the project to a collective 109 | * Reduces risk of one company failing and the project dying 110 | * Reduces the ability for a particular industry to dominate the project 111 | * Obtaining rights to the "governing board" is limited 112 | * Sometimes seats are paid for 113 | * Sometimes is done only by invite 114 | * Status in the industry 115 | * Commercial interest 116 | * *NOT* merit based - that is our next model 117 | * Often the governing body is a foundation 118 | * A "single" entity composed of many 119 | * More to come about foundations 120 | * When is it right? 121 | * To expand the governance of the project beyond a single commercial interest 122 | * Helps spread the load 123 | * More perspectives 124 | * When the project wants to show it is independent of one company 125 | * Further community growth 126 | * When you want to instill confidence in the project 127 | * Challenges 128 | * Growing governance group creates growing opinions 129 | * Managing the governing body becomes a task in addition to managing the code 130 | * Conflicting interests and objectives have to be resolved 131 | * Sometimes conflict can spill into code discussions 132 | * Charter and rules for how to gain membership is neccessary 133 | * Some view this as "pay to play" 134 | * ... and consider it less-than-open 135 | * Access to governing body is reserved for those who can afford it 136 | * Examples 137 | * Eclipse 138 | * OpenStack (note that individuals are also on board) 139 | * All volunteers (open code AND governance) 140 | * Single governing body over the project that is open to anyone 141 | * Nearly identical to previous example 142 | * Except access to the board comes from project involvement 143 | * Meritocracy (see definition) 144 | * Often requires individuals, not companies, to participate 145 | * When is it right? 146 | * As above, plus showing complete independence of the project from corporations 147 | * Challenges 148 | * "Corporate shills" 149 | * Individuals or teams that participate only to serve corporate interests 150 | * Gives influence to a company when intended for individuals 151 | * Governing an open governance board is, itself, a large challenge 152 | * Often described as organized chaos 153 | * Those that DO, may not be the best at LEADING 154 | * Often made up entirely of volunteers 155 | * See risks about Lone Wolf and volunteerism 156 | * Examples 157 | * Apache Software Foundation 158 | * Software Freedom Conservancy 159 | 160 | # Vocabulary 161 | * **governance** - a set of rules applicable to a project that defines important aspects of how decisions are made in the project 162 | * **bylaws** - a rule made by a company or society to control the actions of its members. 163 | * **Meritocracy** - Philosophy holding that power should be vested in individuals almost exclusively based on ability and talent. In Open Source communities, this also includes contribution to the project. 164 | -------------------------------------------------------------------------------- /LectureNotes/Dependencies.md: -------------------------------------------------------------------------------- 1 | # Dependencies and Libraries 2 | 3 | ## Dependency 4 | * Note the vocabulary definition 5 | * Simply: My software needs other software to do its job 6 | * Why would I depend on other software? 7 | * Well, more on that later 8 | * Slight expansion on typical term 9 | * Dependencies are also components in the environment 10 | * A database or backing store 11 | * A web service 12 | * A translation service 13 | * Anything that your software needs outside of your code to operate 14 | * Creates a link to functionality 15 | * Nearly every piece of software has dependencies 16 | * Runtime 17 | * JVM 18 | * libc 19 | * interpreters 20 | * Runtime libraries 21 | * java.lang.* 22 | * stdio.h 23 | 24 | ## Libraries 25 | * See definition 26 | * A library helps do work you don't have to do 27 | * Defines functions you can call to do things 28 | * Specifies data types that you may operate on 29 | * Reasons to use a library 30 | * The code already exists 31 | * The work needed is hard 32 | * Special eye on security 33 | * Special eye on where things can go wrong 34 | * Special eye on experts who have already done it 35 | * Excellent examples 36 | * [OpenSSL](https://github.com/openssl/openssl/tree/master/crypto/aes) - AES code 37 | * [Apache Commons HTTP client](http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/java/org/apache/commons/httpclient/) -HTTP handling 38 | * [Ruby](https://github.com/ruby/ruby/blob/trunk/lib/resolv.rb) - DNS resolver 39 | * Your program declares a need for the library 40 | * Java - `import com.bitnebula.ILYB` 41 | * Ruby - `require 'ilyb'` 42 | * C/C++ - `#include ilyb.h` 43 | * It can then call functions in the library or refer to types in it 44 | * How??? 45 | * When the code is compiled, the compiler (or linker) creates a link to the library 46 | * It needs to know where to find the data 47 | * Example: with C, function declarations and types are in header files 48 | * Compilers hande this differently 49 | * Java: the code has a public method in a compiled class in a jar file 50 | * Perl: the @INC paths are searched for modules used 51 | * C: the -I argument includes a path to header files to find fxns 52 | * When found, a link is made during compilation 53 | * During runtime... 54 | * The runtime attempts to locate the compiled dependency 55 | * May be part of the runtime 56 | * May be outside the runtime, but brought in 57 | * Compiled languages search paths for the library 58 | * Interpreted languages also search paths, but execute the dependency rather than oink to it 59 | * Finding libraries is different per runtime 60 | * Java: CLASSPATH 61 | * C/C++: LD_LIBRARY_PATH (Linux/Solaris), LIBPATH (AIX), PATH (Windows) 62 | * .NET: placed in bin directory 63 | * Ruby: GEM_PATH 64 | * Perl: @INC, PERL5LIB 65 | * Most are environment variables 66 | * Now that it knows where the code is, it uses it when appropriate 67 | * Static versus shared 68 | * A shared library is outside of the binary 69 | * Must be on the machine running the code 70 | * Search paths are examined when the program starts 71 | * Libraries can be installed in a common place 72 | * All programs dependent on the library use the same one 73 | * Permits upgrading just that library 74 | * Again, different formats per runtime 75 | * UNIX/Linux: .so file (shared object) 76 | * Windows: .dll file (dynamically linked library) 77 | * Java: .jar file (Java archive) 78 | * Are consumed in compiled form 79 | * Proprietary code is often distributed this way (binary form) so it can be used 80 | * A static library is compiled into the resulting executable 81 | * Dependencies travel with the binary 82 | * Does not require the library to be on the system 83 | * Increases the size of the binary 84 | * Must have the source code or the object file 85 | * Complex applications have complex dependencies 86 | * Some (scary) examples: 87 | * [TheDailyWTF](http://thedailywtf.com/articles/The-Enterprise-Dependency) 88 | * [Blog post](http://technogems.blogspot.com/2011/09/dependency-graph-visualization.html) 89 | * [libxml by Meeting C++](https://meetingcpp.com/index.php/br/items/releasing-boost-dependency-analyzer-1-1.html) 90 | * Sometimes it gets out of hand 91 | * Dependency hell 92 | * Version specific links between dependencies 93 | * Conflicting needs 94 | * Example: foo 95 | * Depends on: libfoo v1 96 | * Depends on: libbar v2.3 97 | * Depends on: libwhatev v3.3 98 | * Depends on: libfoo v2.8 99 | * Depends on: libintl v1.1 100 | * Two different versions of libfoo are needed 101 | * Not a big deal if v2 is fully backwards compatible and the binary was not linked against the specific version 102 | * Otherwise... You are in bad shape 103 | 104 | ## Automated dependency management 105 | The civilized way to deal with builds 106 | 107 | * Remember how we said the libraries need to be there during build? 108 | * Where do you find them? 109 | * Is it safe to download and use? 110 | * Born in the Open Source world 111 | * Apache Ant -> Apache Maven -> Gradle 112 | * Simplifies finding and building against dependencies 113 | * Maintains a registry of libraries and where to get them 114 | * Obtains the libraries at build time 115 | * Automates the build of the project 116 | * Build procedures are declared 117 | * Tasks are executed automatically 118 | * Non-dependent tasks can be parallelized 119 | * Scales to very large and complex projects 120 | * Incremental builds 121 | 122 | 123 | ## Vocabulary 124 | * *Dependency* - A loose term when a piece of software relies on another piece of software to function. 125 | * *Library* - A collection of resources used by a program to perform work. May include configuration data, documentation, help data, message templates, pre-written code and subroutines, classes, values or type specifications. Colloquially, a library usually means function definitions, routines and types in compiled form used by your program. 126 | * *Coupling* - the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules. 127 | -------------------------------------------------------------------------------- /LectureNotes/Documentation.md: -------------------------------------------------------------------------------- 1 | # Must have documentation 2 | 3 | * If you want your community to grow, people have to be able to... 4 | * ... find your project 5 | * ... use your project 6 | * ... build your project 7 | * ... contribute to your project 8 | * Documentation is critical! 9 | * There is never enough 10 | * It is never good enough 11 | * It is never fun to make 12 | * Anecdote about documentation... 13 | * Inversely useful 14 | * Those that KNOW the stuff, don't need it 15 | * ...but need to write it 16 | * Doco is difficult to write from a newbie's viewpoint 17 | * Things you "just know" can be hard to document 18 | * Generally, coders do not like writing doco 19 | * It is laborious 20 | * It is drudgery 21 | * It's painful to write down the stuff you already know 22 | 23 | * Files that must exist in your source tree 24 | * README 25 | * **SUPER IMPORTANT** 26 | * All of the immediately important things about the project 27 | * What is this stuff (the files inside) 28 | * How do I build this software? 29 | * Required [dependencies](Dependencies.md) 30 | * What build software is used (may mean I have to download something else) 31 | * Environment or command line variables 32 | * Sometimes this can be pretty involved, so lives in its own file called BUILDING 33 | * How do I use the software? 34 | * Required [dependencies](Dependencies.md) for runtime 35 | * Basic overview 36 | * Should be a pointer to the full documentation 37 | * Cool trick: In GitHub, make a README.md file 38 | * This becomes the landing page of your project 39 | * Most hosting tools work this way as well 40 | * CHANGELOG 41 | * Informs users what noteworthy changes have occurred 42 | * High level notes 43 | * A quick glance to know if the new version is worth grabbing 44 | * It fixes a bug 45 | * It adds a feature 46 | * It improves performance 47 | * LICENSE 48 | * The exact text of your [license](Licenses.md) 49 | * Lets the users know what they are getting into 50 | * Informs people inclined to contribute what model this project has 51 | * Some users or developers look for certain licenses 52 | * CONTRIBUTING 53 | * This is an overview of how to give back to the project 54 | * What work is expected before a contribution should be made 55 | * Examples: 56 | * Software compiles 57 | * Passes test cases 58 | * CLA or attribution made 59 | * Pull request or patch file generated 60 | * Ticket opened in tracker 61 | * Discussed on dev list 62 | * How the contributor should expect to interact 63 | * Discussion of the contribution 64 | * Actual submission of the bits 65 | * How the community is expected to respond 66 | * Sometimes succinct enough to go in README 67 | 68 | * Other documentation 69 | * WIKI 70 | * Stands for "What I Know Is" 71 | * Open place where documentation can quickly be thrown together 72 | * Most wikis provide lightweight editing facilities 73 | * Very easy to get going 74 | * Beware 75 | * These often fall out of date 76 | * These often fail badly at decent organization 77 | * Wikis get spammed by bots sometimes 78 | * Website 79 | * You know what a website is 80 | * This should be the "core" of your documentation 81 | * Readily accessible 82 | * Thoughtfully organized 83 | * Separate sections for various concerns 84 | * Its job: 85 | * What IS this project? 86 | * This is your brochure 87 | * Home page must be GREAT 88 | * What problem does the project solve? 89 | * Why should I even care? 90 | * How do I USE the project? 91 | * Someone is interested, get them hooked... 92 | * Provide a quick introduction 93 | * HOWTO 94 | * Overview of getting started 95 | * If it is complex, break it down a bit (diagrams help) 96 | * Provide deeper documentation 97 | * Command line options 98 | * Configuration options 99 | * Environment stuff 100 | * API 101 | * History or About page 102 | * Contributing page 103 | * Developer documentation 104 | * You want to grow your dev community, so focus there, too 105 | * What immediately important things are there for a potential developer to know 106 | * How to get set up to modify the project 107 | * Is an IDE needed? 108 | * Are there certain tips and tricks? 109 | * Common questions asked by folks hacking on the project 110 | -------------------------------------------------------------------------------- /LectureNotes/Foundations.md: -------------------------------------------------------------------------------- 1 | 2 | # Foundations in Open Source 3 | 4 | * Project growth eventually finds a need for the project to become its own entity 5 | * Accepting donations on behalf of the project 6 | * Purchasing things on behalf of the project 7 | * Web hosting 8 | * Servers 9 | * so on 10 | * Enforce trademarks 11 | * Disconnect from the founding company/person 12 | * Shows the project is stand alone 13 | * Helps avoid concerns about a single interest commandeering the project 14 | * Enter: foundations! 15 | * See definition of foundation (non-for-profit) 16 | * A legal "entity" 17 | * It is it's own person in legal terms 18 | * Similar to a corporation in this respect 19 | * Gains the benefits of being its own entity 20 | * Can have bank accounts 21 | * Can own trademarks/copyrights 22 | * As a legal entity, has legal requirements 23 | * Helps separate concerns about money coming in/out 24 | * Accounting and auditing laws, etc 25 | * Some foundations (non-for-profits) have specific requirements (more on that later) 26 | * Important things about such a structure... 27 | * This requires a lot of management 28 | * A foundation generally has a board 29 | * Auditing and tax requirements 30 | * Legal/trademark knowledge 31 | * Pull the concerns apart 32 | * Let the developers develop 33 | * The foundation needs folks to manage it separately 34 | * Generally advised for projects to join an already established foundation 35 | * The foundation has figured out the rules 36 | * The foundation has gotten into their groove 37 | * Trying to do this on your own is *really* hard 38 | * **Most OSS foundations exist to absorb the work that developers don't want to do** 39 | 40 | ## Most popular US non-for-profit types 41 | * Different types have different requirements 42 | * Common 501(c) things 43 | * non-for-profit organizations 44 | * Can receive unlimited contributions from individuals, corporations and unions 45 | * Exempt from some or all federal income taxes 46 | * 501(c)3 - Religious, Educational, Charitable, Scientific, Literary, Testing for Public Safety, to Foster National or International Amateur Sports Competition, or Prevention of Cruelty to Children or Animals Organizations 47 | * Types 48 | * Public charities 49 | * Receive most income from general public or gov't 50 | * At least 1/3 must come from a broad base of public support 51 | * Private foundations 52 | * Non-operating foundations 53 | * Typically exist to support other charities through grants 54 | * Private operating foundations (a hybrid of the first two) 55 | * Highly regulated 56 | * No activities nor the net earnings can unfairly benefit any director, officer, or any private individual 57 | * Must avoid political involvings 58 | * Software foundations such as this are "for the public good" 59 | * Can operate outside the US 60 | * Donations are tax deductible 61 | * Highly regulated 62 | * 501(c)(6) – Business Leagues, Chambers of Commerce, Real Estate Boards, etc. 63 | * Not organized for profit and no net earnings go to any private entity 64 | * Exempt because they promote business interest *that improve business conditions rather than actually conduct the business* 65 | * Would not qualify if activities secure benefits for particular members (must be all) 66 | * Not applicable to hobbies 67 | * **Are** allowed to participate in political activities (lobbying) 68 | * Can attempt to influence legistlation related to the business interests of the membership 69 | * Membership dues... 70 | * Tax deductible generally as a business expense 71 | * Not all tax deductible if the main purpose of the nonforprofit is political influence 72 | 73 | ## Popular OSS foundations 74 | * Apache Software Foundation 75 | * 501(c)3 76 | * All volunteer - even the board 77 | * Currently the largest foundation 78 | * Software Freedom Conservancy 79 | * 501(c)3 80 | * All volunteer - even the board 81 | * Will fight license violations 82 | * Linux Foundation 83 | * 501(c)6 84 | * Corporate member driven, plus committers and fellows 85 | * Trade association 86 | * Eclipse Foundation 87 | * 501(c)6 88 | * Corporate member driven, plus committers and fellows 89 | * Trade association 90 | 91 | 92 | ## Vocabulary 93 | * *Foundation* - a legal category of nonprofit organization that will typically either donate funds and support to other organizations, or provide the source of funding for its own charitable purposes. 94 | -------------------------------------------------------------------------------- /LectureNotes/GettingInvolved.md: -------------------------------------------------------------------------------- 1 | # Getting Involved 2 | 3 | * Communities want to grow 4 | * Refer to [previous lecture](Communities.md) about community importance 5 | * Generally, as projects grow, they move away from BDFL/Lone Wolf models 6 | * More "stable" over time if more get involved 7 | * With more heads come more ideas 8 | * There is a general path for getting involved 9 | * Not 100% of people take this route 10 | * Some folks take the route only up to a certain point 11 | * See definitions below 12 | * A path for getting involved 13 | * Obtain [more merit](CommunityModels.md) 14 | * Some do this over the course of many years 15 | * Casual participation 16 | * Busy with lots of projects 17 | * Come and go as time allows 18 | * Some do this very quickly 19 | * Work on the project during their day job 20 | * Can focus more resources, etc 21 | * **Important point**: All contributions matter and earn merit 22 | * User 23 | * As a user of the software, you have some of the best information 24 | * What bugs are out there? 25 | * Lots of bugs are caught during development 26 | * Some bugs ship so devs want to hear about it 27 | * How are you using the software? 28 | * What are unique things in your environment devs need to know about? 29 | * What integration points are important to you? 30 | * Does the software do what you think it should? 31 | * Is the documentation good? 32 | * Things a user does to earn merit 33 | * Tests the builds and provides feedback 34 | * Opens bug reports 35 | * Identifies gaps in the documentation 36 | * Hangs out in the various communications channels and helps answers questions 37 | * These all provide value to the community 38 | * This improves the standing of the user in the community 39 | * The community begins to value their contributions 40 | * Trust in the individual grows and they gain "weight" 41 | * Contributor 42 | * You've used the software but now want to scratch an itch 43 | * Contributors do what the name implies - they contribute something of technical value to the project 44 | * That is **not** to say the things an active user contributes isn't valuable 45 | * It's a gray area, but we'll draw the line at the exchange of bits 46 | * In addition to what a user may do, contributors... 47 | * Provide code changes as patches or pull requests 48 | * Add a new feature the contributor wants to see in the product 49 | * Fixes a bug they have found 50 | * Resolves bugs in the tracker by providing code 51 | * Adds to or fixes documentation 52 | * In short, a contributor does work on technical aspects of the project 53 | * The work they do is shared with the project 54 | * Someone with commit access will need to accept the contribution 55 | * Work is usually implicitly covered under a Contributor License Agreement 56 | * The contributor's input is highly valued by the community 57 | * Code changes are almost always welcomed 58 | * This shows the community the contributor is serious... 59 | * ... enough about the project to give their own time 60 | * ... enough about the project to invest in the project 61 | * The end sum is that the contributor gains merit and thanks for the work they do 62 | * Committer 63 | * You have provided so much value to the community that you have earned the commit bit 64 | * Formal recognition of contributions 65 | * Trusted to have write access to the repository 66 | * Being a committer on a project means that you are "officially" a developer on the project 67 | * Yeah, that can go on your resume 68 | * In addition to what a contributor may do, committers... 69 | * Accept patches and pull requests to merge them into the code base 70 | * Are given additional access and responsibilities 71 | * Can update the web page 72 | * Can sometimes speak on behalf of the project 73 | * May be able to create categories in the tracker or communications tools 74 | * Perform the tasks around releasing the project 75 | * May be able to digitally sign a release 76 | * These are the folks that are the "guts" of running the project 77 | * Voter 78 | * Quick note 79 | * Not all projects distinguish between committer and voter 80 | * Some consider a committer the top level 81 | * Some consider a committer to have enough merit to write to the code base, but not vote on certain things 82 | * Example: 83 | * In the ASF, a committer can add code, but cannot vote on a release 84 | * To vote on a release, you must be on the project management committee 85 | * You have homework to read about voting in OSS projects (too much to cover here) 86 | * These individuals have binding say in what the project does for the most critical of things 87 | * In addition to what a committer may do, a voter... 88 | * Release a version of the project (special because a release cannot be undone) 89 | * Setting the direction for the project 90 | * Making significant changes 91 | * A voter participates in the democratic process in the project when conflicts arise 92 | * Other roles 93 | * Not all projects are run the same (see committer vs voter above) 94 | * Sometimes there are additional levels or roles involved 95 | * There is no official way that must be done 96 | * Foundation participation creates its own set of levels and responsibilities 97 | * Legal or marketing 98 | * Conference or event planning 99 | * Board or membership 100 | * Major takeaways 101 | * This is all about building **merit** and **credibility** in the community 102 | * As you do more, you are trusted more 103 | * Think of it as: By acting responsible, you are given more responsibilities 104 | * With a meritocracy, those who DO are given the most "weight" 105 | * Trust comes because one has shown their investment 106 | 107 | 108 | ## Vocabulary 109 | * *User* - An individual who installs and actively engages with the software being produced 110 | * *Contributor* - An individual who provides input of any sort to the software being produced. 111 | * *Committer* - An individual who has write access to the code repository 112 | * *Voter* - An individual who has gained the ability to influence the direction of the project via binding votes 113 | -------------------------------------------------------------------------------- /LectureNotes/IntroAndHistory.md: -------------------------------------------------------------------------------- 1 | ## Overview 2 | * Open Source software is found everywhere 3 | * It is world changing technology 4 | * Backbone of Internet servers 5 | * Found in nearly every consumer device 6 | * Open source software is software still 7 | * Failure reasons are similar to proprietary software 8 | * Vague requirements 9 | * Shifting scope 10 | * Ignoring user feedback 11 | * DO NOT do this!!! 12 | * Fails also for other reasons 13 | * Onboarding new devs 14 | * ... have lots of questions 15 | * ... doesn't provide immediate value 16 | * ... have to train devs on your culture 17 | * Presentation and packaging 18 | * Dev doco must be awesome 19 | * Your web page cannot suck 20 | * Easy to get, build and run 21 | * Marketing woes 22 | * Coders may not be good UI folks 23 | * Webmasters and presentation needs 24 | * Management issues 25 | * Same tactics don't always work in open source as they do internally 26 | * An already independent group (developers) needs cohesion with strong project management 27 | * Should be behind the scenes 28 | * Cultural 29 | * Geographic and simple cultural differences 30 | * Code of Conduct for proj is ESSENTIAL 31 | * Emphasize again 32 | * It is a lot of work to open up 33 | * It is hard to open closed software 34 | * Benefits take time to show up 35 | * These costs are up front 36 | * Benefits are plentiful 37 | * "Free labor" 38 | * Peer recognition 39 | * Resume booster 40 | * Exposure to outside ideas (this is huge) 41 | 42 | 43 | ## History 44 | * Originally, hardware was the differentiator for tech businesses 45 | * Software was extended by users 46 | * Changes shared with mfg and other users 47 | * Major differences from today: 48 | *Architecture was not generic 49 | * What you learn and do on platform A was not portable to platform B 50 | * Your skills were tied to the platform 51 | * Sharing software meant more lock-in 52 | * No Internet! 53 | * Hard to distribute data 54 | * Software wasn't a selling point 55 | * Big industry shifts 56 | * A few architectures won out 57 | * "High level languages" 58 | * Write once, compile the same code for different architectures 59 | * If written for machine A, it could now work on machine B 60 | * HW performance levelled out (less of a differentiator) 61 | * Margins dropped 62 | * Required mfgs to find new sources of revenue 63 | * Results: 64 | * SW became a value add for the platform 65 | * Sharing SW cuts the value 66 | * Competitors could also get the SW, too 67 | * Tgis must be stopped! 68 | * Access to code was restricted 69 | * Legal agreements (NDA) if code was available 70 | * Sometimes also required for binaries 71 | 72 | 73 | ## The rise of the movement 74 | * Several separate people/groups had a similar idea 75 | * But with different motivations 76 | * Richard Stallman 77 | * AI lab at MIT 78 | * Culture of SW sharing at MIT 79 | * Common to academia 80 | * Similar to sharing research 81 | * Co-workers hired away by a proprietary SW company 82 | * New HW w/proprietary OS went to the lab 83 | * Resigned and started FSF 84 | * GPL license 85 | * Code can be copied and modified 86 | * Derivatives must be GPL 87 | * (Viral) 88 | * Must always be free 89 | * Uses legal protections opposite of traditional use 90 | * Instead of enforcing restrictions, it enforces freedoms 91 | * GNU project started 92 | * Free OS 93 | * Free utilities 94 | * Utilities were so good they started being used on non-free OSs 95 | * 1990 most of OS done, but kernel still far away 96 | * Linus Torvalds and collaborators... 97 | * Linux - the missing kernel 98 | * FSF Rhetoric 99 | * Tied politics to code 100 | * Made it a cause, not convenience 101 | * Idealism motivation 102 | * GNU Not the only free OS project 103 | * BSD 104 | * UCB 105 | * Already underway in 1990 106 | * Reimplemented UNIX (versus being a new system altogether) 107 | * Non idealism motivation 108 | * X Windows 109 | * MIT - partnered with vendors 110 | * 1980s 111 | * Unique license 112 | * Free core 113 | * Proprietary stuff can be add on 114 | * Level playing field 115 | * Not idealogic 116 | * More for standards 117 | * Business motivation 118 | * TeX 119 | * Donald Knuth 120 | * Code can be modified, but can't be called Tex unless it passed a compatibility test 121 | * Trademark protection motivation 122 | 123 | ## Reasons to work with free code 124 | * Ideology 125 | * Technical excitement 126 | * Collaboration with others 127 | * The code is generally good 128 | * Comparable to proprietary 129 | * Sometimes better 130 | * Cheaper, at least 131 | -------------------------------------------------------------------------------- /LectureNotes/Issues.md: -------------------------------------------------------------------------------- 1 | # Issue/Bug Tracking 2 | 3 | * Not just "bugs" 4 | * All kinds of stuff gets tracked in a tool like this 5 | * Bugs 6 | * Feature requests 7 | * Major project milestones 8 | * Unsolicited code contributions 9 | * Documentation requests 10 | * Each item is referred to as _something_ 11 | * Bug 12 | * Issue 13 | * Ticket 14 | * "JIRA" 15 | * We will use "issue" 16 | * A tracker provides... 17 | * A way to normalize reports from users 18 | * What version of the code? 19 | * How severe is the problem? 20 | * Is it reproducible? 21 | * A way to formalize an issue's lifecycle 22 | * Alerting to tell... 23 | * devs that a user opened an issue 24 | * the reporter that information has been added 25 | * watchers that something has changed on the issue 26 | * Reporting 27 | * What issues are waiting? 28 | * What issues are new? 29 | * What issues do I own? 30 | * ...etc 31 | * Filtering or moderating 32 | * Lifecycle stages of an issue 33 | * Open 34 | * Info has just been added 35 | * The data has not been verified 36 | * The issue may not even be a good issue 37 | * Open/Working 38 | * Comments are made on the issue 39 | * Additional information is added or requested 40 | * Some discussion occurs here 41 | * *Warning*: be ready to refer to the development list for better conversation 42 | * Waiting 43 | * Details have been requested 44 | * No one can continue working the issue until the info is provided 45 | * Sometimes only the person reporting a bug has the environment to reproduce the problem 46 | * Assigned 47 | * Someone claims ownership of the issue 48 | * Generally this means the person can _reproduce_ the issue 49 | * Diagnosis and analysis is under way 50 | * Resolved 51 | * Sometimes called "patch ready" 52 | * Code is available 53 | * Hopefully the reporter can use it to test 54 | * Others examine the code 55 | * Further discussion may happen on list 56 | * Scheduled 57 | * Some future release is targeted to resolve it 58 | * Code should be in the repo when this target hits 59 | * Closed 60 | * Can be closed for many reasons 61 | * The code fixes/does what was reported and has been added to repo 62 | * The issue was invalid 63 | * Sat in waiting too long 64 | * Not a bug, but misuse of the software 65 | * This change will never be made by design 66 | * The issue was a duplicate 67 | * No one can reproduce the problem 68 | * Note about states 69 | * Not all trackers use all of these states 70 | * Some trackers use other states 71 | * As usual, the project uses the tool how it best suits the needs of the project -------------------------------------------------------------------------------- /LectureNotes/Licenses.md: -------------------------------------------------------------------------------- 1 | # Licenses 2 | 3 | * First, some important terms (know them) 4 | * Free software 5 | * "Software that can be freely shared and modified, including in source code form" 6 | * Coined by FSF 7 | * "Free" ambiguity 8 | * Acceptable ambiguity to emphasize FREEDOM 9 | * Open Source 10 | * Coined by OSI 11 | * "goal at the time was largely to make such software a more palatable choice for corporations, by presenting it as a development methodology rather than as a political movement." 12 | * AKA: ...people in ties 13 | * Other terms: 14 | * OSS - Open Source Software 15 | * FOSS - Free/Open Source Software 16 | * FLOSS - Free/Libre Open Source Software 17 | * DFSG-Compliant 18 | * A note about Debian 19 | * Large amount of work went into definition of criteria 20 | * You KNOW that it is "free" if compliant 21 | * OSI-approved 22 | * Similar concept above 23 | * List maintained by OSI 24 | * FSF list 25 | * "Free" or not 26 | * Also GPL compatible or not 27 | * Proprietary or closed source 28 | * Important distinction 29 | * IS NOT whether the source can be seen 30 | * IS a matter of what you can do with the source 31 | * Proprietary code... 32 | * May be licensed without source being available 33 | * May have source available, but NO rights to modify or redistribute 34 | * Copyleft 35 | * Open Source that is licensed such that derivatives must also be Open 36 | * Also called 'viral' 37 | * Permissive 38 | * Open Source license that does NOT restrict derivatives 39 | * Still "free" 40 | * Aspects of licenses 41 | * Nearly all say... 42 | * Anyone can modify the code 43 | * Anyone can redistribute it both in original and modified form 44 | * The copyright holders and authors provide no warranties whatsoever 45 | * Differences 46 | * Compatibility with proprietary licenses 47 | * Permissive allows incorporating into proprietary works 48 | * Compatibility with other Free licenses 49 | * Enforcement of attribution 50 | * Trademark protection 51 | * Patent protection 52 | * Copyrighter includes patent license rights with contribution 53 | * Litigation initiation also causes LOSS of the patent rights 54 | * The special rights of the copyright holder 55 | * Copyright doesn't vanish when code is open 56 | * Copyright still grants "ownership" of your code 57 | * Giving or sharing the code DOES NOT grant copyright to the recipient 58 | * Unless your CLA grants copyright to the receiving project as part of your contribution 59 | * Copyright grants decision rights for distribution 60 | * Therefore the copyrighter... 61 | * CAN give the code away AND charge for it 62 | * CAN distribute under many terms 63 | * Copyleft license for the general public 64 | * ...but sell exceptions to paying clients 65 | * CAN have a free but paid component (freemium) 66 | * Copyright applies to OTHERS, not the copyrighter 67 | * Quick tour of the popular ones 68 | * MIT 69 | * Massachusetts Institute of Technology 70 | * Permissive license 71 | * Has several derivatives 72 | * Derivatives must... 73 | * Include a copy of the license 74 | * Provide attribution 75 | * GPL 76 | * Created by FSF 77 | * Copyleft license 78 | * Has variations 79 | * AGPL - copyleft applies even to network usage of the code 80 | * LGPL - copyleft stops at binary linking and including in larger works 81 | * Derivatives must... 82 | * Be licensed under GPL 83 | * Provide attribution 84 | * Provide code 85 | * Apache 2 86 | * Created by ASF 87 | * Permissive license 88 | * Similar to MIT, but expressly grants patent rights 89 | * Derivatives must... 90 | * Include attribution 91 | * BSD 92 | * Created by University of California Berkeley 93 | * Has some variants and is a "collection" of licenses 94 | * 2 clause - (most common) Pretty much the same as MIT, but doesn't explicitly allow as much (though it is implicitly allowed) 95 | * 3 clause - No endorsement by copyright holder 96 | * 4 clause - Advertisements must acknowledge copyright holder 97 | * Derivatives must... 98 | * Include a copy of the license 99 | * Provide attribution 100 | 101 | Resources: 102 | https://en.m.wikipedia.org/wiki/Comparison_of_free_and_open-source_software_licenses 103 | -------------------------------------------------------------------------------- /LectureNotes/Releasing.md: -------------------------------------------------------------------------------- 1 | 2 | ## Releases 3 | * Note #1... just be consistent with naming your releases 4 | * Snapshot of code at a specific time 5 | * Tags help here 6 | * "Set" of features/ fixes 7 | * A specific version of the software 8 | * Old bugs have been fixed 9 | * New bugs added 10 | * New features added 11 | * New options added 12 | * Incompatible changes 13 | * Is a file name followed by version number 14 | * usually a dash 15 | * Capitalize or don't... doesn't matter, just be consistent 16 | * Example: 17 | * foo-1.5.8 18 | * Foo-1.5.8RC1 19 | 20 | ## Version numbering 21 | * Represent a contract with your users 22 | * Must be consistent between releases 23 | * Easily identifies.. 24 | * Ordering of releases 25 | * Compatibility information/nature of changes 26 | * Always increases 27 | * Are groups of digits 28 | * Not decimal points 29 | * Sometimes add a qualifier 30 | * Alpha 31 | * Beta 32 | * Release Candidate 33 | * (Qualifiers follow the version number they will represent) 34 | * 1.4.0 alpha will become 1.4.0 eventually 35 | * Rules vary by project... But MUST BE CONSISTENT within that project 36 | * Major.Minor.Micro common "rules" 37 | * Major version is a compatibility boundary 38 | * Minor version is backwards compatible 39 | * Micro is forward and backward compatible 40 | * Version compatibility 41 | * Backward compatibility 42 | * Allows new versions to talk/use older clients/servers/data 43 | * When paired with equally new clients/servers/data, may enable new features 44 | * "Works the way it always has" 45 | * Forward compatibility 46 | * Changing between micro up or down should not add or remove functionality 47 | * Downgrading from 4.1.6 to 4.1.5 should only restore bugs, not lose features 48 | * Compatibility domain 49 | * Defines what a Maj.Min.Mic will not break 50 | * Depends on what your project does 51 | * Examples: 52 | * Data formats read or written 53 | * Messages exchanged over network 54 | * Application Programming Interface (How other SW calls your code) 55 | * Function names 56 | * Parameters for functions 57 | * Function return data 58 | * Application Binary Interface (ABI - how compiled code binds to your library) 59 | * Expectations of memory locations of members within structures 60 | * Forces new stuff to end of structures 61 | * Prereleases (alpha/beta) usually get a pass on this 62 | * Adding to Maj.Min.Mic 63 | * Sometimes adds a patch number after micro 64 | * Sometimes odd Maj or Min means "in development" and compatibility rules are off 65 | 66 | ## Releasing 67 | * Open Source usually releases source code 68 | * Sometimes binaries 69 | * Sometimes binaries in addition to source 70 | * Code set contained as an archive 71 | * Non-windows: 72 | * Source: compressed tar archive 73 | * gzip or bz2 compression 74 | * Binary: 75 | * Native package 76 | * DSO 77 | * "Installer" 78 | * Windows 79 | * Source: zip 80 | * Binary: 81 | * Installer 82 | * DSO/DLL 83 | * zip 84 | * Expected to extract into a directory of the same name as the archive 85 | 86 | ### Steps 87 | * These are general guidelines and exact procedures vary by project 88 | * Identify release process 89 | * Release manager 90 | * Person responsible for identifying and incorporating changes into release 91 | * Should "own" the release 92 | * Ensure compatibility domains are followed 93 | * Has final say 94 | * Voting 95 | * Similar as above, but responsibility is shared 96 | * Changes receive votes 97 | * Typically three +1 votes needed 98 | * Sometimes voting rights restricted to certain people 99 | * Usually a -1 is a veto for that change 100 | * Incorporate changes into release branch 101 | * Perform votes or identify changes 102 | * Apply patches or pull requests 103 | * Tag branch for release 104 | * Package up the release 105 | * Create change info (CHANGES file) 106 | * Noteworthy changes in this release 107 | * Significant bugs fixed 108 | * Features added 109 | * Any visible change in behavior 110 | * Compatibility changes 111 | * Create archive 112 | * Distribute archive to project for final testing... 113 | * On different OS platforms 114 | * On different architectures 115 | * With different config options 116 | * Via the test suite 117 | * Finalize the release 118 | * Hold vote to proceed with release 119 | * Sign packages with digital signature (s) 120 | * Add new version to issue tracker 121 | * Publish packages to mirrors/distribution points 122 | * Ensure mirrors are synchronized before proceeding 123 | * Publish digital signature file(s) 124 | * Announce 125 | * On lists 126 | * On web page 127 | * On forums 128 | -------------------------------------------------------------------------------- /LectureNotes/SDLCMethodologoies.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/DRuggeri/OSSClass/ac9dfe7ee3dbed9d07e11b8d950f1ba59ea2b03c/LectureNotes/SDLCMethodologoies.md -------------------------------------------------------------------------------- /LectureNotes/SourceControlAdditional.md: -------------------------------------------------------------------------------- 1 | # Additional version control topics 2 | 3 | ## Beware the word "fork" 4 | * Can be an overloaded term 5 | * In git speak, it means copying the repository to a separate location 6 | * Usually a good thing 7 | * ... since it's the start of a potential contribution 8 | * ... or nothing at all 9 |  * Either way "Give me a repository just like this one" 10 | * In community speak, it is a much more serious problem 11 | * The community has come to a disagreement 12 | * Usually a major disagreement 13 |    * Fundamental problem 14 | * There is no way forward 15 | * Neither side will cave 16 | * The community itself is forked 17 | * Only solution is to split into two projects 18 | * Now directly competing with each other 19 | * ... for users 20 | * ... for developers 21 | * ... against proprietary software, too 22 | * The code base now lives in two places 23 | * Actively maintained by separate devs 24 | * Potentially very different project cultures 25 | * Sometimes projects continue separately 26 | * Sometimes one or the other folds 27 | * Sometimes both collapse completely 28 | * Likely outcome for smaller projects 29 | 30 | ## Branches 31 | * A total copy of a set of version controlled files/directories 32 | * At the time the branch happens, both are exactly the same 33 | * Contents 34 | * History 35 | * Reason to branch: Release branch 36 | * Users need a stable release version - the code must be stabilized 37 | * ... but developers want to work on stuff 38 | * New features 39 | * Unrelated stuff for the release 40 | * Solution 1 - freeze work 41 | * No new features or changes beyond what is intended for the release 42 | * Everyone focused on getting the release out 43 | * Common in commercial development 44 | * Fastest turnaround time to get the release out the door 45 | * Dangerous for OSS projects 46 | * Stops devs from working on what they want to work on (unless it's the release) 47 | * That much control is not guaranteed to a project leader anyway 48 | * Solution 2 - branch development from stable 49 | * Requires a bit more care and work for getting changes from development to a stable branch 50 | * Allows developers to work on trunk 51 | * New features 52 | * Incompatible changes 53 | * The stable branch is less "loose" 54 | * Isolates active work from things ready for release 55 | * Requires a more deliberate act to get code into this branch 56 | * Most projects have a process for this 57 | * Reason to branch: features 58 | * Sometimes a feature requires a lot of changes 59 | * ... and collaborators 60 | * Once you've used SCM right, it's hard to go back to non-collaborative development 61 | * A branch can be created from an existing branch (stable or trunk) to work on just that feature 62 | * Allows people to commit and change the branch 63 | * Allows for experimentation 64 | * As work is done, it is isolated from the original branch 65 | * When work is done, the branch can be... 66 | * merged into the branch it came from 67 | * deleted since it was just an experiment 68 | 69 | ## Tags 70 | * An exact snapshot of every file/directory in the repo at a specific time 71 | * Somewhat similar to a branch (point in time copy) except it cannot be modified 72 | * Useful for releases 73 | * Identifies the exact contents that went into the release 74 | * Years later, can still obtain the files as they were when the release was done 75 | * Also useful any time a snapshot is desirable 76 | * Before a rearchitecture 77 | * Interesting point in the project's history 78 | -------------------------------------------------------------------------------- /LectureNotes/SourceControlOverview.md: -------------------------------------------------------------------------------- 1 | # Source Code Management 2 | 3 | * What is it? 4 | * Exactly as it says - manages all the important files 5 | * Code 6 | * Documentation 7 | * Web pages 8 | * Gives one place to get all the good stuff 9 | * Can share the location of the repo 10 | * Know where the latest and greatest version can be found 11 | * "Management" of code? 12 | * Tracks metadata 13 | * Creates a "time machine" 14 | * Any change, ever, can be put back or obtained 15 | * Allows for experimentation in "sandbox" areas 16 | * Creates an audit log 17 | * Who changed what, when and why 18 | * Helps with attribution 19 | * Ensures only those allowed can change the code 20 | * Can help join changes from multiple people on the same file 21 | * Facilitates code review 22 | * Release management 23 | * A topic for another day 24 | * Dangers of what you've only been told about so far 25 | * What if you lose your local data from accidental deletion or giant lizard attack? 26 | * It is hard to share the code 27 | * Sending files around... Who has the latest version? 28 | * Do I have everyone's changes? 29 | * Who even made this change? 30 | * How can we both work on the files at the same time? 31 | * Multiple people working on one file set can step on toes 32 | 33 | 34 | ## Important version control concepts 35 | * The master server is the canonical place for the code 36 | * With git, every local copy and fork is a complete copy of the original repository 37 | * Including all previous commits since ever 38 | * And is now its own repository 39 | * You can commit/modify locally and offline 40 | * This allows for recovery of the repository if the central repository dies 41 | * Version Control all the things 42 | * Except dynamically created (generated) content 43 | * Most version control systems have a browseable UI 44 | * Helpful for quickly navigating the code or linking directly to files 45 | * Easy way to view history 46 | * Also have "sticky" links for commits and diffs 47 | * Can also "watch" a repository 48 | * Notify when changes happen 49 | * Typically provide an email containing the diff 50 | * Most projects do this with their dev or vcs mailing list 51 | * Useful log messages 52 | * Make an overview of what and why you changed things 53 | * Do not just say what you did 54 | * Sucks: Modify input.c to rename counter variable 55 | * Does not suck: Rename variable 'ctr' to 'i' in input.c to avoid confusion with 'cntr' variable 56 | * Use a consistent nomenclature for revisions 57 | * Example: r9926 58 | * Allows semi-smart scraping to auto generate links 59 | * The commit bit 60 | * Should ONLY be given to trusted people 61 | * These are the committers 62 | * Is earned over time by people that... 63 | * Demonstrate proficiency 64 | * Have been involved as a user/contributor 65 | * Know the project culture 66 |   * Engenders your project's values 67 | * Typically extended via the following process (which should be documented publicly): 68 | * An existing committer nominates the person on a private list 69 | * A discussion is held 70 | * The matter is put to a vote by the other committers 71 | * If successful, the person is offered commit access 72 | * Often grants the ability to vote in some way, too 73 | * Do not overdo authz 74 | * Keep a "permissions flat" repo 75 | * Ensure everyone understands the areas they should and should not change 76 | * Example: With docs and code in the same repo, a person given commit access who works on docs should know not to commit to the code 77 | 78 | ## Typical workflow - git 79 | Fork the repository in the web UI 80 | 81 | Obtain a local copy of the forked repository 82 | ``` 83 | git clone https://github.com/DRuggeri/OSSClass/OSSClass.git 84 | ``` 85 | 86 | Make the modifications you would like to make 87 | ``` 88 | vi syllabus.md 89 | ``` 90 | 91 | Add the modified files to the change set 92 | ``` 93 | git add syllabus.md 94 | ``` 95 | 96 | Commit the changes to the local repository 97 | ``` 98 | git commit -m "Update syllabus to push back assignment due date" 99 | ``` 100 | 101 | Send the local changes to the remote fork 102 | ``` 103 | git push 104 | ``` 105 | 106 | Open a pull request in the UI from your repository to the original repository 107 | 108 | ## Typical workflow - svn 109 | Check out the code from the master server (note the below does not work on github because git!=svn 110 | ``` 111 | svn co https://github.com/DRuggeri/OSSClass/OSSClass.git 112 | ``` 113 | 114 | Make the modifications you would like to make 115 | ``` 116 | vi syllabus.md 117 | ``` 118 | 119 | Add the modified files to the change set 120 | ``` 121 | svn add syllabus.md 122 | ``` 123 | 124 | Commit the changes to the master repository 125 | ``` 126 | svn commit -m "Update syllabus to push back assignment due date" 127 | ``` 128 | 129 | 130 | ## Vocabulary 131 | * **Repository** - a hierarchical structure of files containing the objects under version control in addition to metadata about the history of the repository 132 | * **Fork** - a copy of a repository managed separately from the project's formal repository. This may be an individual's personal working repository before submitting changes or a whole new community spinning off from the project. 133 | * **Commit** - to make a change to a repository. With svn a commit is also a push. 134 | * **Push** - (git) to send the local repository's changes to a remote repository 135 | * **Log message** - an overview of why the change was made in a commit 136 | * **Update/Pull** - to synchronize changes from a remote server to the working set/local repository 137 | * **Checkout** - obtaining a copy of the repository at a specific version number (usually the latest commit) 138 | * **Clone** - (git) obtaining a copy of the repository at the latest commit 139 | * **Working copy** - the isolated, local set of files from the repository 140 | * **Revision** - a specific version of a file or directory 141 | * **Changeset** - a series of changes to one or more files or directories grouped together for a commit 142 | * **Diff/patch** - a textual representation of the differences between two or more files/directories 143 | * **Tag** - a label for a collection of files at a specific revision 144 | * **Branch** - an isolated copy of the code inside the formal repository. Functions almost like a fork, but is still part of the repository 145 | * **Trunk** - typical name for the development branch from which all branches came 146 | * **Merge** - moving/propagating a change from one branch to another. Also: the automatic combination by the version control system of two different changes to the same file 147 | * **Pull request** - (git) a request to incorporate (pull) the changes from one branch or repository to another. Often is a merge of commits from a fork or branch into mainline 148 | * **Conflict** - a situation in which two changes are made to the same file by different developers that cannot be automatically merged by the version control system. Typically the second push/commit must be modified to eliminate the conflict 149 | * **Lock** - to enforce the ability for only one developer to be able to write to specific files/directories in the repository 150 | * **Stash** - to temporarily store modifications in a working set such that the working set can be restored to the previous revision and restored to the stashed version later 151 | * **Log** - the list of revision identifiers with the time/date/author and log message of each revision 152 | * **Revert** - to restore a repository to a previous revision. Note that this is another commit and does not erase the previous commit(s) 153 | -------------------------------------------------------------------------------- /LectureNotes/WhatIsOSS-ForStudents.md: -------------------------------------------------------------------------------- 1 | 2 | # Introduction to Open Source Software 3 | ### _For students_ 4 | 5 | ??? 6 | Something 7 | Some slide notes 8 | 9 | ---- 10 | ## Who is this guy? 11 | 12 |   13 | 14 | Daniel Ruggeri 15 | - Infrastructure guy that loves code and OSS 16 | - Participates in many OSS communities 17 | - Mentor, teacher, handyman... geek 18 | 19 |   20 | 21 | See LinkedIn if you care for more... 22 | - DRuggeri@primary.net 23 | 24 | ---- 25 | ## So many things, so little time 26 | 27 | In this presentation 28 | - What is Open Source Software (OSS)? 29 | - Why does Open Source exist? 30 | - History leading up to OSS 31 | - Initial OSS Communities 32 | - Tools 33 | - Terminology 34 | - Licenses 35 | 36 |   37 | 38 | ##### _... what is most interesting to you?_ 39 | 40 | --- 41 | # What Is It? 42 | ##### _A program whose source code is publicly available and licensed for use and/or modification_ 43 | 44 | ---- 45 | It's software, of course... and it's _everywhere_! 46 | - The Internet 47 | - Government 48 | - Research 49 | - Big data 50 | - Your pocket 51 | 52 | ---- 53 | ## Side notes 54 | - There is contention with "free" 55 | - `Free != Libre != Open` 56 | 57 | - Universally agreed: Having the code allows... 58 | - Inspection of how it works 59 | - Fixing bugs 60 | - Making derivatives 61 | - Enhancing the software 62 | 63 | --- 64 | # Benefits 65 | ##### _Why would anyone GIVE AWAY good software?_ 66 | 67 | ---- 68 | Open algorithms/code get more eyes 69 | - So are often more secure 70 | - This allows us to understand how the S/W works 71 | - "No one of us is as smart as all of us" 72 | 73 | ---- 74 | Depending on flavor, may have a backing foundation 75 | - Leveling the playing field 76 | - Removing concern of single-company control 77 | - Lets the community drive the software 78 | 79 | ---- 80 | Ideology around freedom 81 | - Is certain tech a basic human right? 82 | - Freedom as in _'murica_ 83 | 84 | ---- 85 | Giving back 86 | - Contributing to projects we get things from 87 | - Moving technology forward 88 | 89 | --- 90 | # Some History 91 | 92 | ##### 1970s - 1990s 93 | 94 | ---- 95 | ### In The Beginning... 96 | ##### _(Well, the 70's, actually)_ 97 | 98 | - Hardware was the seller 99 | - There were several architectures 100 | - Software was specific to the hardware 101 | - ... and was openly shared (to drive lock-in) 102 | 103 | ---- 104 | ### And then... 105 | 106 | - Hardware performance levelled off 107 | - A few architectures won out 108 | - Higher level languages came on the scene 109 | - _Software_ now became a differentiator 110 | 111 | ---- 112 | ### So someone said 113 | > "We should totally charge people for this stuff instead of giving it away" 114 | 115 | --- 116 | # Meanwhile... 117 | 118 | Separate threads happening simultaneously gave birth to different OSS communities 119 | 120 | ---- 121 | ## BSD 122 | 123 | - At UCB, UNIX OS was originally "Open" 124 | - Began adding some utilities 125 | - Rewrote kernel to add virtual memory support 126 | 127 | - The birth of _Berkely System Distribution_ in '78 128 | - Expanding and reimplementing UNIX 129 | - All proprietary code eventually replaced 130 | 131 | Create a better OS that isn't encumbered by software licenses. 132 | 133 | ---- 134 | ## TeX 135 | 136 | - A typesetting system by Donald Knuth 137 | - Developed as his book was produced 138 | - Interested in digital typesetting 139 | 140 | - Began work in '78 141 | - Interesting license 142 | - Free code, but protected name 143 | - Must pass a test to be called `TeX` 144 | 145 | Just be true to the name. 146 | 147 | ---- 148 | ## FSF 149 | 150 | - Richard Stallman in AI lab at MIT (culture of sharing) 151 | - Co-workers hired by a proprietary s/w company 152 | - New h/w with proprietary OS came to the lab 153 | 154 | - "This sucks", so around '83 155 | - Resigned and started _Free Software Foundation_ 156 | - Created (with others) _GNU Public License_ 157 | - Started the GNU project (free OS and utilities) 158 | 159 | Injected politics into the conversation. 160 | 161 | ---- 162 | ## X Windows 163 | 164 | - An MIT project 165 | - Hardware and vendor independant graphics 166 | - Lots of attention from vendors 167 | 168 | - Became a consortium 169 | - Formed in '88 from several vendors 170 | - Neat license: open core, but can be expanded 171 | 172 | Level playing field to let vendors compete on differentiators. 173 | 174 | ---- 175 | ## ASF 176 | 177 | - Free NCSA HTTPd 178 | - Several folks ran websites with it 179 | - It was abandoned in '94 180 | 181 | - "Oh no!" 182 | - Apache group formed in '93 183 | - Shared patches and enhancements 184 | - 8 developers created an ad-hoc community 185 | - Became _Apache Software Foundation_ in '99 186 | 187 | Value the community. Remove vendor dependence. 188 | 189 | --- 190 | # Tools of the Trade 191 | 192 | When multiple people that are geographically dispersed work on the same code, tools are _required_ to make it all work 193 | 194 | ---- 195 | ## Source Control 196 | 197 | A time machine for the code 198 | - The code isn't just on your machine 199 | - Changes are made locally and sent to the server 200 | - Mistakes can be reverted to a previous revision 201 | 202 | Popular tools: 203 | - Git 204 | - Apache SVN (subversion) 205 | - mercurial 206 | 207 | ---- 208 | ## Build Systems 209 | 210 | Automates the build 211 | - ... and sometimes the gathering of dependencies 212 | - A vital part of Continuous Integration 213 | - Distills the steps to build the s/w into a "script" 214 | 215 | Popular tools: 216 | - Gradle 217 | - Apache Maven 218 | - Apache Ant 219 | 220 | ---- 221 | ## Issue/Ticket Tracking 222 | 223 | Tracks issues or tickets (of course) 224 | - Allows users/project members to report bugs 225 | - Facilitates collaboration/info sharing around issue 226 | - Assign owners, share patches, etc 227 | 228 | Popular tools: 229 | - Bugzilla 230 | - JIRA 231 | - Trac 232 | 233 | ---- 234 | ## Other Collaboration Tools 235 | 236 | Various other tools exist for various purposes 237 | - Realtime chat for takling and ChatOps 238 | - Patch management for discussing code changes 239 | - Message forums for ongoing conversations 240 | - WIKI sites for easy documentation 241 | 242 | Popular tools: 243 | - Slack/HipChat/IRC 244 | - GitHub/GitLab/BitBucket 245 | - phpBB/FUDforum/Discourse 246 | - MediaWiki/Confluence/MoinMoin 247 | 248 | --- 249 | # Terminology 250 | 251 | Let's get on the same page about terms first 252 | 253 | ---- 254 | ## Free Software 255 | 256 | > "Software that can be freely shared and modified, including in source code form" 257 | 258 | - Coined by FSF 259 | - "Free" ambiguity acceptable to emphasize FREEDOM 260 | 261 | ---- 262 | ## Open Source 263 | 264 | > "... goal at the time was largely to make such software a more palatable choice for corporations, by presenting it as a development methodology rather than as a political movement." 265 | 266 | - Coined by OSI 267 | - Means the same thing, but different 268 | 269 | ---- 270 | ## Proprietary/Closed 271 | 272 | Software that places restrictions on it's use 273 | - Access to source code 274 | - Redistribution of the software 275 | 276 | Sometimes has uncommon restrictions 277 | - Field/industry of use 278 | 279 | ---- 280 | ## Copyleft 281 | 282 | Licensing that requires derivitives or use of the software to also be Free and/or use the same license 283 | 284 | - Often called "viral" 285 | - This scares people that wear ties 286 | 287 | ---- 288 | ## Permissive License 289 | 290 | A license that does not restrict derivitives 291 | 292 | - May be incorporated into proprietary works 293 | - May be used without contributing back 294 | 295 | --- 296 | # Licenses 297 | ##### _(The fun part!)_ 298 | 299 | ---- 300 | ## The license... 301 | Determines rights 302 | 303 | - How may I use it? 304 | - May I view the code? 305 | - May I modify the code? 306 | - May I distribute modifications? 307 | - Must my modifications also be open? 308 | 309 | ---- 310 | ## A Sea of Licenses! 311 | 312 | Nearly all say: 313 | - Anyone can modify the code 314 | - Anyone can redistribute in original/modified form 315 | - Copyright holders provide no warranty 316 | 317 | Differences: 318 | - Compatibility with proprietary/other free licences 319 | - Enforcement of attribution 320 | - Trademark protection 321 | - Patent protection 322 | 323 | ---- 324 | ## A few of the most popular licences... 325 | 326 | ---- 327 | ### MIT 328 | 329 | Permissive license 330 | - Developed at MIT (of course) 331 | - Has several derivitives 332 | - Software derivitives must... 333 | - Include a copy of the license 334 | - Provide attribution 335 | 336 | ---- 337 | ### GPL 338 | 339 | Copyleft license 340 | - Created by FSF 341 | - Has a few variants 342 | - AGPL - viral for nearly anything that touches it 343 | - LGPL - copyleft stops at binary linkage/including 344 | - Derivitives must... 345 | - Be GPL licenced 346 | - Provide attribution 347 | - Provide code 348 | 349 | ---- 350 | ### Apache 2 351 | 352 | Permissive "business-friendly" license 353 | - Created by ASF (of course) 354 | - Similar to MIT, but... 355 | - Grants patent license 356 | - Declares contributions to be covered 357 | - Derivities must... 358 | - Include a copy of the license 359 | - Provide attribution 360 | 361 | ---- 362 | ### BSD 363 | Permissive license 364 | - Created at UCB 365 | - Has a few variants 366 | - 2 clause - Pretty much the same as MIT 367 | - 3 clause - No endorsement by copyright holder 368 | - 4 clause - Advertisements must acknowledge copyright holder 369 | - Most common is 3 clause 370 | 371 | ---- 372 | ## Great source of license popularity 373 | 374 | ##### [https://www.blackducksoftware.com/top-open-source-licenses](https://www.blackducksoftware.com/top-open-source-licenses) 375 | 376 | 377 | --- 378 | ## End 379 | -------------------------------------------------------------------------------- /Presentations.md: -------------------------------------------------------------------------------- 1 | # First Presentation suggestions 2 | * 3 - 14 - *Hammad* - A few Open Source business models that rock 3 | * 3 - 14 - *Toan* - What is Internationalization and why do I care? 4 | * 3 - 14 - *Aaron* - What is an IDE and why are they great? 5 | * 3 - 16 - *Patrick* - How to get started contributing to an Open Source project 6 | * 3 - 16 - *Hassan* - The git workflow - how to SCM like a boss 7 | * 3 - 16 - *Meredith* - A quick overview to being a command line ninja 8 | * 3 - 21 - *Sam* - Watch me deploy my app to Tomcat! 9 | 10 | # Second Presentation Suggestions (4/25) 11 | * *Toan* - OpenStack 12 | * *Aaron* - Eclipse 13 | * *Sam* - Apache Tomcat 14 | * *Hammad* - Ubuntu 15 | * *Hassan* - GIMP 16 | * *Meredith* - Linux 17 | * *Patrick* - Netflix OSS 18 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # An *Open* Open Source class 2 | 3 | With luck (and passion), anyone can take this content and deliver a successful course outlining Open Source software development methodologies, tools and communities. 4 | 5 | Head on over and see the [syllabus](syllabus.md) doc for example implementations of this course for more information. 6 | -------------------------------------------------------------------------------- /UsefulLinks.md: -------------------------------------------------------------------------------- 1 | # Links worth keeping 2 | 3 | ## Git clients for Windows 4 | * Eclipse GUI, no installer - [GitEye](https://www.collab.net/downloads/giteye) 5 | * Portable cygwin with git, no installer - [git-scm](https://git-scm.com/download/win) 6 | 7 | ## Cheat sheets 8 | * [git cheat sheet](https://education.github.com/git-cheat-sheet-education.pdf) 9 | * [UNIX/Linux command line cheat sheet](https://files.fosswire.com/2007/08/fwunixref.pdf) 10 | 11 | -------------------------------------------------------------------------------- /syllabus.md: -------------------------------------------------------------------------------- 1 | * [Spring semester 2017 - University of Missouri St. Louis](2017-Spring-UMSL.md) 2 | * [Spring semester 2019 - Washington University](2019-Spring-WashU.md) 3 | --------------------------------------------------------------------------------