I'll sign the petition.  There's got to be a ton of customers like me using MySQL.

I will miss the WAR distribution model as well.  Would it really be difficult to make the war available, and just not provide installation support for customers using it?  I agree that there can be some pain involved getting Clearspace / SBS set up and fine tuned the first time, and the RPM will probably work better for many new customers, but your existing customers have already gone through that pain.  Besides, typically your support team considers issues involving installation, application server configuration or database to be outside of scope anyway.  (don't get me wrong - in most other respects the support team has been stellar in my experience)

The MySQL support will be the real sticking point, though.  The impact to me will involve moving from a shared MySQL DB cluster managed by my IT team to a new server that I will have to buy, install, manage, and backup myself.

In my experience, I had seen these rpm (or other dist. formats), work is , if you package Clearspace, put it in an appliance and begin selling Jive/Clearspace appliances, then in fact you provide a admin interface, where new rpms/versions can be installed.  Barring that, this is a step back.  I would much prefer the standalone distribution, as the cost of the bundled app server (in terms of space) is quite minimum and I can rely on Jive to ship the appropriate container version with the cleaspace version.  While at this, if you could ship a version with Jetty as the container (which I learnt is used internally at jive), would be even better.

Best Regards,

-senthil

Another customer sorry that there is no WAR distribution.  I'll probably try moving the application directory onto our existing application server and running it there anyhow.  Well, that is once I have time to set up Postgres since this won't be able to go on the well-functioning production MySQL system.  This has more of a cost than developers may realize; aside from additional hardware, it's a substantially bigger endeavor when one needs to set up managed configuration and re-provisioning, metrics, paging, disaster recovery scenarios, backup procedures, and administration documentation...  And yet, the costs of moving to a dedicated appserver and JVM running out of /usr/local is much more frustrating than setting up PostgreSQL because it's creating a legacy subsystem: lack of SELinux support, no distro-based security upgrades for the toolchain, difficulty integrating with managed configuration, and the one-off overhead for technicians to find things (like management scripts) in non-standard places.

I agree one decision point for us was SQL 2005 support.

What free services are you offering to help existing customers move to the new system requirements?

Hey everyone, please keep the opinions coming. I talked with Bill yesterday on the phone and it is clear to me that they really need to have this level of feedback. While I fully appreciate their reasons for trying to standardize on a platform, the reality of the market is that each of Jive's customers are going to have different requirements for what they can support. Jive needs to listen to their customer base.

Asking a MySQL (or db2 or SQL2005) shop to have to invest in the infrastructure to support another database is never going to happen in this economic market. There is no way I can go to the head of the company and tell him that I need to allocate more hardware, support contracts and dba's just to support installing SBS on Postgres. It is far less expensive to just find another vendor making similar software (and yes, they are out there).

If enough customers complain loudly enough, Jive will be forced to back down and find other ways to improve their system without requiring a specific database vendor. I'm a software engineer who has developed absurdly high traffic J2EE applications that run extremely well on top of MySQL. I know it can be done, it just takes a bit of effort.

Hi Eric,

I wanted to address several of these points directly and hopefully clarify how you aren't restricted by the platform.

We're fully compatible with SElinux, you can configure any policies you like for the platform and we'd be happy to help identify where it makes sense to create those policies.

We rely almost entirely on the distro-based tool chains, one of the reasons it takes extra time to support non-RPM based distros like Debian which locate system tools like awk in different directories. Likewise, we rely on distro libraires for lower level encryption (OpenSSL for example) so we're directly dependent on the standard patch cycles for the major enterprise distros. We do ship a platform-optimized Apache server, mainly because we wanted to be able to take advantage of bug fixes faster than the distros can produce blessed packages, but you're under no obligation to use it, likewise for the PostgreSQL server. Many of the platform services are there because we can optimize them based on our customer's experiences, we don't however, force you to use our all of the platform-managed components.

We follow LSB standard init-script convention allowing you to easily probe the status of each service on the platform from conventional monitoring tools. Likewise, we include various configuration options for SNMP monitoring as well as JMX-level monitoring of the application.

As mentioned above, we do locate the core management functionality in standard locations. We also provide a thorough runbook for system administrators that describe the most common system admin tasks. Lastly, we provide a set of tools to help when engaging support such as thread dump snapshots, system information gathering and log file aggregation. As a former SA, I think the tooling will be well received and I'd love to hear feedback on how we can improve it.

Bill, thanks for weighing in.  While the decision to move towards packaged distributions makes sense, it seems a bit of a bold leap of faith that every organization can drop everything to move to Linux + one of two DB implementations.  The standard Windows + SQL server shops (no doubt a reasonable percentage of total setups out there) won't in many cases be able to drop everything at the tip of a hat - the required skill set to run and maintain may or may not be there.  Particularly in a weak economy where every dollar spent is scrutinized, it's difficult to justify additional infrastructure / manpower / expertise solely because we're upgrading versions.

it's not like I don't trust you to tune Tomcat, but I don't

So it's exactly like you don't trust them to tune Tomcat

Where is a fourm to discuss SBS? For instance, I don't see yet how you upgrade your existing CS instance to SBS......

When I first saw the packaging for SBS, I was torn between thinking it was cool that I didn't have to set anything else up, and that it's now more of a pain to set up on EC2.  I think I have a strategy devised to make sure my organization's data stays on persistent storage (Amazon EBS volumes) while at the same time making it easy to migrate to a new server instance if the need arises.

I am concerned about some of the assumptions that are made in some of the scripts.  For example, the database backup script is hardcoded to connect to localhost, port 5432, etc.  It also assumes you always want to keep 30 days of full backups around.  It would be nice if these options were customizable in external properties/config files.  I'm afraid that if I make changes to these files, that if/when I upgrade to a newer version of the SBS RPM, it will be difficult to make sure I get to keep my changes while getting whatever updates Jive makes to the scripts.

Dittos about the .war, Windows & SQL 2005 concerns from a brand new customer. We just bought into 2.5.6 about a month ago. It's a big hit and I'm encouraged by the 3.0 developments, particularly around reporting. I'd love to start piloting it and testing the new features. However, there's ZERO chance we're going to deploy a bundled app, change an OS, and change our database system. It ain't happening. Period.

I really hope this is just the first (mis)step of the rollout and that there's a significant change very soon in direction for these items as well as the pricing model, or we will not be a customer very long.

Hope this changes too.  We need war deployment.  I like configing my app server 1x and not having Jive change things every upgrade.  The war was simple and worked.  If supporting of platforms is a problem then Jive should do the following:

Linux:  support only RH Enterprise or Suse (no official support for others) - although this shouldn't matter IMO if we are talking about supporting the app server

Windows: support Server OSes only

You should retain the current database support or at minimum support the major RMDBs and one "free" one : SQL Server, DB2, Oracle and Postgres.  If you halt support for MySQL (which we run) then provide a migration tool to get us to one of the supported ones.  In our case we would likely move to SQL Server since we have expertise there.

I hope this is just due to the fact that 3.x is new and support for current databases and OSs (or a reasonable subset) will happen.  If not we will have to stay on 2.5.x until it is dead and then look elsewhere if it came to that

I'd love to hear from Bill Lynch whether this outcry of displeasure has influenced / changed his on the decision to no longer support certain infrastructures.

Another annoyed customer here.

The war file was useful and easy to use for dev and production.  I don't want to have to run a bundled thing everytime I get an upgrade, and I already have tomcat etc on my mahine.

And as for dropping support for SQL Server. Scandalous bascially!  There is NO way we are moving to Oracle, and why would we want to. And there is no way the systems guys are going to want to start supporting another DB system.

We have a nice SQL server cluster already.  I agree with the comments above somewhere, you should/must maintain support for the major RMDBs.  SQL server is part of the infrastructure of the projects (of which we have two, internal and external). And was costed and purchased as such!

Looks like 'upgrading' to BS 3 will be just as much hassle as moving to another product....!

Nothing that hasn't been said already, but I will register my $0.02 anyway.  Not supporting Ubuntu is problematic for me.  It causes me to have to purchase OS license/support that I did not have to before, and I know that I am not the only one out there using it.  Not supporting MySQL is problematic as that architecture is in place and working and that is where our expertise lies.  I am a small company with limited resources.  I am 5-months into adoption and rollout of clearspace, and you yank the rug out from under me.  Now, I have to decide to stay, or roll back to SharePoint.

I have to admit, these developments have given me pause on pulling the trigger on Clearspace. We've deployed the demo in-house for a few months. So far, the response has been outstanding. We just purchased the hardware and database to support our Clearspace purchase. You can imagine my surprise when I learned that Windows Server and SQL Server isn't supported - after I purchased the approriate system and licenses.

Base on the feedback on this thread I was shocked to read that Jive really did market research before making this change.

To be fair to Jive they did support Oracle and PostgreSQL before this move.  However I agree this move is very Oracle centered.  Especially considering that PostgreSQL is very Oracle like in nature.  Tomcat is great and all, but I'm going to guess that large enterprises that have CS were running a enterprise app server like JBoss, Websphere.  Those two just disappeared.  Also I'm not sure how you can expect to compete with Sharepoint when you remove Windows/SQL Server support - now all those Windows shops will never look at Jive again.  How can Jive support Oracle as the only commericial DB?  SQL Server is cheaper and a better alternative for those that want a enterprise database system.  I'd argue DB2 too, but I do understand it is probably a smaller market than Oracle or SQL Server.  Very strange.  Bill did email me and asked to discuss this change with him.  When I get a chance this week I'll probably do this.  My problem is that I now not only have to upgrade from my Ubuntu, Tomcat, MySQL platform to something else.  I need to move to a database that we have NO internal knowledge on how to support, maintain, install etc.  I also have to buy RH Ent as well and deal with rpms instead of the simple war deploy in Tomcat.  If MySQL was pulled, I would have probably opted SQL Server since we have that expertise in-house - however that is not an option.  Oracle is out for sure - too damn expensive.  PostgreSQL is an unknown for us.  This is a tough situation.  In the best of circumstances (if we accept the route Jive is on) we now have to spend time upgrading not only our database, but our operating system as well.  This means a new server (likely), new routines for DR/backup, new tools to manage the new database, spend time gaining skillset on a new database, etc etc etc.  Overall not what I expected at all...   I also want to make sure that the next surprise isn't pricing.  Supporting an Oracle only infrastructure tells me it might if they are targeting Oracle shops (which means $$).  I see the word enterprise used all over the new literature - I hope this doesnt mean that small/medium shops are getting priced out.  If prices are expected to go up, this would be really bad.

Sharepoint vs. Clearspace did make only very little sense, anyhow it was nice to read that one could use CS as an alternative.

Dropping support for some databases makes sense if one does need very database specific features but that's likely not the case. Testing and certifying two instead of six databases makes releases much more easy. Especially as some databases have "8-bit" limitations like restricted blob size, index lenght, character support, ... so one needs to be careful during the design and coding phase. Other vendors of J2EE applications show that this is possible.

J2EE/JSR-154 (war file) is a standard and de-supporting standards is somewhat innovative, isn't it?

Another frustrated customer.  We are a Windows + Oracle shop and this is not changeable.  Any form of Linux is not an option regardless of whether it is a "better" system or not.  I realize Jive may have reasons for dropping support for Windows but I'm really, really disappointed that this was communicated much better.  I do not have the luxury of checking the Jive blog daily but I do feel that I check in enough that if this had clearly expressed, I would have picked up on it.  We have not only just renewed our license but also increased the number of licenses as the system is really starting to gain momentum and now I find I cannot even upgrade to the newest version and I cannot even at least download the 2.5.9 version so that I may upgrade.  I really feel that this drastic change should have been communicated much better to existing customers especially those who were just about to renew their licenses.  I have been really impressed with Jive's software and service until....now.  Very frustrated...

Looked at the contents of the RPM, packaging python, visualvm, postgres, just to name a few, packaging guidelines and best practices for dependency management are not maintained.  Also, I see threads complaining about hard dependencies, strengthening my conviction that this is an appliance solution.  But with all this outcry from customers, yet have not heard from Jive management on any guidance on decisions going forward.  For me personally, Jive/Clearspace had become lot less interesting. *sigh*

I just recommended against IBM and for Clearspace because IBM makes you install so much other software with their product and only allows you to run on their server. Boy, do I look like a fool!

From our discussions with Bill, it seems that Jive is not going to add support for any platforms outside of what is already listed. Even though we are an Oracle shop, the fact that Jive is using Tomcat rather then other Enterprise class application server is really troublesome. Like many others, we have invested time, money and effort to design our infrastructure to meet all our requirments and we ensure all application we use fit nicely within that infrastructure stack. With this recent development, it seems that Clearspace Community 2.5.x might be the end of the line for our continued support of Jive and we have to begin looking for another application that will work.

Jive's intentions are good in that they want to provide an applicance that has been optimized for best results, however limiting that to Tomcat only is a bad decision. Just look at all the feedback from the customers.

Generally speaking, most companies have already optimized their environments based on their load/stress testing results, as we have. Perhaps Jive should consider simply providing us with the deployment package alone with a disclosure stating that this application has been designed for optimal performance on Tomcat. Issues relating to performance tweaking on the application level is the responsibility of the client as each environment setup is different.

These would hopefully ease the pain a lot of us are feeling at this moment.

Bill, any feedback on this?

Sigh, I think you've never been exposed to a conservative, adverse-to-change corporate IT culture such as ours.  You seem to have the impression that one can just stroll into the data center, install the software, and walk out -- "no thanks guys, I've got it."  Maybe our infrastructure department is uniquely recalcitrant, but I doubt it.  Can someone tell me the EOL for Clearspace?

wow, this got to be some regional,one city based, savings bank , I know MS, JP and BOC and many other major bans  do not work like that at all...

try to request one port to be opened on on of them and then wait 3 month  for it to go through change control ,  thats the way 99% high corporate ITs work. you cants just call up a Server room and have a PostGre running there by the end of the day

another unhappy customer adding his name to this list. Windows shop running SQL server. I'd suggest trying to beef up the "eval.exe" and support JBDC driver.

Working at a state institution, and end of the year spending coming up, I was planning on recomending clearspace. So much for that. It's a shame, I really liked your product.

Bill, although it's great SQL Server is supported, it implies that someone would need a Windows machine running the DB, and then a seperate machine to run the web-app off Linux.  While possible for some shops, it's not realistic for many (such as it sounds like in Kris').  Considering that you've indirectly supporting windows on the backend via SQL Server (no Unix-based version exists), will you consider adding Windows based support for the web-app in the future?

Is the Eval.exe even close to a fully working version? How long did that installer take to make? I don't even see why you bother to spend time to make that, yet not even going to bother with windows.

However, I tried installing it last night, but it gace me the Postgres with no option to use my old database. Then I started it up and its "Loading" ( checked it in the morning (10 hrs later) and it is still loading....

Bill,

You seem to be the only person at Jive replying to customers. Support isn't replying, neither is Megan who writes the new release notes blog posts. Trying to find out what build (Clearspace 2.5.10 doesn't seem to be it) will have the fix for a clustering issue reported on Jira CS-11531. We've been waiting since February 2nd. We were told 2.5.8, then 2.5.9... now 2.5.10 is out and it doesn't have the fix. Does 3.0 have the fix?