## 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