Forums : Posts

Integrate OpenID authentication.

I had a discussion earlier today as to how to count lines in multi-language files (i.e. PHP in HTML). Right now Ohcount counts a more important language; in this case PHP no matter how small the PHP ... [More] chunk in an HTML line. I prefer to count both a line of PHP and a line of HTML. That way when a user queries how many lines of HTML there are, they don't get a small number like 2 because of all the embedded PHP, CSS, Javascript, etc.; if a user queries for PHP, they don't get a huge number, etc. Also, it's much easier for the parser to do it the latter way ;) Thoughts or comments? [Less]

Hello, I have run a web site to the open knowledge on the ERP/CRM (mainly these Open source). The topic of this site is to give acces to lots of open documentations about how to choose an ERP/CRM ... [More] , how to migrate from one to another, and to stay in the spirit of the open source, not to be stuck on just one. For the start we have books for: Compiere, Dolibarr, ERP5, Hipergate, Jfire, Neogia, Ofbiz, Openbravo, Opentabs. All these programs are Open source. And of course we will try to get the information about some corporate ERP like SAP, Sage, Jeeves, ... Everybody's wellcome, Best regards, Alain Ivars www.choiceerp.org [Less]

Double post; sorry for the noise. Please delete this

The topic title is maybe not very clear but what I mean is this: Your guys are having some interface that all listings backends should implement (currently git, cvs, svn)?, what if you open the ... [More] interface (so say whay functions should be implemented) (I don't say that you should open the source of them immediately, although it would be cool) Anyway if the documentation of the interface is opened, people can start on a bazaar, mercurial, whatever-vcs backend. In this way people can contribute faster, and more projects will be added. (I don't use Ohloh for several programs of mine because the bzr backend is missing). [Less]

Here a suggestion for the rank calculation algorithm that would likely produce much better results than the current one: Rankingpoints = ln (Total number of commits * 50) * ln (Total lines of code ... [More] changed * Language factor) * ln (1 + Sum of stacks of all contributed projects * 5) Language factor could be use to factor in the difference in LOC between languages. If unwanted assume a value of 1) The algorithm is very easy and fast to calculate and it could be extended by more factors (e.g. longest time in project, persistance in contributing, etc.) [Less]

How about putting more emphasis on POSIX and LSB computability by having a nice looking badge for both of these. A project can be tested automatically for compliance, and the badge can be added.

It would be interesting to see the mailing list activity for open source projects. If a project has a good community and being actively used, the mailing list would have a lot of emails. If the ... [More] mailing list was started several years ago, but no recent emails would show a dead project. You could also measure how many responses a post gets. If it receives none = poor community that doesnt help out. If it has many = good community that tries to help users. Anyway, thanks for your site; it is really good and fun :D [Less]

I had an idea, what if you analysed the bug tracker as well as the source code? My idea is that you will be able to directly see which bugs were fixed in the VCS by looking for the commit closest to ... [More] the time it was reported fixed in the tracker. You would have another factor for your COCOMO analysis which could be used for determining the quality of the software written? [Less]

Done.