Menu
▾
▴
Forums
- Language-Serbian 15
- Language-Romanian 9
- Language-Hebrew 2
- Language-Farsi 3
- Language-Bosanski 4
- Language-Slovak and Czech language 9
- Language-Arabic 14
- Functional-Posterita 99
- Language-Turkish 14
- Language-Hungarian 7
- Functional-Human Resource 65
- Localization Brazil 64
- Language-Greek 1
- Language-Filipino 16
- Language-India 36
- Language-Thai-Siamese 47
- Functional-Manufacturing 290
- Language-Chinese 98
- Language-Finnish 5
- Language-Nusantara 56
- Language-Italian 81
- Language-Japanese 33
- Language-Portuguese 82
- Language-French 55
- Language-Bulgarian 7
- Language-German 223
- Language-Russian 15
- Language-Spanish 1180
- Functional-ERP 866
- Content & Documentation 128
- Functional-Financials 503
- Bazaar Projects 136
- Specifications Requests 16
- Developers 3195
- Community Process 327
- Business & Marketing 122
- Functional-Web-based Modules 103
- Help 1700
- Bazaar Open Discussion 2060
Hi all,
Did anyone have a look at TinyERP?
If yes, can you post your comments?
www.tinyerp.org
They have a pretty good website and they are also using Ajax as a user interface. They also use a partner network system like compiere does. Otherwise in terms of functionality, I have no idea.
Regards,
Alex
Hi Alex,
As usualy all applications written in PHP have good look and feel and are web based.
Regarding ERP application in php my general comment is that it can't grow as big and as complex as ERP application written in java. PHP do not have all the infrastructure which java and frameworks based on java give that's why i think that after some size php application get more costly to support and enahnce.
Kind regards,
Trifon
I All!
I am afraid that Trifon got confused about Tiny. Tiny is not developed in PHP, it is developed in Python and it is not only a web based application, it has a Gtk based fat client.
My impression is that Tiny was modeled after Compiere. I believe that Tiny tried to correct some not so good decisions about Compiere and tried to change the way they do it.
Open Source based database vs Oracle
Master Detail data entry
Propietary library for pdf file generation
OpenOffice files as a reporting tool
XML-RPC communication between the client and the Server
Web Services, etc.
The Tiny ERP Architecture looks also interesting:
http://tinyerp.org/wiki/index.php/DevelopperBook/TechSpecArchProgram
Previous versions included almost the same menu options as Compiere.
A java vs python discussion is out of topic but there are some disadvantages about developing in Java rather than programming in Python, among them a Python applications is usually developed in a shorter time than in Java.
A side by side comparison between python and JAva can found here:
http://www.ferg.org/projects/python_java_side-by-side.html
"A programmer can be significantly more productive in Python than in Java. How much more productive? The most widely accepted estimate is 5-10 times. On the basis of my own personal experience with the two languages, I agree with this estimate".
Tiny have grow up in features at a really amazing phase compared to Compiere.
Unfortunately Tiny also has that lock-in feel similar to Compiere, the business model is the same.
http://www.tinyerp.com/component/option,com_sobi2/Itemid,67/catid,2/
And their community is not as active as Adempiere's :)
Hope this helps!
Best Regards
I agree partially with Moyses.
> A java vs python discussion is out of topic
Agree
> "A programmer can be significantly more productive in
> Python than in Java. How much more productive? The most
> widely accepted estimate is 5-10 times. On the basis
> of my own personal experience with the two languages,
> I agree with this estimate".
Agree partially.
There are languages less restrictive than others.
In some scenarios ones are better than others.
What I think is in a complex application like ERP, the language is not so important as the architecture and design.
In a little application, java can be seen as pachydermic, and any scripting language (php, python, etc) looks faster.
There are many things I would never code in java but in unix shell script :-)
But in a big application, IMHO the language is not so important as the good architecture - ease of reusing objects, ease of extending, etc.
I think Adempiere inherited a good architecture from Compiere.
I know there are detractors here from this architecture.
But I find very easy to extend the application without code.
And when I need to code I found very easy to write the code after I know how to use the model.
A callout can make a lot of things in very few lines.
A process can make lots of things just writing a short doIt process.
Etc.
At this point is not the language. Compiere could be constructed in python or perl or even php and could be as extensible (in configuration and in code) as it is in java.
And at this point there is a remarkable effort from Sun standards on the enterprise level that makes java desirable for this type of applications.
But everyday market is also adopting LAMP apps (like Sugar) and there is no problem with that.
Finally from what I have heard from Tiny I agree with Moyses.
The model looks the same as commercial-open-source model, with the inherent problems of such model:
- like the lack of support for non-paying community
- like the need of controlling what to deliver / include for business purposes instead of product or market purposes
- etc - there is enough etcetera materials on these forums ;-)
Regards,
Carlos Ruiz
Hi,
sorry i got confused.
Thank's for the details it was interesting for me to read them. It looks that business model is the factor that stops product from growing.
But even in Python.
I do not care about productivity of languages but about frameworks based on it and available(read it open source). Also about community - java community is very strong and growing.
Kind regards,
Trifon
MUMPS is an ANSI standard language, developed to run multiprogramming/tasking applications on the PDP11 series of mini-computers. It has an built in database, email system etc. It is EXTREMELY CPU and resource conservative (remember that in PDP11ś 256 MB was a luxury), so a 300 concurrent user system can easily run on a 4 CPU 64 bit system with 8 GB memory. It has a distributed database facility, so you can have a local branch server, connected to a corporate server, over a TCP/IP link. In case the link fails, the local branch operations continue and when the link comes up the databases automatically sync up. This can also be used as a disaster recovery site, geographically separate.
The US Govt Veterans Administration, and Dept of Defense has been using a MUMPS based system since the early 80s. VA alone has over 200 hospitals and 800 clinics running multiple instance of VistA, the MUMPS based Health Care and Electronic Patient Health Record System. Where nearly 200,000 users access the system, from around the world. It services the health care needs of several million people.
MUMPS based systems are the backbone of the financial systems around the world, like credit card processing etc., where response times are critical.
MUMPS has extensions for using it as an network or hierarchical database and ESI, a software vendor has developed an Object based platform. It also has an SQL access.
An Open Source and FREE version of VistA and the MUMPS platform is available as GTM.
The 3 trillion dollar health care industry, especially in the US needs a total revamp of the supply chain and IT infra structure. MUMPS based VistA is being seriously considered as a possible alternative.
VistA has been developed and largely used in an military environment. The processes of for the civilian health care need to be added to VistA.
I think using the powerful Application Data Dictionary architecture and built in RAD facilities, Adempiere/Compiere etc have a potential of offering an Open Source Stack. So this could be an opportunity for Adempiere to have a competitive package for one LARGE vertical.
Vipen Mahajan
PS I have been into Compiere etc. since 2001. More from a business process re-engineering than from a development angle.
Hi Vipen!
I am happy that a old friend are here!
Thank you for you comment Vipen, I hope you join this great community
Victor Perez
CEO
www.e-evolution.com