DPS909 and OSD600 Fall 2014 Notes

Week 1

• Course introduction
• Question: What is Open Source? Why work on Open Source as a student?
  • I studied business and programming, not English. I still can't find a job
  • The Secret to Hiring Great Developers
  • https://twitter.com/jeresig/status/33968704983138304
  • Facebook open source in 2014
  • Facebook on Github
• Success in this course requires:
  • Willingness to be lost and not panic
  • Curiosity
  • Being driven, persistence
  • Willingness to ask for help
  • Willingness to give others help
  • Independent learning
  • Doing more, much more, than the bare minimum
• What are Seneca and Seneca students capable of accomplishing? Some examples
  • Audio Data API, Pointerlock, Gamepad API
    • https://blog.mozilla.org/blog/2014/03/18/mozilla-and-unity-bring-unity-game-engine-to-webgl/
    • https://developer.mozilla.org/ms/demos/detail/bananabread
  • WebVTT
    • Example

• Intro to open source
  • Proprietary Licenses, EULAs
    • Microsoft
    • Apple, Richard Dreyfuss reads the iTunes EULA
    • Skype
  • Open Licenses
    • BSD
    • GPL
    • LGPL
    • MIT
    • Apache
    • MPL

• TODO
  • Create an account on this wiki for yourself (note: requires manual creation)
  • Add your info to the Fall 2014 Open Source Students page.
  • Create a blog (wordpress or blogspot or whatever) and create a feed category or tag called "open source"
  • Read the Blog Guidelines for instructions on how to use your blog in the course
  • Add your blog feed and info to the Open Source@Seneca Planet List so that it appears in the OpenSource@Seneca Planet
  • Pick one Closed and one Open license/EULA, and read them from start to finish. Pick 3 things that struck you, blog about it and your reactions to the readings this week.
  • Begin learning how to use IRC for communication. We'll cover this in detail next week, but it's better to get started early.

Week 2

• Open/Closed Licenses
  • Discussion of findings in license readings from week 1
  • Case Study: Markdown and open licensing, open standards, forking, blogging, and Twitter
    • Markdown 1.0.1 (2004)
    • Markdown's license
    • Markdown is used everywhere, by everyone
      • Example: Markdown for documentation - https://github.com/antirez/redis-doc/pull/417
    • calling out a maintainer (2009)
    • call for standardization of Markdown (2012)
    • failed attempt to standardize (2012)
    • podcast of Gruber discussing Markdown
    • a second attempt, Standard Markdown (2014)
    • Standard Markdown rejected
    • the difficulty with standardizing
    • naming fallout
    • a third attempt, Common Markdown (2014)
    • ...and finally http://commonmark.org
    • Winer's open email to Gruber, with parallels to RSS/Atom

• Discussion of Class Projects: enabling browser based cloud sharing
  • Filer - https://github.com/js-platform/filer
  • MakeDrive - https://github.com/mozilla/makedrive, http://blog.humphd.org/introducing-makedrive/
  • Brackets - http://brackets.io/
  • Nimble - https://github.com/mozilla/nimble.webmaker.org
  • Appmaker - https://github.com/mozilla-appmaker/appmaker
  • Mobile Appmaker - https://github.com/mozillafordevelopment/mobile-appmaker/
    • http://tech.firstpost.com/news-analysis/spice-fire-one-running-mozillas-firefox-os-launched-for-rs-2299-230409.html
    • https://blog.mozilla.org/blog/2014/08/29/firefox-os-smartphones-available-in-india-this-week/
    • http://bgr.com/2014/08/27/mozilla-firefox-os-smartphone-iphone/

• Release 0.1
  • Option 1 (for those new to open source):
    • Implement du in Filer
    • You will learn git, github, JavaScript, node.js, npm, Filer, code review
    • You must fix the bug yourself and have it reviewed by another student *and* review another student's implementation (i.e., do a pull request against another student's fork, and vice versa)
  • Option 2 (for those with more experience):
    • Find and fix a bug in one of the projects listed above which is of an equal size to Option 1
    • Releases 0.2, 0.3, and 0.4 will be like Option 2 for everyone

• TODO
  • Sign-up for a case study and begin researching and immersing yourself - 2014 Open Source Project Case Study
  • Reading for Wednesday's class: The Cathedral and the Bazaar. Please be prepared to discuss next class.
  • Figure out which option you will do for Release 0.1 and begin working on it.
  • Sign-up for an Open Source Case Study
  • Write an introductory blog post about the case study project you chose, and the project that you will be researching.

Week 3

• Discussion of The Cathedral and the Bazaar
  • "The Linux community seems to resemble a great babbling bazaar"
  • "Linus Torvald's style of development - Release early. Release often. And listen to your customers."
  • "Every good work of software starts by scratching a developer's personal itch."
  • "Good programmers know what to write. Great ones know what to rewrite (and reuse)."
  • "Plan to throw one away; you will, anyhow (Fred Brooks)"
  • "You often don't really understand the problem until after the first time you implement a solution."
  • "When you lose interest in a program, your last duty is to hand it off to a competent successor."
  • "Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging."
  • Linus' Law: "Given enough eyeballs, all bugs are shallow." or "Debugging is parallelizable" and "More users find more bugs...because adding more users adds more different ways of stressing the program."
  • "Somebody finds the problem...and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge."
    • In the cathedral-view bugs are "tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals."
    • "In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena - or, at least, that they turn shallow pretty quick when exposed to a thousand eager co-developers pounding on every single new release."
  • "If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource."

• Release 0.1 - Getting Started
  • Case Study: implementing wc
    • "%d %d %d %s\n", <newlines>, <words>, <bytes>, <file>
    • Fork it - https://github.com/js-platform/filer
    • Clone it - http://git-scm.com/book/en/Git-Basics-Getting-a-Git-Repository#Cloning-an-Existing-Repository
    • Setup Dev Environment - https://github.com/js-platform/filer/blob/develop/CONTRIBUTING.md
      • An open source code editor: suggestions include Brackets or Atom
      • node.js
      • npm install
      • npm install -g grunt-cli
    • Run the Tests - https://github.com/js-platform/filer/blob/develop/CONTRIBUTING.md#tests
      • grunt test
      • grunt test-browser and browse to http://localhost:1234/tests/
    • Find similar code - tests, code, docs
      • sh.cat() docs
      • sh.cat() code and tests
    • Write Tests First
      • Consider the cases we care about with wc
      • Study how the cat tests work
      • Copy/Paste/Modify/

• TODO
  • Install git http://git-scm.com/
  • Create a Github account if you haven't already
  • Fork and clone Filer and start on Release 0.1 if you haven't already (due in 2 weeks). Blog about your progress, what you learned, what you still need to learn
  • Read chapters 1 & 2 of Pro Git, be ready to discuss next week.