Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.synopsys.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
The popularity question is addressed in our FAQ at http://www.ohloh.net/about/faq#popularity
We're planning to retire this method of computing popularity soon, since there are some flaws in it. We'll
... [More]
be replacing it with a direct count of the number of user stacks containing the project.
Thanks for the kinds words,
Robin
[Less]
Hi ted,
I've removed the duplicate project 3264, and I corrected the report on project 18 to be the latest information. All of the ratings and stacks and such have been moved over to project 18.
... [More]
You're not the first to requests a duplicate-detection feature, and when time allows we'll probably try to implement one. For now, we're cleaning them up manually, and so far it hasn't been too much of an issue.
Thanks for finding this and letting us know,
Robin
[Less]
Hi nasheet,
iTextSharp is a SourceForge project. You can get the latest source code from http://downloads.sourceforge.net/itextsharp/itextsharp-4.0.3.zip
For the Project Cost calculator only, we use the Basic COCOMO model. This model considers only the total lines of code when estimating the years of effort required:
months = a * (KLOC) ^ b
a and b
... [More]
are arbitrary constants. Ohloh uses typical values of 2.4 and 1.05.
You can read more about COCOMO at wikipedia.
This is the only place on the website where we use COCOMO estimates. Elsewhere on the website (such as on the contributors pages), we measure the time more precisely by examining the actual source control logs.
[Less]
Failures are usually caused by a temporary networking or server problem. We reschedule most failed downloads automatically, and they usually succeed on a second try.
If a job repeatedly fails over
... [More]
several days, we may have a problem.
This download appears to be running well now, and the report should be ready soon.
[Less]
There was a great article published last month on Linux Weekly News called Who wrote 2.6.20?. This is a little survey about the linux kernel which contain some good ideas regarding code analysis and
... [More]
statistics like Developers with the most changesets, Developers with the most changed lines and so on...
I think this could be inspiring for the ohloh team to add some features to code statistics.
[Less]
It'd be great if the most recent figures approximatively displayed in the codebase history graph (code, comments, blank) were made explicit, e.g.
code.............2123 lines.....64.5%
... [More]
comments.....1032 lines.....31.3%
blank..............134 lines.....4.2 %
this would be especially useful to understand how specific projects position themselves with respect to the reference values Ohloh uses to establish factoids.
For example: projects are marked as well documented if their comment/code ratio (N%) is above the average (M%) for that language category. At the moment, though, there is no way to know the comment/code ratio for projects not highlighted through factoids.
[Less]
Hi all,
Great stuff - I'm loving ohloh and added several projects and built my stack. Your stats helped me pull together some stats for a presentation I am giving. I'm so glad I didn't need to
... [More]
manually go through some changelogs in source code to figure this stuff out. :-]
Any plans to add some aggregated stats for someones stack? I'd love to see, for example, total LOC and person days for all projects in my stack.
Keep up the good work. I've been happy with support so far too.
Thanks
[Less]
Hey
I really like the graph that shows for each contributor how active they have been. However, its on a very large scale - 5 years. Can you base that on how long the project exists? If you go to the
... [More]
Code tab, you'll find:
'The source code repositories show that the project is x months old.'
Where x is a number of course.
Why not use that number to base the graph on. Lets say my project is about 11 months old, then each contributor would have the graph reach to lets say 1 year. And once it becomes 12 months old, the graph changes to 1 year and a month. That would make it a bit clearer I think, however, I do like how it is now.
Thanks
[Less]