Not that Compiere isn't doing well on SF :-) but the Oracle dependency seems like a major adoption-killer for a lot of VARs/businesses. I've scoured the forum for a clear direction on this and can now only guess at what it is.
Is there a definitive/clear roadmap for providing a Postgres alternative to Oracle?
If so, it might be a good idea to post it on the compiere.org site. Of the 400K plus downloads from SF (amazing!), my guess is that 352.3K (approx.) would be interested in this :-)
This is typically my situation.
I thought Compiere was targetting SMB,
but a business that can afford the admin
and the burden that come with Oracle is
usually neither small nor medium... :-((
Just my 2 cents
Well, it depends. Compiere claims to handle business needs for enterprises up to some 50 million dollar turnover which is quite a bit, but still classifies as medium by usual standards.
There's a page on www.compiere.org where they ask for funding that would be required to complete the port, and provide some history about how they proceeded so far. It's interesting to read... TANSTAAFL.
They should not do a port for PostgreSQL but rather do one for SAPDB...(multi-platform builds).
They should invest their own time & money to do the ports and recoup the costs from service contracts which, I for one, would be happy to have my company shell out the $1800/yr. for so we can rid ourselves of Macola.
Just My $0.02
Their web page (worth to read!) mentions that they are underway porting to JBOSS and thus aquiring total data base independence. If they succeed, any one will no longer have a specific data base engine rammed down their throats. While I'm not too deep in the trenches with Java related stuff, focussing on middleware and being able to switch data base backends in an instant is something I consider to be a very good idea if it can reasonably be done. Locking into just another data base engine will probably only result in more wasted efforts.
Apart from that I guess that you have only very few ideas about how software development works. Instead of waiting for some far-fetched date, I'd rather suggest that you switch now and thus increase their service revenues. If you have any confidence in Compiere and Macola is the PITA you suggest, then you can't possibly loose, can you?
While I have not been to Compiere's site since they posted the "donate for a new port" program I too think that a middleware abstraction such as JBoss is a very good idea and I would welcome this just as much as I would their port to a free database such as sapdb or postgresql.
And yes, I do know how software development works but I also know a simple rule is that "if you build it they will come". Small companies such as mine do not have the budget for Oracle and that is the only thing keeping me from jumping on the bandwagon. We are moving to SAPDB from MS as our corporate database so my interests are in seeing support for SAPDB thus the reason for my remarks.
Don't assume, it only makes you look like an A$$.
Thanks for the flowers... If you have $1800 for their package in case it _would_ support SAPDB, then you should probably have $1800 for their package that already includes Oracle to the best of _my_ knowledge:
I also would like to note that the leechers surely will come, but these guys, after having already invested a huge amount of money (time/work/...), need something to eat. So, please consider your rule of software development augmented by "If you don't eat, you don't build it." Now please re-evaluate "assume".
On the technical side, having a middleware like JBOSS and then be able to use Compiere together with whatever data base happens to fulfill minimal requirements, like eg. PostgreSQL, but very likely SAPDB, too, is the best option to broaden the possible application space of Compiere, in my opinion.
I plan to setup and demo the app to our accounting and production departments using the Oracle developers license to see if it is a viable replacement but, unless an open source db is supported we won't be able to use it. We are not going to swallow the cost of yet another license based database when a perfectly viable "free" database exists. Once support for sapdb is available then I will gladly have our President cut the check for the support contract.
Also, the whole processor/internet/limited seats biz is annoying ... using a free backend should allow them to have a simple payment scheme...$1800-$2000 per year for support on an unlimited amount of seats. This would be music to the ears of IT people around the globe who are tired of having to memorize license contracts.
The leeching is a problem I do admit but I cannot fathom any IT Director that would deploy a Accounting/ERP system without a support contract and those that would will have a nice surprise waiting for them.
You are welcome for the flowers.
Ah, that's embarassing. I totally missed that link.
So, what's the total amount needed to get this thing "independent?" (or maybe that's in there, and just can't see it either)
During email exchanges in October / November Jorg said to me that it would cost $7000 per month to employ him to do the work. He had free time in January, which coinsided nicely with the expected completion of JBoss cmp in December. However not a January, nor a February, and possibly maybe not even a March completion date could be gauranteed. You see if JBoss ran over then that would push him back, and then..................................
Such gaurantees are valued somewhere I'm sure, but it was just a teenie weenie bit too wishy washy for me.
Then how many 7's did we keep paying, and surely in a comercial world, that would give us ownership of something. And you know what Jorg was prepaired to give us for the money? He offered to dely the public release date of the postgres port. Somewhat curious I thought. But maybe others, which may include those waiting for db independence of this so public advertised "open source" product (which, in my opinion, seems to be working quite nicely for it a sourceforge) may not find it curious at all. Who knows, this is only comment.
We certainly did not want Oracle either. However as fortune would have it, I had previously worked as a sys admin at an Oracle site and had kept in touch with one of the programers. He had a few dba guys for me to choose from, whom were prepaired to travel the 1.5 hours to us for on site support, and give phone support almost anytime, for $50AUD/hr (including travel time). So I actualy had the Oracle side sorted, considering that it should only be short term. And the fact that my customer had to be talked out of commiting to a $15,000AUD product, and the exchange rate being close enough to 2:1 would could pay for one month of Jorg, and still have a grand left for me to do window and report customisations. If it was only going to be one month and if it was only going to be short term with Oracle.
Well, now we see the donation tray only has $1061.95US as of this writing. To all those who have donated good money, having someone say "in my opinion this is but a drop in the ocean", oh well.
I donated $50 and am now planning to spend some time getting familiar with the codebase and the current state of the PostgreSQL port.
I own a small business and like many of you, I can't afford to commit to $1800 a year for Compiere. However, the nature of my business is that I have spare programming cycles for discretionary use.
I would suggest that those of you who want PostgreSQL support and have the skills and the time to devote, stop asking and write some code.
When you have donated the code, make sure you make it well known in a forum here.
Because I for one would really like to see that.
How much $$$ Compiere needs to support postgres ?
I'm thinking serious to do "development" fork to try move
Compiere to some persistance framework. (I do not believe in JBoss here I wrote about this some time ago:
CMP could reside on server but client would have to use remote Entity beans or have own database access for many thinks (GUI eg.)
I analized Castor, OJB and Hibernate.
I think Hibernate is the best althougth it lacks some features (easy to do)
Currently I try to port whole from creation logic to this and it seems to be good idea (code will be much more clear)
Now I have some free time I don't know what in the future.
What do You think of this ?
Forget Castor! Really.
What do you have against jboss?
mmh I have nothing to jboss. But in my opinion it does not fit into Compiere.
There is a lot of unoptimized database access code in client (form creation code, MTable code, Printing).
It does lot of small selects which hurts performance. It is necessery to optimize it. I believe that this is ponitless to move this code to CMP EJB residing on remote server.
It would be remote Entity beans which are not very fast for many reasons. Acctually I would have to use DAO any way. So maybe it is better to have good tool in client, which comunicates to database directly as it is now.
Futher more it would not block using Compiere without Application Server.
I will do some probes now and will tell how it works.
It surely remove a lot of ugly JDBC code, it should improve perofomace if I will enfoce some changes in Hibernate, and all should much more simple.
You don't like Castor or any persistance framework .
I will show code if there will have something (no lot of time now) and You can tell what do You think of this.
IMHO, if it's not done right we should do it right now, avoiding such a good framework like jboss just because we would need to optimize some code it's unacceptable.
It should be optimized from the beginning, and if it's not yet we should work on it so it gets optmized.
Let's not think about what we have now, just think about what should be better.
I'm following this project since one year and it is my first message i drom into this forum. Let me express my personal idea: it is better to go for a DBMS indeoendence solution rather than a design a specific porting to PostgreSQL.
Of course in the event of CMP - J2EE the responce time will slow down but if we're into a small-medium company evironment it won't be a problem for the relative small number of transactions.
In large companies a J2EE server will allow using more than one application servers so performances will be good as well.
Other advantages are: Compiere in this way will be focused only on the business logic. It will be independent on Oracle, PostgreeSQL, JBoss and any specific product, J2EE is a specification rather than a specific product.
And again what about JSP & Servel for B2B B2C support?
Just another point, SAP, the present market leader, even with a proprietaty software implements a sort of J2EE architecture and is moving toword J2EE itself.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.