How to Make a Collaborative Hardware Project Hack Chat Transcript

12:05 PM

*waves hello*

Noel says:

12:05 PM

Hello all!

Boian Mitov says:

12:05 PM

Hello @Pete Dokter and @Toni Klopfenstein :-)

Stephen says:

12:05 PM

Why don't you all kick us off by telling us a bit about your self and your experience with hardware collaboration.

Shayna says:

12:05 PM

Hi all

Pete Dokter says:

12:06 PM

Oh, jeez... Hardware collab is sorta a double edged sword. I'm not necessarily opposed, of course, but... I'm kind of a hermit when it comes to personal projects.

Pete Dokter says:

12:06 PM

There are times it works, and times it won't.

Sophi Kravitz says:

12:07 PM

agreed

Pete Dokter says:

12:07 PM

Depends on the goal of the project and the personalities involved. Sorta like a band.

Sophi Kravitz says:

12:07 PM

I have a collaboration going right now, but it's someone I often work with, and we started working together off-line

12:07 PM

I've helped folks over the years through my work in tech support and engineering at sparkfun, and have occasionally worked on personal projects as well, but usually only when folks have asked for support (I don't necessarily go seek them out)

12:07 PM

mostly from a sheer lack of time

Pete Dokter says:

12:08 PM

I was telling somebody earlier that I ususally enter into projects to go on a journey. And mine is seldom in the same scope as others.

Pete Dokter says:

12:08 PM

Toni says I'm a snowflake.

Sophi Kravitz says:

12:08 PM

But you (Toni) must see how often the schematics are downloaded at Sparkfun ... yeah?

12:08 PM

Definitely!

Sophi Kravitz says:

12:09 PM

back up for a sec

Sophi Kravitz says:

12:09 PM

Toni, can you tell this group your role at Sparkfun, specifically how it pertains to the schematics/ layouts/ hardware doc?

12:10 PM

I'm the Product Development Manager - my team helps ensure our docs/code/schematics are all available and functional for our customers, and often creates them for different products/projects as well

12:10 PM

It's a lot of curation

Robert Marosi says:

12:10 PM

Have you folks considered moving away from Eagle and more towards KiCad yet?

12:10 PM

It's a constant discussion

12:11 PM

We've been talking about it for years

zakqwy says:

12:11 PM

version 5 is SPICEy!

Pete Dokter says:

12:11 PM

True that. I did the Lumenati boards with KiCad.

Sophi Kravitz says:

12:11 PM

so if we were to discuss a fictional project, a hardware project, how would the documents be worked on in a hardware collab?

Pete Dokter says:

12:11 PM

But it's a headache with lots of overhead to make the switch, I'm sure y'all can appreciate.

12:11 PM

For a hardware project, we use a couple different file sharing platforms

Noel says:

12:12 PM

I think the decision with eagle vs kicad has gotten harder with promised improvements from autodesk

Sophi Kravitz says:

12:12 PM

(also, let's stay on topic... the KiCad / Eagle thing will be in a different chat :)

12:12 PM

GitHub for the board/schematic/code files, and then we have an internal system for the guides

Taylor Street says:

12:12 PM

Which platforms have you found to be the best?

Adam Weld says:

12:12 PM

similarly, what are the most important tools for broader organization of the collab?

12:12 PM

When I started at SparkFun, we used a server that anyone could access/edit, without any record of who changed what

Stephen says:

12:13 PM

Please add your questions to the event page:

Stephen says:

12:13 PM

You've inherited a project with hardware, firmware, and an app. There is virtually no documentation for it. Part of it is public, part of it is private. What is the best way to document it both for new collaborators and for the "internal" developers?

Sophi Kravitz says:

12:13 PM

I think collabs work best with project management system, so everyone can see who is doing what. I tend to use Google docs

Stephen says:

12:13 PM

And on that note, here is our first question from the crowd for everyone:

Stephen says:

12:13 PM

This one is from the infamous @Lutetium : What is the best way to on-board new collaborators?

Pete Dokter says:

12:14 PM

Well, we don't really have a system, per se... Toni?

12:14 PM

It depends on whether the collaborators are local or remote

Sophi Kravitz says:

12:14 PM

If it is a work project, then easiest to find out what their skills are and "assign" them to a part of the project

Boian Mitov says:

12:14 PM

I do an architectural overview of the project on hands, and walk them through the code etc.

12:14 PM

What @Sophi Kravitz said

12:15 PM

We have a pretty standard assignment process for people in the building, but it gets tricky with remote folks

12:15 PM

onboarding is more than just telling them what to do, though

Boian Mitov says:

12:15 PM

Also assigning specific tasks works best after the overview has been done

Sophi Kravitz says:

12:15 PM

if is it personal project... lots of times you yourself have to figure out what the collaborators skillset is

Sophi Kravitz says:

12:15 PM

yeah tru

Pete Dokter says:

12:15 PM

Oh, sure. You've got to do a full overview of the project from start to finish before you can ask anything of anyone.

Robert Marosi says:

12:15 PM

I think good documentation practices play a part in onboarding as well

12:16 PM

what practices are those, specifically?

12:16 PM

Start with a conversation - what are your goals for collaborating, what are the goals of the project itself, and what can everyone offer skill wise?

Stephen says:

12:16 PM

@ɖҿϝիɟթվ asks: How to make the would-be collaborators actually read the documentation you wrote about how to contribute?

Sophi Kravitz says:

12:16 PM

absolutely! (although no one likes to document)

Stephen says:

12:16 PM

Along with their above question :)

Pete Dokter says:

12:16 PM

How to make them? Follow up with a quiz?

Pete Dokter says:

12:17 PM

Some people yoiu just can't trust...

Sophi Kravitz says:

12:17 PM

Toni and Pete, do you think the project originator comes up with the goals or do we allow every collaborator to make goals?

12:17 PM

all of them, actually, but that's a separate issue

Pete Dokter says:

12:17 PM

To follow with the band analogy, you've got to have a lead. Too many cooks and all that.

Sophi Kravitz says:

12:17 PM

LOL

Sophi Kravitz says:

12:18 PM

And the lead is usually the originator, the person who cares the most

12:18 PM

true

Pete Dokter says:

12:18 PM

But then, people have to be compensated in some fashion for their time.

Sophi Kravitz says:

12:18 PM

or it is the person funding the project (which sucks)

Sophi Kravitz says:

12:19 PM

well, in a work project, they are being compensated

Sophi Kravitz says:

12:19 PM

should we talk only about not-work projects?

Robert Marosi says:

12:19 PM

I think the compensation is being able to put the project on your resume, assuming it's actually successfull

12:19 PM

at work most of those problems are solved by the work setup itself

AKA says:

12:19 PM

as a control freak *and* a lazy person, i'm bad in spare-time collabs because I vacillate between guilt (I owe team more) and charging ahead with stuff so it works as I think it should (which obviates the "collab" part of the project)

12:19 PM

In personal projects, they are often getting to practice their skills, or resume building, or networking...lots of different reasons

Stephen says:

12:19 PM

I suggest we keep this chat to non-work related collaborations

Pete Dokter says:

12:19 PM

Yes, but... in my mind, and maybe I'm off here, we're talking about non-workplace projects. Things that people just want to be involved with. Dig?

Sophi Kravitz says:

12:19 PM

Sophi Kravitz says:

12:19 PM

Pete Dokter says:

12:19 PM

That.

Stephen says:

12:19 PM

So is the best way to onboard people them to sit down with them and hand-hold through the design? This doesn't seem to be the case for many software projects

Sophi Kravitz says:

12:20 PM

but we are talking about hardware projects

Robert Marosi says:

12:20 PM

why don't we have both XD

Sophi Kravitz says:

12:20 PM

all projects have both

Sophi Kravitz says:

12:20 PM

but this chat is about hardware specifically

Pete Dokter says:

12:20 PM

In my experience, the best way to bring somebody up to speed on anything is to sit down 1 on 1 and 'spain and answer all the questions. It can be very time consumning.

Sophi Kravitz says:

12:21 PM

12:21 PM

I think it's important to remember that a project is not the same thing as the product that it results in. Project consists of people, not code and design files, and a single project may produce multiple artifacts over its life.

Pete Dokter says:

12:21 PM

'splain. Dammit.

Stephen says:

12:21 PM

Correct. They are also technical collaborations as well, so I imagine there is a lot of overlap in issues that we could learn from

Sophi Kravitz says:

12:21 PM

@Pete Dokter typos +1

Stephen says:

12:21 PM

In this vain, @Lucas Rangit MAGASWERAN asks: Is there an equivalent to a Code Style Guide for Hardware Designers?

Sophi Kravitz says:

12:22 PM

there needs to be

Stephen says:

12:22 PM

12:22 PM

We have DFM rules that we use (Design for manufacturing)

Sophi Kravitz says:

12:22 PM

yes, in a work situation, there will be a guide to best practices

Bharbour says:

12:22 PM

There certainly is for RTL projects

Sophi Kravitz says:

12:22 PM

(and DFM)

Sophi Kravitz says:

12:22 PM

but in a not-work situation, I don't think so

12:22 PM

depends on the scope of the project

Robert Marosi says:

12:23 PM

what are some of the main DFM rules? Is there a good resource for DFM rules?

Pete Dokter says:

12:23 PM

I've always sorta seen hardware as the place where I can break some rules if need be.

Stephen says:

12:23 PM

Are those DFM rules public? Would they be applicable to many hardware projects?

Benchoff says:

12:23 PM

Seeed has a very good dfm manual, btw: http://www.seeedstudio.com/blog/2017/05/11/seeed-fusion-free-pcb-dfm-manual/

Sophi Kravitz says:

12:23 PM

DFM: depends on the project, but there are rules that everyone follows generally

Pete Dokter says:

12:23 PM

Had not seen that yet.

Sophi Kravitz says:

12:23 PM

me neither

Benchoff says:

12:24 PM

really only applicable to seeed, but it's still good.

Sophi Kravitz says:

12:24 PM

and the last two things I bought there didn't work

Pete Dokter says:

12:24 PM

Burn...

Stephen says:

12:24 PM

Robert Marosi says:

12:24 PM

good find.

Lucas Rangit MAGASWERAN says:

12:24 PM

thanks @Benchoff

Sophi Kravitz says:

12:24 PM

thank Brian!

Sophi Kravitz says:

12:25 PM

so when you have a not-work hardware project, such as one of Radomir's robots, what is good way to start a new person on the project

Stephen says:

12:25 PM

Let's move on to the next question by @zakqwy: How do you handle the practical logistical concerns of working on a project across geographic boundaries? When do you ship stuff, when do you tell people to build their own local copy, when do you give hardware to new contributors?

Sophi Kravitz says:

12:25 PM

1. explain the project

Sophi Kravitz says:

12:26 PM

I usually send a board, populated

Stephen says:

12:26 PM

Please continue Sophi, and we'll get to the next question when you're done !

Sophi Kravitz says:

12:26 PM

no the question is fine... Pete and I were just talking about this, so want to continue this

Sophi Kravitz says:

12:26 PM

I will send a populated, working, board

Sophi Kravitz says:

12:26 PM

which in theory should result in a new populated and working next rev board

Pete Dokter says:

12:27 PM

I'd want to see some level of commitment from somebody before I build and send them a board. What that looks like, I'm not sure. You're already sharing ideas and work. Maybe I expect too much? I think Sophi was trying to sell me on teh idea of giving away free hardware to get people jazzed. But we've had lots of hardwre disappear that way.

Stephen says:

12:27 PM

From there do you copy each other's revs on your own boards? Or pass that one back and forth?

Sophi Kravitz says:

12:27 PM

this is hard to manage. People get busy, people take on too many projects

12:27 PM

clear expectations on deliverables need to be set

Pete Dokter says:

12:27 PM

Two iterations isn't a bad idea.

Sophi Kravitz says:

12:27 PM

I have a board here from @AKA and a servo motor from @nick steadman :(

DrivenMadz says:

12:28 PM

gitlab for rev. and collab :)

AKA says:

12:28 PM

LOL, i synchronize prototyping setups across geographies using photographs of benchtops :-/

Sophi Kravitz says:

12:28 PM

LOL

zakqwy says:

12:29 PM

hahaha i like it

Stephen says:

12:29 PM

hah!

Shayna says:

12:29 PM

lol

Pete Dokter says:

12:29 PM

Not a bad idea.

Taylor Street says:

12:29 PM

Lately, I have been using Kicad with Github or Bitbucket. You can commits and diffs a bit more straightforward, since Kicad stores all files in ASCII format.

Sophi Kravitz says:

12:29 PM

so we're coming up with some steps :)

DrivenMadz says:

12:29 PM

Love it :)

Stephen says:

12:29 PM

Sending hardware to people does allow them to overcome some economic barrier to collaborators. Our next question from the chat is: How do you make working on a project as accessible to collaborators as possible? Should you?

zakqwy says:

12:29 PM

thanks for the thoughts. I think the sending-hardware-to-someone question is always an 'it depends' thing, but it's nice to see others' perspectives

12:30 PM

If you want collaboration to happen, you need to make it accessible

Sophi Kravitz says:

12:30 PM

By giving away hardware?

Sophi Kravitz says:

12:31 PM

and making the documentation clear?

Pete Dokter says:

12:31 PM

Well... in for a penny, in for a pound. If you're going to call it a collaboration, you can't keep people from it, can you?

12:31 PM

Make sure files are on a platform everyone can access, if there are economic restrictions on collaborators, get them hardware

Pete Dokter says:

12:31 PM

Sophi's just a really giving person.

12:31 PM

make the documentation as clear as possible (yay for photos!)

Robert Marosi says:

12:31 PM

More like, by making the hardware easy-ish to make by anyone

12:31 PM

that's something to keep in mind when designing

Sophi Kravitz says:

12:32 PM

yes- but if the hardware is easy, you might not need a collaborator

Pete Dokter says:

12:32 PM

I'd prolly keep designs using at least 0603 or bigger parts, but I still expect people to go the distance and build some stuff.

Pete Dokter says:

12:32 PM

Unless I'm funding?

Taylor Street says:

12:32 PM

I think even an unpopulated board goes a long way. That's always the hardest thing, at least economically (in general), to do.

Sophi Kravitz says:

12:32 PM

I'm at 0805s, don't send me anything smaller

Pete Dokter says:

12:32 PM

Oh, waaaa...

Stephen says:

12:32 PM

@Robert Marosi asks: How much time should we put into planning projects? How do we keep ourselves from being overly optimistic about what we're capable of doing or how long things will take?

Sophi Kravitz says:

12:33 PM

bad eyesight....

12:33 PM

Always build in 20% more time than you expect it will take

12:33 PM

and plan for delays on top of that :)

Sophi Kravitz says:

12:33 PM

I love it

Andrew Sowa says:

12:33 PM

I used 0603 to keep cost and board size down but what size smd part is probably a long conversation

zakqwy says:

12:33 PM

I would say .. the inverse of that.

Pete Dokter says:

12:33 PM

Hey, you gotta push yourself. You should be reaching a bit on every project, no?

Sophi Kravitz says:

12:33 PM

I used to work somewhere we built in 39% (!!!)

zakqwy says:

12:33 PM

As in, 1/0.2, or 5x.

Sophi Kravitz says:

12:33 PM

39% worked out perfectly every time

Stephen says:

12:33 PM

I use the Pi rule when working with other engineers - multiply all time and $$ estimates by pi

Clayton G. Hobbs says:

12:34 PM

my feeling is that estimating time is a skill that's learned, not taught ;)

Robert Marosi says:

12:34 PM

39% is oddy specific. 40% is better

Taylor Street says:

12:34 PM

Pi Rule. Brilliant, I love it.

12:34 PM

it's hard to estimate though if you're working with new collaborators

12:34 PM

so some general guidelines help

Sophi Kravitz says:

12:34 PM

totally.

Sophi Kravitz says:

12:34 PM

like... ?

Pete Dokter says:

12:34 PM

Set a timeline of "can you do this inside of a week?"

Pete Dokter says:

12:35 PM

See how they do.

Pete Dokter says:

12:35 PM

Something small-ish, maybe.

12:35 PM

Test runs are good, breaking the project into bite sized chunks to keep progress moving forward

12:35 PM

schedule out check-ins at the beginning of the collaboration to give everyone goals

Pete Dokter says:

12:35 PM

That's how we've broken in new employees...

Sophi Kravitz says:

12:35 PM

do you do design sprints?

12:35 PM

depends on the project

DrivenMadz says:

12:36 PM

ensure communications pipes, email, chat,etc. setup a couple times that people can plan for. Always take notes :)

12:36 PM

and make sure the notes exist where everyone can find them!

DrivenMadz says:

12:36 PM

+1 Toniu

Sophi Kravitz says:

12:36 PM

Taylor Street says:

12:36 PM

What actual form of communication do you primarily rely on? Email? Calling? Texting?

Sophi Kravitz says:

12:36 PM

all the thigns

Sophi Kravitz says:

12:37 PM

I'll use whatever the others want to use

Pete Dokter says:

12:37 PM

Email here.

12:37 PM

all of the above

DrivenMadz says:

12:37 PM

find what works the best for the group

Sophi Kravitz says:

12:37 PM

my favorite is google doc

Sophi Kravitz says:

12:37 PM

no notifications

Stephen says:

12:37 PM

Since we're all so familiar with the overcommitted engineer trope, we have the questions:

- The most graceful way of leaving a project that you are no longer interested in?

- Any suggestions for handling contributors that aren't contributing anymore?

DrivenMadz says:

12:37 PM

for sure google doc is getting better and better !

Taylor Street says:

12:38 PM

Really? That's an interesting choice. Never thought of using Google Docs.

12:38 PM

To leave a project - just be straightforward about it. Communicate to all members, and ensure you've explained any work to whomever you're handing off to

zakqwy says:

12:38 PM

google docs is _great_ for writing and editing documentation

Pete Dokter says:

12:38 PM

Ah... personal relationships. Like anything, you just gotta be straight with people.

Sophi Kravitz says:

12:38 PM

:) no need to be graceful... just politely say you have no time/ interest/ money and leave the project

baldengineer says:

12:38 PM

Google docs is great as long as you aren't working with someone in China

zakqwy says:

12:38 PM

oof good point

Taylor Street says:

12:39 PM

Ha, that's actually my situation.

DrivenMadz says:

12:39 PM

google doc in china =VPN :)

Pete Dokter says:

12:39 PM

Huh. Did not know that.

zakqwy says:

12:39 PM

uh, WeChat Docs?

Sophi Kravitz says:

12:39 PM

hahaha

Stephen says:

12:39 PM

haha

Sophi Kravitz says:

12:39 PM

somehow my wechat bbq channel resurrected yesterday by itself

Pete Dokter says:

12:39 PM

Taylor Street says:

12:40 PM

? ndeed!

12:40 PM

They reset the internet to a previous version. :)

zakqwy says:

12:40 PM

i usually don't question bbq

Sophi Kravitz says:

12:40 PM

some long ago channel where people just say where they're eating dinner

Sophi Kravitz says:

12:40 PM

in Shenzhen

Taylor Street says:

12:40 PM

hahaha

zakqwy says:

12:40 PM

haha that is amazing

Pete Dokter says:

12:41 PM

BTW, everybody needs to check out "Orphans of Doom".

Stephen says:

12:41 PM

What about when it's not you who isn't contributing, but them? @baldengineer asks: Any suggestions for handling contributors that aren't contributing anymore?

Sophi Kravitz says:

12:41 PM

what abt contributors who don't work anymore?

Sophi Kravitz says:

12:41 PM

thanks :) @Stephen

12:41 PM

Try to reach out, and if you just can't get the info, move on.

Robert Marosi says:

12:41 PM

make 2~3 attempts to get in contact, then drop them if nothing

Stephen says:

12:41 PM

Np, Sophi, I'm lookin' out

Sophi Kravitz says:

12:41 PM

yeah, I would just move on, no need for drama

Pete Dokter says:

12:42 PM

Yeah. Ask them straight of their heart is still in it or not, offer them the graceful exit option.

12:42 PM

And be aware that life happens, and sometimes people just have to disappear from a project. It's almost never because of malicious reasons

DrivenMadz says:

12:43 PM

I wonder if a simple newsletter type directed at contributors from time to time the remind everyone and make sure any resources available to them are linked/posted ?

Robert Marosi says:

12:43 PM

yep. if people are working on these projects for free, the project isn't gonna be their first priority

Sophi Kravitz says:

12:43 PM

unless there is a deadline

Sophi Kravitz says:

12:43 PM

like presenting it somewhere

Stephen says:

12:43 PM

even then...

Sophi Kravitz says:

12:43 PM

or putting it on a resume

12:44 PM

I like to check with folks at the beginning of the project and ask honestly "do you think you can realistically participate in this timeline, or do you have life stuff that might get in the way?"

Pete Dokter says:

12:44 PM

Good call.

pt says:

12:44 PM

hi @Pete Dokter just wanted to say enjoying the according to pete videos, keep up the good work (and also hi @Toni Klopfenstein ) !

Sophi Kravitz says:

12:44 PM

that's smart

12:44 PM

Keeps my expectations realistic for their potential level of collaboration

DrivenMadz says:

12:44 PM

great idea Sophi, resume. hint towards the way they can benefit form the experience :)

Pete Dokter says:

12:44 PM

Hey PT!

Stephen says:

12:44 PM

What is the best way to defend against all the people wanting to join your project but having no clue what it is about and how they would contribute?

12:44 PM

Hi!

Sophi Kravitz says:

12:44 PM

hi @pt !

Sophi Kravitz says:

12:45 PM

@Stephen that's a great question

Pete Dokter says:

12:45 PM

Don't offer it up in the first place?

DrivenMadz says:

12:45 PM

guidelines and what is really needed from the start? to give a kind of expected direction may be ? :)

Sophi Kravitz says:

12:45 PM

well, no. if you are putting your project in a public place, then you are offering it up

DrivenMadz says:

12:46 PM

true

Pete Dokter says:

12:46 PM

Exactly my point. If you need to maintain some level of control, be discriminating from the get-go.

Sophi Kravitz says:

12:46 PM

but as Toni said earlier, you can break the project up into small chunks and

Sophi Kravitz says:

12:46 PM

ask people if they can deliver on something small

zakqwy says:

12:46 PM

I've found the toolchain question can be pretty effective

Pete Dokter says:

12:46 PM

lol

zakqwy says:

12:46 PM

'sure here's some hardware, but you need to get it to compile and flash'

Sophi Kravitz says:

12:46 PM

what's that Zach?

Sophi Kravitz says:

12:47 PM

(hides)

Stephen says:

12:47 PM

That's how I often onboard people, ask them for a small contribution and when they show up with that give them a larger one - ease them in

12:47 PM

"you need to be this tall to compile it"

Stephen says:

12:47 PM

hah!

zakqwy says:

12:47 PM

i.e. if it's an AVR project, can they work with avrdude? do they have a programmer (or can they make one)?

AKA says:

12:47 PM

LOL zach that's the kindest way to tell me to eff off of a project ;-)

Sophi Kravitz says:

12:47 PM

same same

zakqwy says:

12:47 PM

Stephen says:

12:48 PM

Ooh, my question is up! Thinking of hardware collaboration in a broader sense; How do you design & document a project so that others can easily incorporate your work into new and spinoff projects of their own?

zakqwy says:

12:48 PM

that's why teensys are the best!

12:48 PM

in my experience nobody ever is interested in re-creating your project, no matter how good the documentation is

DrivenMadz says:

12:48 PM

+1 great question

12:48 PM

Make sure the files are accessible to all, make sure there are clear instructions on how to use the existing platform, and make sure your license terms are included (and clear)

Robert Marosi says:

12:48 PM

as for spinoffs, you need some sort of licensing that allows spinoffs, yeah?

12:49 PM

and be willing to answer questions about your hardware

Sophi Kravitz says:

12:49 PM

be accessible, as in say how they can contact you

12:49 PM

yup, or guide them to where other folks using the materials are

Sophi Kravitz says:

12:49 PM

the trouble is when people ask you about code you wrote 3 years ago

12:49 PM

(forums, chats, etc.)

Ted Yapo says:

12:49 PM

I've seen several re-spins of projects on this site. it definitely happens.

Robert Marosi says:

12:49 PM

//write more comments

Sophi Kravitz says:

12:50 PM

+1 Robert

Sophi Kravitz says:

12:50 PM

@Ted Yapo yes we do have a lot of re-spins

Sophi Kravitz says:

12:50 PM

and people use the comments mainly to talk things out in public

Pete Dokter says:

12:50 PM

That's just a part of the game.

AKA says:

12:50 PM

(what is a re-spin?)

Taylor Street says:

12:50 PM

What are the primary open source licenses you use? Do you find that it matters much?

Sophi Kravitz says:

12:51 PM

Noah- a re-make of your PCB, often with extra parts

zakqwy says:

12:51 PM

Stephen says:

12:51 PM

What projects have people done outside of work that have been collaborative and/or had successful spinoffs?

Pete Dokter says:

12:51 PM

I'm still partial to Beerware.

https://creativecommons.org/licenses/by-sa/4.0/

12:51 PM

CREATIVECOMMONS

Creative Commons - Attribution-ShareAlike 4.0 International - CC BY-SA 4.0

Bahasa Indonesia Bahasa Malaysia Castellano Castellano (España) Català Dansk Deutsch English Esperanto français Galego hrvatski Italiano Latviski Lietuvių Magyar Nederlands norsk polski Português Português (BR) română Slovenščina suomeksi svenska Türkçe Íslenska čeština Ελληνικά Беларуская русский українська العربية پارسی বাংলা 中文日本語華語 (台灣) 한국어

Read this on Creativecommons >

12:51 PM

@zakqwy but that had 0 documentation!

anfractuosity says:

12:51 PM

@Pete Dokter heh, that sounds interesting

Robert Marosi says:

12:51 PM

I think it matters because it explicitly tells others whether or not they're free to make spinoffs and what the scope is

https://opensource.org/licenses/MIT

12:51 PM

beerware is good (except in an education setting), MIT license is good

Sophi Kravitz says:

12:51 PM

OPENSOURCE

The MIT License | Open Source Initiative

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

Read this on Opensource >

12:52 PM

@zakqwy also, no eyes

zakqwy says:

12:52 PM

i usually do MIT or CC-By-SA 4.0

12:52 PM

same here

Sophi Kravitz says:

12:52 PM

I don't usually do anything

anfractuosity says:

12:52 PM

can you use GPL for hardware out of interest?

zakqwy says:

12:52 PM

yeah, i need to finish assembling ...

12:52 PM

mit for code, cc for hardware

12:52 PM

@anfractuosity you can, but it's discouraged

Taylor Street says:

12:52 PM

Excellent. Thanks.

anfractuosity says:

12:52 PM

aha

zakqwy says:

12:53 PM

@anfractuosity I did previously but now use CC-By-SA 4.0

12:53 PM

@anfractuosity and it would be legally ambiguous

Pete Dokter says:

12:53 PM

I don't normally expect taht much for my work. If I can extract a beer once in a while, life is good.

zakqwy says:

12:53 PM

mostly because people told me it was a bad idea

Stephen says:

12:53 PM

I like this question: @Robert Marosi asks - Do you think we can incentivize more project creation and collaboration by holding more Hackaday contests?

Sophi Kravitz says:

12:53 PM

Yes! Of course!

zakqwy says:

12:53 PM

you guys need to get @alpha_ninja to run another contest, that was the best one IMHO

Stephen says:

12:53 PM

I sure think so!@

12:53 PM

hmm, a contest that requires collaboration?

Pete Dokter says:

12:54 PM

You're giving people a reason to work together, so that's agood place to start.

Sophi Kravitz says:

12:54 PM

we might want to do something where it requires collabs

Ted Yapo says:

12:54 PM

like a 3-legged race, lol

Sophi Kravitz says:

12:54 PM

@alpha_ninja contest was perfect

Stephen says:

12:54 PM

I loved the one square inch contest

https://hackaday.io/project/7813-the-square-inch-project

12:54 PM

What's that?

Stephen says:

12:54 PM

Three legged hardware race!

Sophi Kravitz says:

12:55 PM

HACKADAY

The Square Inch Project

A contest to create awesome, useful square inch boards. Entries are closed.

Read this on Hackaday >

12:55 PM

ooo I like that

Pete Dokter says:

12:55 PM

I'd do that.

anfractuosity says:

12:55 PM

maybe you could re-run it as the 2.54cm project ;)

Sophi Kravitz says:

12:55 PM

HAHAHAHA

12:55 PM

Pete Dokter says:

12:55 PM

Oh, I'm in.

Sophi Kravitz says:

12:55 PM

actually @alpha_ninja planned to re-run this

12:55 PM

254mm

zakqwy says:

12:56 PM

'this is totally a different contest!'

12:56 PM

AKA says:

12:56 PM

let's bump it up to a power of two tho

Taylor Street says:

12:56 PM

Have it be an annual contest.

Stephen says:

12:56 PM

We have 5 minutes left in the chat, so we have enough time for two questions if you can come to a conclusion quickly, but that will be a challenge...

Stephen says:

12:56 PM

What EDA tool is best for handling contributions? How do you review and compare those changes?

12:56 PM

10x the fun.

Sophi Kravitz says:

12:56 PM

so back to the collab thing- should we require collaboration on this? or do we award extra points to teams?

AKA says:

12:56 PM

i think it'd be fun to do an Exquisite Corpse hardware contest

Sophi Kravitz says:

12:57 PM

smh. sick

Pete Dokter says:

12:57 PM

That one I don't got. Sorry.

Robert Marosi says:

12:57 PM

both of those rules could be abused by contestants somehow

zakqwy says:

12:57 PM

hey hey hey so 5 minutes left I have a PSA. i have ~90 minutes extra in the 10m EMC chamber next Friday, so if you have an unintentional radiator you want to pretest .. send me a PM. preference goes to open hardware projects.

https://en.wikipedia.org/wiki/Exquisite_corpse

12:57 PM

WIKIPEDIA

Exquisite corpse - Wikipedia

Exquisite corpse, also known as exquisite cadaver (from the original French term cadavre exquis ), is a method by which a collection of words or images is collectively assembled. Each collaborator adds to a composition in sequence, either by following a rule (e.g. "The the adjective noun."

Read this on Wikipedia >

Taylor Street says:

12:57 PM

Require it, but make it easy for people to join/start teams.

AKA says:

12:57 PM

like the Travelling Maker box, but each time you send it off you provide an interface (and obscure the internals) https://en.wikipedia.org/wiki/Exquisite_corpse

Pete Dokter says:

12:57 PM

WT...?

Pete Dokter says:

12:57 PM

TONI!!