Author Topic: EEVblog #921 - Open Source Hardware Problems Solved!  (Read 63758 times)

0 Members and 1 Guest are viewing this topic.

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #150 on: September 16, 2016, 09:04:15 am »
There is nothing more limiting to the potential of open source than masquerading something not open as if it is open. That is the crux of the issue. You do not need to annotate the OSHW logo to do that. You just need to not use it.

Too bad that's not how it's worked out in the real world, and there is no changing that.
Keep hoping all you like, but it's not going to change, the majority of people will continue to use the OSHW logo without their project being fully open.
 

Offline wilfred

  • Super Contributor
  • ***
  • Posts: 1246
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #151 on: September 16, 2016, 12:08:38 pm »
There is nothing more limiting to the potential of open source than masquerading something not open as if it is open. That is the crux of the issue. You do not need to annotate the OSHW logo to do that. You just need to not use it.

Too bad that's not how it's worked out in the real world, and there is no changing that.
Keep hoping all you like, but it's not going to change, the majority of people will continue to use the OSHW logo without their project being fully open.

Look Dave, I know you are right that it will continue. I'm not expecting to change it. I just want people to understand that you cannot debate an issue if you are not focussed on the true core issue. I didn't think people here had properly understood that. It isn't about the logo, font, colours, letters or symbols, it is about accepting you have to abandon OSHW as a concept in practical usage.

So even if you accept the OSHW logo is destined to become meaningless and you tolerate allowing incompletely open products to proliferate, where will it get you? You'll end up clinging to a logo without value and listing out the documentation. What are you left with?

All I can see is the current problem flipped on it's head. Instead of solving the issue of not seeing at a glance what the not open product gives you, you will simply introduce the problem of people seeking an actual open product having to ferret throught the documentation to see what is missing. Is that what you want to call progress?

Like I said before the proposal you put on the table only really serves to cover the butts of commercial vendors pretending to be open. That, is what I am opposed to.
Owners manuals at one time included schematics and sometimes parts lists. It was just part of the products documentation. The world managed quite well not calling it open.

 

Offline Brumby

  • Supporter
  • ****
  • Posts: 12288
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #152 on: September 16, 2016, 12:53:11 pm »
... it is about accepting you have to abandon OSHW as a concept in practical usage.
If OSHW fails in practical usage, then one has to question the original premise and ask: "If it can't succeed in practice, what value was there ever in it?"


Quote
So even if you accept the OSHW logo is destined to become meaningless and you tolerate allowing incompletely open products to proliferate, where will it get you? You'll end up clinging to a logo without value....

Oh, the irony.



I had more to say, but I'm going to save my breath.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #153 on: September 16, 2016, 12:54:36 pm »
All I can see is the current problem flipped on it's head. Instead of solving the issue of not seeing at a glance what the not open product gives you, you will simply introduce the problem of people seeking an actual open product having to ferret throught the documentation to see what is missing. Is that what you want to call progress?

 :palm:
That's the current situation which is what I'm trying to improve here!
I'm done trying to explain it now, you obviously don't see the issue the way most seem to, and well, ok, that's fine.
Most people seem to understand the problem and get what I'm trying to do and support it, so that's a win.
 

Offline Brumby

  • Supporter
  • ****
  • Posts: 12288
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #154 on: September 16, 2016, 12:57:20 pm »
Thanks Dave  ....  that's the point I was typing when I came to the same conclusion as you.

I decided to walk away from another  |O
 

Offline wilfred

  • Super Contributor
  • ***
  • Posts: 1246
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #155 on: September 17, 2016, 02:52:36 am »
... it is about accepting you have to abandon OSHW as a concept in practical usage.
If OSHW fails in practical usage, then one has to question the original premise and ask: "If it can't succeed in practice, what value was there ever in it?"


Quote
So even if you accept the OSHW logo is destined to become meaningless and you tolerate allowing incompletely open products to proliferate, where will it get you? You'll end up clinging to a logo without value....

Oh, the irony.


Yes it IS ironic. THAT'S my point. That's exactly my point. No  :palm: no  |O needed. If OSHW can't succeed in practice why seek to continue with the use of the logo in some not open form in the hope that it encourages more people into OSHW? I strongly suggest everyone go back and REALLY LISTEN to what Dave is saying with particular regard to @5:00-@5:44. The video has a few inconsistencies and that 44 seconds is the only end result that I can see this "solution" seeking to address.
Go and listen to EEVBlog#195 @2:27-@2:37 https://youtu.be/I0HOgcbtmws?t=132


That there are so few people on the forum making a case either in favour or against what I am saying is the interesting issue. Dave's made at least two videos on it. Apparently it is a polarising issue in other forums why not here. Do people here really not care one way or the other or are they reluctant to voice their opinions for some reason? Is it FOGFP?

And if you really want to do what I did and educate yourself about the issue, read the definitions. I also watched a video put out by an acknowledged opinion leader in the community. I'm not making any of this up.

https://youtu.be/I0HOgcbtmws?t=424  Group Hug.

I'm just getting my opinion out there and I do try to add a little something new and avoid abusing anyone. I don't want to be  :palm: or  |O


« Last Edit: September 17, 2016, 02:56:11 am by wilfred »
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2317
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #156 on: February 23, 2018, 12:04:36 am »
What if a given board has no programmable elements, and so doesn't require any software or firmware (e.g., an analog circuit/audio amplifier). As a mathematician at heart, I'd consider it valid to include an "F" for firmware on the symbol, because:
  • Pedantically, all of the firmware that you need to get the PCB operating (i.e., the empty/null set) is available. (In the same way that evaluating AllOf([]) returns true in any decent programming language.)
  • Otherwise it would be impossible to have a fully decked-out gear symbol, even if I was doing absolutely everything possible and reasonable to make it maximally open-source, purely because my design is non-programmable.
Would people here agree that that is reasonable to include the F for this reason, or would people consider it deceptive? I strongly think it's perfectly reasonable to include the F, but maybe that's just me.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #157 on: February 23, 2018, 12:52:28 am »
What if a given board has no programmable elements, and so doesn't require any software or firmware (e.g., an analog circuit/audio amplifier). As a mathematician at heart, I'd consider it valid to include an "F" for firmware on the symbol, because:
  • Pedantically, all of the firmware that you need to get the PCB operating (i.e., the empty/null set) is available. (In the same way that evaluating AllOf([]) returns true in any decent programming language.)
  • Otherwise it would be impossible to have a fully decked-out gear symbol, even if I was doing absolutely everything possible and reasonable to make it maximally open-source, purely because my design is non-programmable.
Would people here agree that that is reasonable to include the F for this reason, or would people consider it deceptive? I strongly think it's perfectly reasonable to include the F, but maybe that's just me.

I wouldn't put the F.
I would trust that it's so obvious to people that there is no firmware in this product and hence why the F would be missing from the letters.
I can appreciate the desire to have a "fully decked out" gear symbol with all the letters when you are giving away everything in he design, and I realised this at the time but didn't really have a good solution for that scenario.
« Last Edit: February 23, 2018, 12:54:13 am by EEVblog »
 

Offline Brumby

  • Supporter
  • ****
  • Posts: 12288
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #158 on: February 23, 2018, 12:56:05 am »
I also wouldn't put the F in there.  It implies there IS something.

If anything, I would put a big dot in the corresponding cog - but anything used to signify there is no specific component should really be spelled out in the definition.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #159 on: February 23, 2018, 01:10:14 am »
I also wouldn't put the F in there.  It implies there IS something.
If anything, I would put a big dot in the corresponding cog - but anything used to signify there is no specific component should really be spelled out in the definition.

Yes, a dot or a dash or something that would imply N/A
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2317
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #160 on: February 23, 2018, 01:19:31 am »
I wouldn't put the F.
I would trust that it's so obvious to people that there is no firmware in this product and hence why the F would be missing from the letters.

As much as I would hope that people would be thinking that carefully and rigorously when looking at the symbol, I think you and I both know that the majority of people are going to interpret the symbol at a glance and mostly just look at its "density" -- I'm pretty sure only a small minority of people would connect all those dots.

I can appreciate the desire to have a "fully decked out" gear symbol with all the letters when you are giving away everything in he design, and I realised this at the time but didn't really have a good solution for that scenario.

Is clarifying the definition of F as I've suggested not a good solution? It's not even changing the definition, just clarifying what is currently a grey area. To make it crystal clear, I'm suggesting that the presence of F means "there is no closed-source firmware" (read: "no annoying roadblocks here!"). This definition is logically totally identical to "all firmware is open source"*, but the former makes it perfectly clear that F is perfectly allowable for an analog board -- and thereby preventing analog boards from being pretty arbitrarily disallowed from having fully decked out gear symbols. I know that you'd prefer that people not blindly demand fully decked-out symbols, but you sort of know that a lot of people are going to do so regardless, and to leave purely analog boards with the resulting marketing disadvantage as a result seems unfortunate.

* !AnyOf([a, b, c, ...]) === AllOf([!a, !b, !c, ...])

I also wouldn't put the F in there.  It implies there IS something.

This is a worrying implication -- it implies that the F only means "open source firmware is present". What if there are two programmable chips, one open source, the other (actually doing all the work) closed source? If we don't insist that the definition is "all applicable firmware is open source", then

If anything, I would put a big dot in the corresponding cog - but anything used to signify there is no specific component should really be spelled out in the definition.

This is a fine compromise, I would probably adopt this idea.
 

Offline rs20

  • Super Contributor
  • ***
  • Posts: 2317
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #161 on: February 23, 2018, 03:29:15 am »
Sorry for the double-post, but I was talking about this over lunch today and a colleague pointed out that by extending my logic, it would be legitimate to sell pineapples with Open Hardware Gear icons on the label with S, P and F letters on the basis that a pineapple has no closed source schematics, gerber files, or firmware/software. So perhaps a totally mathematically pure approach is not necessarily ideal.
 

Offline Brumby

  • Supporter
  • ****
  • Posts: 12288
  • Country: au
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #162 on: February 23, 2018, 03:50:33 pm »
LOL.  (Thanks, I needed that   :-+)
 

Offline Birger

  • Newbie
  • Posts: 1
  • Country: no
Re: EEVblog #921 - Open Source Hardware Problems Solved!
« Reply #163 on: March 13, 2018, 11:28:08 pm »
Hi,

I created a Font with all permutations of the OSHW EEV-Blog style icon, and though it would be a nice thing to share it with the community.
Included in the attached zip-file are a true type font (ttf) and a Open Type font (otf).
Makes it easy to add logo to PCB's etc..

Enjoy
/B
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf