Saturday, November 14, 2009

59> A Milestone and a Call to Arms

Many of you who have followed this site, which is now nearly eighteen months old, may be wondering about this “Open-Source” thing. Obviously just showing my own design ideas isn’t really open-source. At the same time, I started at a readership of zero. I had to achieve some visibility. There has always been a compromise between what would grow the site and what would populate it with engineers. Anyway I have decided that it is time to take this project to the next level.

For several months now, this site has had the capability of enabling not just the sharing of my designs and ideas but of yours as well. Unfortunately, I’ve had a lot of problems figuring out what I was doing so I could clearly explain it to you, the readers and potential users. The problem was compounded because it really takes more than one computer and IP address to experiment with a system like this. Luckily I have recently found the time to at least partially figure it out, so, without further delay…HERE IT IS! (Corks pop and the sounds of noisemakers ensue)

First, if you want to not just look at my designs but play with them like you had drawn them yourself, I have posted the address of a download site to the right. (You will currently need Google’s free 3D modeling program “SketchUp”, although later the site may be populated with many other file types.)

Furthermore, they may be improved and resubmitted, or you can share your own projects. PRT control software would be nice!

It works like this. Google holds the files. We each have folders, which, when updated from the Google site, will have identical contents. Each of us can then open any project file in the folder and work on it. When we want to quit, we simply close the file in the usual way. It can then be either submitted to be shared, or reverted. If it is submitted, a text box will open where you will hopefully describe your work, so the rest of us do not get confused. You can also share your own project files by putting them in the folder and submitting them. Another option is to branch a project by changing a file and submitting it under a new name.

This is all done by a magic little helper program. (SVN) I am using one called Tortoise.
It runs in the background and you access it by right-clicking the file or folder to get at its menus. It places little badges on the file icons in your folder – blue for one you just added, red for one you just modified, and green for the shared version that Google is holding. (A note on SVN jargon - Submitting a file is called “committing”. Your folder is called a “local repository”.)
So anyway, by right clicking, you can ADD, REVERT, COMMIT, (individual files) or UPDATE. (The folder)

To get started, just go to the OpenPRT site, and go to “downloads” to get a MS Word doc with step-by-step instructions. By the way, those files under “Downloads” are already old. It’s best to go to “Source” > browse> svn>trunk to get the whole up-to-date library. Right now all I have is mostly the models that I used for illustrations for this blog. At some point we will need to start designing in earnest, from scratch. Note that there is even a wiki. This might just become the most important part of the site because wikis are great at linking related subjects. The design of any part of a PRT system inherently relates to many other parts, as well as to statements of design requirements, such as safety, cost, modularity, replacement/repair cycles, etc. With a wiki, every part can have it’s own page, and everyone can contribute and edit. This part-by-part discussion can then be put into 3D and worked on via the SVN. At the present the wiki is like a big unopened box. I invite you to create the first page.

It has become clear to me over the past months that I will need a lot of help with all of this. I think it is worth starting discussions about how to incorporate volunteers and create some kind of formal administrative structure. Wikis, SVN, managing open source projects…. None of this is really up my alley. I really hope we can get some good discussions going in the comment section this time. I really could use some guidance as to how to make this thing unfold.

1 comment:

Ryan Baker said...

Dan, you may want to put some more thought into the licensing. Presently you have the site up listing it a GNU v2.

GNU has a number of clauses which are at the very least confusing as to how they would be applicable to things other than software.

In the software world, there are two main types of open-source licenses (though many more than two actual licenses with smaller variations).

The first type, exemplified by GPL, which basically says, that if anyone takes the base code, and makes additions to it, they need to make those additions public and free.

The second type, exemplified by BSD, doesn't include this "copy-left" clause and allows any type of reuse.

The implications of the copy-left clause are only loosely understood in the software world, and would definitely be murkier outside of it. For example, it's generally considered acceptable to modify GPL code and not make it public if you never give the code to anyone else. You could run a website using modified or extended GPL software and charge for access to the website, but you couldn't sell someone your software to run their own site, you either need to keep it completely private, or completely public, there is no middle ground once you have used a single GPL line of code.

My suggestion to you therefore, is to consider two things. First, for the non-code elements, I'd suggest you consider BSD. A GPL license would insure that no one could take the software provided here, clean it up and then sell a license to it to a company with more mechanical and implementation experience. Anyone could modify the software, but wouldn't be able to utilize it without building and operating their own PRT system. If they try to work with another partner then they would be required to make their modifications public, which would probably harm their ability to negotiate with said partner.

To me, that's a bad situation because it encourages a more monolithic organization of the companies involved.

At the very least use Lesser GPL instead of GPL.

For non-code elements, I'd also suggest something other than GPL (noting that it may not even be valid for non-software). BSD may work here, or maybe Creative Commons. Whatever you do, do some research and consider the implications because once you start accumulating submissions, you cannot change your mind.

I think what should be encouraged is a system where the "glue" elements are shared, which enables much smaller organizations to participate in the industry. For example, if there is a standard protocol for communicating between vehicle and intersection controller then one company could focus on high quality intersection software while the other focuses on vehicle software. Specs are nice, but the ultimate spec is always working code, and BSD code would allow this common communication code to be used by both companies.