The Farm Hack River of Activity

You seem to have a pretty clear idea of what a "Template Tool" would look like. You could pick some trivial, perhaps hilarious, example and do it up!

Welcome to Farm Hack! I have seen some amazing stuff done with all wooden wheelbarrows using laminates and some with steam bending. I have seen some bent aluminum tubing frames stiffened with light weight plywood as well. For attaching to the bike, I would look to the bike forums - I am sure it has been well explored.

Would it be useful to have a glossary for this forum?

Because Farm Hack is interdisciplinary by nature, keeping everyone on the same page may require some explaining. There could be links to wikipedia pages or other sources and audience-specific entries about farming and design vocabulary.

Oh nice - I missed Saturday and this seems like a really cool device!

I came across this picture which I felt reinforced my reasoning above. The person in that picture obviously didn't have the alternative we do back in his time. I think Louis C.K. illustrates how artists today can create a business model today that circumvents the industry and one of the key features was the lack of DRM in his downloadable product. While that's not quite open-source, it's VERY progressive for the industry and makes a lot of customers happy since they feel like they are given the ownership they are entitled to when they buy something.

Anyway, I was just trying to illustrate my point of how important it is to pick your battles. By not caring about people pirating his product, Louis CK was able to cut out middle men, sell his product more cheaply, and make more money then he would have otherwise. Wins all around!

The stack exchange model seems like a pretty good starting point. It would definitely keep the site from becoming a collection of abandoned projects which in turn may make it less credible as a professional outlet for ideas. Conversely the premise of a lifespan on tools may keep some new users from using the site and disenfranchise users who may have listed a new tool idea which did not proliferate within the community and was accordingly removed. In short, I’d say that the implemented system should be much more sensitive than stack exchange’s. Removing someone's question (like in stack exchange) isn't too big of a deal, but the removal of a tool, its documentation, and forum discussion is much more important, but the core basics can really help keep things organized. The biggest point would be to make sure the metrics were reasonable; it’s better to have a wait time before deletion that is slightly longer than might seem necessary than one that is too short.

I would say that communication would also be vital for such a system to work effectively. Users would need to know that posted tools that do not appear to progress may be removed, so that way there are no surprises. In this instance surprises are never good. Perhaps something like a FAQ or Guide could be implemented to outline the process of adding and editing tools which would also include necessary details about site deletion. Furthermore, it may also be a good idea to send a notification to any user who has a tool which may be deleted soon. Keeping the users informed is vital to maintaining the integrity of the site.

Another thing which came to my mind was that projects at different stages might need different metrics for evaluating. A tool at concept or at prototype level which does not appear to be growing over X amount of time, like you mentioned, may be a candidate for removal. Conversely, tools which have seen more development and are more stable would probably not follow the same metric. For instance, a tool which has become established with large amounts of documentation and has reached the DIY or even more so commercial product level, it would be a bad idea to remove that tool from the site if the amount of contributions on it suddenly slows down or stops for some time. The worst case scenario would be to compromise the reliability of the site by removing tool pages which people may be relying on.

I am not sure how viable (or accurate) any of these concerns or ideas are, but just some food for thought :)

i choose the public domain. it is to me the most sincere expression of openness and admission that all good ideas are old ideas. the simple reality is that once set into the wind, the seeds will do as they please! replicate mutate iterate.

Inspired by Louis's comment that got mangled from a text filter, I enabled am more flexible text filter AND enabled user's to edit their own comments. Maybe in the future we'll lock this down but for now it's a nuisance especially while preview comment isn't working.

Haha amazing, so meta. This one is definitely influenced by my experience in the Drupal issue queues where the original text is editable by anyone and the comments are permanent. Having the original text editable allows you to update the thread AT THE TOP so when the thread gets into the triple digits then someone can edit the original text to summarize the discussion. In the Drupal community we suffer from conversations that will start up again like 50 times because no one has the time to read the whole conversation.

As for the needing to go back and edit in general, I agree, I'm the same way and I try to use the preview button as much as possible to force myself to reread things. Unfortunately there is something funny with the preview mode right now. See http://dev.farmhack.gotpantheon.com/forums/clicking-preview-button-forum-topics-results-error.

I also see a need to keep comments permanent for accountability. I think it keeps people civil. I might be wrong though.

My takeaway from reading the public labs site was the following:

CC Share-alike has one potential weakness: people who build off of someone's original plans can see their work become closed, since the originator of the project can change his or her mind about licensing. Thus, it forces people downstream to make their development open while also allowing the potential for someone upstream to patent and close the project, taking downstream developers contributions along with it. CERN does not allow an upstream developer to do so.

My final position is that CERN is the way to go. Part of me did feel like the ability to close a project was a useful tool to use against corporations who may want to use my work, but further thought made me realize that that benefit would probably not pan out in practice.

If a corporation really wanted to keep using my work, they no doubt will find a way; waging patent war is not the battle I intend on fighting. Meanwhile, the cost of this ability is that downstream users are at-risk of my whims and this discourages their own development of a tool that I originated. In short, the benefit of being able to fight a battle that I don't want to fight isn't worth the cost of discouraging collaboration.