> These posts bring to mind two long running thoughts, one directly > related to EMC and one not quite so related.
I want to make sure people are aware that these _are_ two distinct ideas and that one is not reliant on the other. I think it would be a bad idea for the two to be directly associated as there will eventually be conflicts of interest between the two entities. This doesn't mean that they can't help each other out when it is mutually advantageous. #1: > an entity so that we can accept and use contributions to the central > benefit of the project -- contributions of code, cash, or whatever. I think the board should decide if they want to form a fund/foundation or non-profit corporation, since they will be doing all of the work. (?) It is a fair amount of paperwork. The major goal here is to obtain a tax status for the EMC project - the board already serves the other functions. I dont think that distribution of money and hardware will be so very contentious as long as it is made clear from the start 1) whether said equipment is on loan from EMC and 2) whether a programmer is being paid to accomplish a specific task, with a bounty system for example. A bounty system would be useful for end-users in its own right. and entity #2: > a web mediated [decentralized] manufacturing business This is huge, and whoever gets there first is going to stay the default for a long time, for better or worse. This is due to "network effects" which you can read about here: http://en.wikipedia.org/wiki/Network_effect There is an amazing series of articles which vividly describe what I imagine as an ideal "open" distributed manufacturing community, and the steps it would take to get such a thing running. If you are interested in this sort of thing you should read them too: http://www.freesoftwaremagazine.com/articles/free_matter_economy http://www.freesoftwaremagazine.com/articles/free_matter_economy_2 ... http://www.freesoftwaremagazine.com/articles/free_matter_economy_7 The biggest roadblock in this endeavor will probably be software compatibility. In order for our "network" to be useful to outsiders we have to be able to read the drawings they send to us. I spent a few weeks getting a feel for the feasibility of writing translation libraries for STEP/ISO-10303, the official CAD/CIM/everything exchange format. Unfortunately it seems that the perverse incentives inherent in the standards creation process make it extremely hard to read the documentation. I mean it's really hard to actually read it, once you've paid the $15k or so to actually get the documents. (You can get an idea by looking at the draft standards.) This is done so the people who wrote the standards get to keep their jobs as the people who read and explain the standards to you in plain english. There are some open source projects available such as NIST's expresso and express-engine which make it more like reverse engineering rather than reading legalese, and this should appeal to software developers. Maybe this should be moved into its own thread. -fenn ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
