There has been a lot of dialog about the future direction of unRAID, both interms of GUI and additional features.  I tried to come up with a poll to capture people's opinions.

 

I hope this input is useful to Tom.

 

Here is a detailed description of each of the items above ...

 

1. GENERAL PURPOSE HOME SERVER:  I think that the aesthetics of the existing GUI are adequate for the base product.  Tom should make only a minimal investment in APIs and adding components (like lighttphd Web Server) to make developing alternate GUIs more achievable by the community.  (Tom may or may not “adopt” and support the community GUI at some point in the future).  Tom’s main focus should be on expanding unRAID’s functions beyond pure file/media storage server, which might include serving media (ps3media), VPN remote access, playing audio, hosting VMs, and other non-file server related functions available in competing products.

 

2. THE BEST MEDIA STORAGE SERVER:  Minimal involvement in GUI similar to #1.  But in this option, Tom’s main focus should be on expanding and refining the core unRAID features.  unRAID should more gracefully guide users through failure scenarios, have extensive protections against having a user shoot themselves in the foot, allow multiple arrays to be defined, more disks per array, 2 parity disks, etc.

 

3. OUTSTANDING GUI WITH (DELAYED) GENERAL PURPOSE FEATURES:  I think that the aesthetics of the existing GUI is lousy, and think that Tom should take the leadership is designing a new GUI as a very high priority.  The new GUI should define a GUI plug in architecture and make accessible, via the Web GUI, features and functions in Linux (e.g. rsync) to a non-Unix audience.  Community projects should “plug into” the supported GUI, and not attempt to replace it.  Only after that, Tom’s focus should be similar to #1 above.

 

4. OUTSTANDING GUI WITH (DELAYED) MEDIA STORAGE SERVER FEATURES:  Similar to #3 in terms of approach to GUI.  After this, Tom’s focus should be on core unRAID features as described in #2 above.

 

You need a third dimension to the matrix... an open API.

 

With the open API, development of other features, and GUI, can proceed in parallel (and multithreaded ) to Tom working on core features.

 

I'd chose the API first, then #2.

You need a third dimension to the matrix... an open API.

 

With the open API, development of other features, and GUI, can proceed in parallel (and multithreaded ) to Tom working on core features.

 

I'd chose the API first, then #2.

 

I'm in agreement here also. 

You need a third dimension to the matrix... an open API.

 

With the open API, development of other features, and GUI, can proceed in parallel (and multithreaded ) to Tom working on core features.

 

I'd chose the API first, then #2.

 

#1 and #2 both include an open API to support community GUI development.

I think that anyone interested in answering the poll has had an opportunity to do so.  I thought I would summarize the results and close this out.

 

The goal here was to give Tom a (hopefully) unbiased view of community sentiments in March of 2009.  We are a fickle bunch, and 6 months from now a new poll might be created to capture sentiments at that time.

 

More than 86% of the respondants believe that LimeTech’s focus (excluding the GUI issue addressed below) should be on improving and expanding the core file storage and recoverability features of unRAID.  Less than 13% feel that unRAID should focus on non-storage enhancements to compete with more “general purpose” home servers in the marketplace.

 

More than 77% of the people responding feel that LimeTech should focus on building open APIs that will support the development of a “community GUI” (perceived to be a relatively small task), and should then quickly get to implementing enhancements (as described above).  They feel that Tom should at least consider "adopting" the community GUI once it reached a level of maturity.  Less than 23% feel that the LimeTech GUI is “lousy.”  They feel that LimeTech should, at its highest priority, redevelop the GUI (perceived to be a relatively large task); and only then focus on core enhancements (as described above).  Further, this group felt that community development should be confined to developing plugins that follow the GUI conventions set by “official” GUI.

 

Hope I said this in an unbiased way.  That was my goal.  Thanks for all that participated!