Open source

  • Legal:

    • Source code is out there (available to the public)

    • Source code can be used under "permissive" license:

      • Use as you will: "Open Source". Open Source Initiative, BSD or MIT licenses

      • Must make changes available: "Free Software". Free Software Foundation, GPL

    • Source code can be extended and republished

    • http://opensource.org has licenses and licensing information

  • Practice:

    • Open to developer contributions

    • Open governance

Choosing a project

  • Interest: Will you still care about this in 7 weeks?

  • Scope: Can you do it in 6 weeks?

  • Incremental: Can you do something cool in 2 weeks?

  • Uniqueness: What's the relation to existing stuff?

  • Multiple-Use: Can you use this project for more than this class?

  • Modular: Is it all "of a piece" with strong coherence and weak coupling?

  • Choose quickly!

Some classic project domains

  • Something you want to have: Often related to work or business. Make sure it is in-scope

  • Something you've always wanted to build. If you have a project passion, this is a good class for it

  • Something overlapping another class. Fine with me, but please clear it with the other instructor as well

  • A game. This makes a really good project

  • A webapp. But for what? Webapps are a great project for this course. Understand that you will be evaluated on the code, not on assets or data. Probably use a framework

  • A mobile app. This is hard. I wouldn't suggest it unless you have a ton of time and coding skill and/or have already worked in the mobile space. You should have access to the hardware you're targeting — the simulator is usually not good enough to get work done

  • A library. Some of the best projects are this. A good library with a solid API is worth every bit as much as an app

  • A module for an existing Open Source project. This has to be something new, and coherent. But if some project has a need for a modular piece, this can be a great way to contribute

  • A hardware/software project. These are great fun. But do not attempt without some existing clue about this stuff: it's really hard to get started with otherwise

Some classic project red flags

If any of these apply, you should think carefully

  • Project seems potentially very large. I am much happier with a small project that is finished and clean than with a half-finished garbage dump of code

  • Project is far outside your area of expertise. If you are hoping to use your project to learn a new programming language or something, think very carefully: we only have about six weeks for the project, and so the difficulty is quite high

  • Project is something super-generic. To be honest, I've grown quite allergic to things like "shopping list" or "exercise recorder"; they are all too often extensively plagiarized. I'm sure this doesn't apply to you, but please pick something you're passionate about

  • Project has legal or ethical concerns. Just don't. Marijuana-related stuff is expressly forbidden at PSU. Medical stuff is pretty much out of bounds. I'd prefer not hacker tools (but talk to me)

  • Project is incoherent. The project must be a sensible, modular piece of work. Just "doing stuff" is not an open source project

Starting your open source project

  • Find a group of 2-3 people with a common interest. Figure out what to do

    • Working alone is OK but less fun and misses out on some of the experience

    • Groups of more than 3 please consult with me so that we can figure out what makes sense

  • Work out what technologies are going to be used. What programming language? What resources are needed?

  • Pick a good project name. It should be something that can be used as an identifier for the repository, or whatever. Here's some good links about project naming:

    That first link has a bunch of other great advice as well

    Be Warned: I won't take a project name like "Course Project" or with "CS 461" or the like in it. Name your project something meaningful for the long haul

  • Make a public Git repository for your project. Do this before you have anything meaningful to put in it. I strongly prefer Gitlab or Github for this class, but you may use something else if you really must.

    Once you have a repo, commit everything you do and push it upstream right away. You cannot start too early

  • Add a README.md and LICENSE file to your project first thing. Make it clear what you are doing and under what license you are making it available

  • Make a project roadmap and add it to the README. Say what you expect to do this quarter and when you expect it to be done. Then include post-class plans for the project.

    • Your roadmap should include some kind of "demo" or "prototype" version of your project to be done by week 3 of the course. This needs to be enough to show the viability of the project

    • Your roadmap should include some kind of "minimum viable product" (MVP) version of your project to be done by week 6 of the course. This doesn't have to have all the features, but should be enough that you could turn it in if needed. If you can't do this, rethink the project

  • Start to commit code, docs, etc to the project

Last modified: Tuesday, 25 June 2019, 1:46 AM