Fossisms

Latest revision as of 16:59, 27 February 2017

Draft... Draft... Draft

This page is a rough draft of expressions that capture some important aspect of FOSS process or culture. If someone has time to work on the page, it needs:

• Explanation for all the expressions
• Citations identifying a source (the original source if possible) for each expression. This list owes most of its content to an email by Mel Chua sent on 7 Oct 2012 and from flip charts created in a workshop on student participation in FOSS/HFOSS held at SIGCSE 2012. "The Cathedral and the Bazaar" should be cited for some of these expressions, and might be a source for other expressions not included here.

0. Be productively lost.

1. You pay for teaching with documentation.

2. If it's not public, it didn't happen.

3. Radical Transparency

4. Ask forgiveness, not permission.

There is very little in the open source world that can't be reverted, so if you're in doubt of what to do, just try out what you're thinking and then ask if it's okay. NOTE: although this is true in open source communities, this may not be true outside the open source world for you - so for instance, make sure your advisor is ok with you doing your lab exercise within KDE's codebase (for instance), but once you're in the KDE community, when working on KDE with other KDE people, you don't have to ask if it's okay to do something - just try it out.

5. Branches are free.

It costs basically nothing to make a copy of existing code and tinker around with it to see what's in there, whether you can tweak it, what your tweaks do, etc. If you mess up, just revert it (remember, version control!) or delete it from your machine, no harm done, nobody else need know. Sometimes, though, these experiments turn out to have useful results - and useful results are things you should always be proud to share.

6. Keep a history.

This is where version control comes in handy - make history-keeping an automatic side effect when possible, because it's way more likely that you'll do it then.

7. Begin with the finishing touches. (Also known as: don't reinvent the wheel, stand on the shoulders of giants, and scope a small project first.)

8. It's not what you know, it's what you want to learn. (You're already good enough to contribute to FOSS.)

Why do people come to universities and colleges to study instead of going through books by themselves at home? (we hope that) Part of it is becoming a member of a community of learners, being surrounded by other bright people doing things they're interested in at a high level; we don't expect freshmen to arrive on campus knowing everything.

It's similar in FOSS communities. Folks in FOSS communities are good

• because* they've gotten good by being part of those projects, those groups of people - you come in as a new contributor and learn the skills you need as you go along. We've had people learn to program, learn to package, learn system administration, even learn how to speak entirely new languages *because* of their participation in Fedora.

9. Release early, release often.

10. Show me the code.

11. With enough eyeballs, all bugs are shallow.

Let people help you as much as possible and as early as possible. We can only help with the things we can see and know about - make sure we know exactly how we can help you. The more people who know about your problem, the more likely it is that one of them can help you solve it.

12. Be present.

You might be surprised.