If the development just completely stopped, I have no doubts that the community has the needed experience and skill-sets to implement their own 'emhttp'-like management console. That's all that's really missing.

 

Getting the md kernel code to function properly against newer kernels isn't that difficult, even I managed going from 2.6.32.x to 2.6.35.x then from 2.6.36.x to 2.6.37.x in an evening. However the issues would likely be in performance regressions (as LimeTech mentioned on the absolute newest kernel 2.6.38.x or 2.6.39.x). Those are the sort that take additional time to track through the kernel changesets to determine exactly what the new(ly) suggested methodology is that should be used.

 

Myself and others have managed to get unRAID running on a full current Slackware distro and even on a full current Slackware 64-bit distro. That alone right there takes care of 95% of your potential future controller card and chipset issues. Others have also created their own unRAID mini-distro with additional bundled enhancements (updated bzroot and bzimage).

 

To echo what Brit and other have implied. The important part of unRAID is GPL. What you are paying for in support, updates, the kudos of a Linux commercial project that actually works in the real world and emHTTP (i.e. the front end). It has been stated before categorically that if the project died that Limetech would make sure it could keep going in an open source way. Even if this doesnt happen via Limetech a couple of the Ubers/Staff here have said that a new open source emHTTP would be delivered.

 

There is no such thing as no risk but this is not one to worry about.

To echo what Brit and other have implied. The important part of unRAID is GPL. What you are paying for in support, updates, the kudos of a Linux commercial project that actually works in the real world and emHTTP (i.e. the front end). It has been stated before categorically that if the project died that Limetech would make sure it could keep going in an open source way. Even if this doesnt happen via Limetech a couple of the Ubers/Staff here have said that a new open source emHTTP would be delivered.

 

There is no such thing as no risk but this is not one to worry about.

Don't forget the "user-share" file system. It too would need to be reverse-engineered and re-created.    I'm reasonably certain most here would not want to undermine lime-tech's business. 

 

I certainly hope Tom lives a long life as the unRAID developer, even if he does not get rich on unRAID. 

As others have said. your current system will continue to run just 'as is'.  If the code went into a limited 'maintenance only' phase, then you would have to consider the risks of using unRAID on a new build.  Most existing hardware could replaced with devices of suitable similar function for the likely life-span of any hardware build.

 

The biggest problem would be the failure of a registered usb key.  Hopefully, the code deposited in escrow would enable the skilled amongst us to manage the licensing system.

Yea, it would run "as-is" but support for larger drives/drivers/technology wouldn't be there. The hardware/technology world is moving a lot faster than unRAID is. If unRAID can't keep up with what is at least current, I'd think twice before a big upgrade. I use a good program called Alt.binz. You don't pay for it, you would give a small donation and then be able to use the latest release. With something like that I do not expect many changes/updates because of the way their business model was setup. With unRAID being that I paid for it, do expect a certain amount of support and updates. Keeping my fingers crossed the unRAID train keeps rolling on!!

 

 

The only real risk is Limetech LLC being purchased. That would cause alot of the previous verbal agreements to be nul invoid. Even if that happened there is a good chance the project would get bigger and worst case with some work it could be replaced. Compared to almost any other project the risks are low IMHO. Certainly not something to sway any negative purchasing decisions... in fact look at rationally it makes unRAID more attractive not less.

The only real risk is Limetech LLC being purchased.

 

I have no wish to pry into Tom's affairs and how he operates his business.  However, I strongly suspect that he does not earn a living wage from unRAID alone.  I don't know whether Limetech exists solely for the purposes of developing/selling unRAID.  Perhaps Limetech does have activities which would make it an attractive target for a bid - a bid which Tom would be tempted to accept.

 

I do wonder whether it is somewhat akin to the business I ran while I was still in UK - an IT consultancy with some prestigious customers.  When I developed some software to meet my own personal requirements, I decided that it could be marketed to allow me to recover some of the investment in terms of time and effort.

 

No - without wishing Tom any misfortune, I suspect that the biggest threat to unRAID would be if Tom met an untimely death or disablement.  Perhaps we should all contribute to a personal insurance on Tom - the proceeds of which would be used to re-establish the on-going development of unRAID!

What a morbid thread!

 

I too can't see how Tom is making any money, but as long as he's developing then I'm happy. Tom has already said there's a contingency in place, and considering how he treats his users (very generously) I'd say it'd be in good hands.

Someone who has Tom's ear can you ask him to maybe update the main Lime Tech home page with at least some recent news? The indicated news right on the home page is from January. I directed a couple co-workers to unRAID and they got turned off by the non updated home page. I told them not to worry about that and stick with the forums only. Don't let the home page be a decision.

Someone who has Tom's ear can you ask him to maybe update the main Lime Tech home page with at least some recent news? The indicated news right on the home page is from January. I directed a couple co-workers to unRAID and they got turned off by the non updated home page. I told them not to worry about that and stick with the forums only. Don't let the home page be a decision.

 

Maybe we should open up the Lime-tech webpage so the mods can keep it current. 

Locking this thread.

 

Not that anything said caused it, but this thread started as a question and is quickly turning into a negative thread. We all are here to help each other regardless on how large Limetech Staff is or isn't. Its very obvious we are all vested and will continue to support the project in any shape or form we can.

 

If somebody believes it was locked unfairly please feel free to contact one of the moderators here and I'm sure they will if the need be.

Did some Soul Searching and realized I might of pulled the lock trigger a bit faster than I should. 

 

Thread unlocked.

I would definitely donate or do whatever I can if it was needed to help. If I didn't believe in the project I wouldn't have 16TB of data being used in an unRAID server. I'm not syncing or anything like that. I'm just relying on that one hard drive will fail at a time.

 

 

You are all worrying about nothing.

 

First, Tom does code escrow.

 

Second, there are several people here who can reverse engineer the functionality of emhttp.  We could have a working replacement in a week, sans registration... it would be short a few bells and whistles, and run with a real webserver and not the built-in http engine, but it would work.  Then over time the bells and whistles would flesh it out.

 

I've come on on a few projects like that in the past, where a sole dev was lost, along with some or all the source.  In many cases, the replacement was better than the original, since many times long-revised code has some deadwood and anchors holding it back, due to the revision process and adding on things that were not filly anticipated in the beginning.

 

I remember one that was perl and flatfile DBs, that had to be redone in php and mySQL.  We intentionally threw away the original code and started from scratch, so none of the anchors were carried forward.