Forums : Feedback Forum

I'm interesting in seeing what the general opinion on this is.

The way I see it, ohloh has, arguably, three separate operating scopes.

On the one hand it's tracking and generating metrics from open source projects, and cross referencing these with other projects and the people involved.

On the other hand, it's compiling an informal CV ... or a who's who of the Open Source world. In order to have more accurate data, that necessitates tracking and cross referencing things other than open source data (location data and closed source/commercial contributions for example).

And on the gripping hand, Ohloh is providing a medium for provoking discussion on the open source ecosystem and project analysis.

What I wish to bounce off people is thoughts relating to the second point, and somewhat to the third.

A developer who's code is mostly open source is probably in a minority ... most developers primarily write closed source software to pay the bills, contributing what they can. Sadly this means millions of lines of code locked away in private repos.

Then there's Ohloh itself ... I can't imagine plans to open source much of the core code any time soon. Certainly not until you can think of a business model that lets you cover the costs of running this wonderful place as open source ;)

Also we've got a rapidly increasing number of source control systems and access methods that are posing a headache for people wanting to add projects (and the admins getting constant requests for them :P)

So the thought that occurs to me is, wouldn't it be nice to kill those three birds with one stone?

What would be the thoughts on putting together some sort of framework for an intermediate tool that can gather basic statistical data about a code base for ohloh to analysis without the need to reveal the code (so that closed source software can be tracked)... by making it approprately modular and open sourced, users can contribute patches for their favourite SCM, allowing projects currently left without code to do some of the leg work involved in getting the code in to ohloh?

This way we can have richer coding experience metrics, ohloh can receive community development without revealing the secret magic, and everyone can have their favourite source control.

As an extension of the idea, it would allow the possibility for projects to push updates to ohloh, rather than ohloh having to constantly check for changes.

Thoughts?

Daniel / Nazca ... over 17 years ago

Ping?

Daniel / Nazca ... over 17 years ago

Hi Daniel,

Sorry for the delay - the length of your post probably scared most of us away ;-).

What would be the thoughts on putting together some sort of framework for an intermediate tool...

The good news

We plan on making our SCM adapters and source code analysis open source.

The bad news

We don't know when we can get around to this yet.

ohloh can receive community development without revealing the secret magic

The idea of allowing private software developers to submit their data is very interesting. In my previous life as an Excel developer I would love to be able to show my contributions. My previous employer, however, would have little to gain from enabling this. It would reveal what, exactly, is going on in these projects. I can't imagine Microsoft wanting to divulge that there was only 3 active developers on IE6 (I made up that number - although I suspect I'm not that far off ;-).

It would also divulge who are the most active/key developers on these projects - which competitors would love to know. For these reasons I am very doubtful that this feature would be widely adopted. Do you agree?

Finally, however, this idea as prompted me to think about a general question: since Ohloh currently enables people to disclose that they've contributed to any project (without requiring metrics), perhaps it's a good time to ask: should Ohloh enable adding Closed-Source projects? After all, many of our features would still work: Stacks, reviews, contributors, etc...

What do you think?

Jason Allen over 17 years ago

Sorry for the delay - the length of your post probably scared most of us away ;-).

Yeah, I get that alot ... if it's not the rambling or the foaming at the mouth then it's the crazy looks halo
Hehe

The good news
We plan on making our SCM adapters and source code analysis open source.

Cool :D

The bad news
We don't know when we can get around to this yet.

Yeah, I can understand... adding features and smoothing out rough patches is more important for ohloh at this stage than relicensing the code already written.
Just as it should be.

To the rest of it ... well it's an interesting thing to debate in wider context.
I've found that ohloh offers me two very important services... one I'll get to later, but the first one is that it provides me with an objective and unbiased analysis of the actual code.

Personally I feel that the coding population in general has a responsibility to produce the best software they can.
If the code is written for a personal use that will probably only be needed once then a quick and dirty hack is perfectly justifiable.

On the other hand, if the code is being written for a release grade software project that other people are expected to use, then said code should be efficent, secure and as bug free as possible. Similarly, the interface should be smooth, intuitive and easy to use.
In real terms, compromises must be made between the quest for perfection and the need for deadlines more useful than It'll be done when it is done.

However, on the whole the industry seems to now taking the trend that software should be worth using.
10 or 15 years ago it might have been acceptable to release a quick hack and call it version 1 ... the computing industry in general was still relatively infant, and there were less mission critical demands on the technology. (I mean how many websites did people -need- to visit in those days to survive and make a living?)
These days there are so many coders out there and so much software available that for most applications, people don't have to use a particularly buggy or unwieldy piece of software because there are normally alternatives.

That, combined with the amount of digital threats and exploit happy crackers, is driving developing teams to sell their software not just on the features that it has but also on the quality of what is making it work.
Microsoft, for example, is making a play on vista being more secure than most other OSes... it's becoming more popular for companies to allow specialists to analyse their code to find bugs that have yet to be hit and reported by users.

Which of course brings me to my first important gain from using ohloh.
Looking at the project page I can get a sense of how well documented code is, how active the development is, what languages we used to create it, and so on.
These metrics are helpful indications of how likely the software is to do what it says on the box, and if it is going to be worth the hassle of setting up.
If ohloh tells me a package hasn't been committed to in a year, I'm likely to need a better reason to use it.

So the metrics produced are not only useful to the developers of the software in telling them where work is needed, but also in telling the potential users that they can have a little confidence in it.

Which leads nicely on to the other things I'm gaining from using ohloh: User reviews.
By keeping an eye on the reviews feed at the bottom, I have already stumbled on a number of projects that have a high chance of being very useful to me.
I could probably get the same sort of info from freshmeat or googling around, but here the users reviews are placed alongside real third party metrics and usage counts.

So the way I see it, if a project is worth using, they should be proud enough of their product to be willing to show their users a little about how it's made.
The developers can use ohloh as a way of showing that their product is being actively developed ... that the code is well commented ... but without actually having to show the users the code itself.

I do take the point that some projects might not want people knowing that no one has written any code for 6 months, but if they feel the need to conceal that fact then I'd feel worried about what else they're concealing from their users.
I can also see the point that telling your competitor who your lead developers are could be bad, but if your project/company is treating those lead developers with the respect they deserve, then said developers should be willing to show a little dedication to the project. I personally would think twice about putting someone in a key position if I thought they might move to my competitor the moment a bigger wage was offered.

Perhaps projects and companies that care about their users would be more interested in adopting such exposing tools, though the number of projects willing to adopt the idea might increase if projects were given the ability to hide parts of the metrics that they didn't want others seeing (some might not want everyone to see who is actually committing what and when, where as others might be happy just hiding the details of the commits themselves).

As to the last question ... that's a tricky one.
I guess it depends on what you see as the future for ohloh.
Allowing the adding of closed source projects would allow ohloh to have much broader data (perhaps we could gain something from comparing the stack count of Apache to IIS).
It would also lessen the focus on free and open software development.

I can definitely see benefits in both sides of the coin, but I think personally I'd value the wider data more than the dubious moral high ground.

Oh dear ... another long post ... perhaps I should start referring to these as poles instead of posts.

Daniel / Nazca ... over 17 years ago

ping?

Yes, I know that last post was long and rambling, but it would be nice to have a reply lol

Daniel / Nazca ... over 17 years ago

Daniel - I was frightened by the length again! I'll buckle down and read it now...

Jason Allen over 17 years ago

Looking at the project page I can get a sense of how well documented code is, how active the development is, what languages we used to create it, and so on.

I am very happy to read these words. As we design Ohloh, we've focused on providing simple, understandable and actionable metrics. We've purposefully avoided showing abstract, abstruse metrics. Software development (in general) has not embraced measurement-driven models (yet). While its often possible to measure aspects of a developer or a project, what is generally lacking is perspective. In other words - what do the measurements mean?

The answer lies in having a relevant comparative data set. As a specific example, one might be able to see that their project has an 8% commenting ratio in their code. The challenge comes in trying to understand how to interpret that number. Is 8% high or low? To get a better idea, you'd have to compare it to other projects. Ah - but then again - perhaps not all projects! Maybe just projects written in the same language? Perhaps projects that do similar things (ie: a web app?). Perhaps projects with the same age, or with a similar team size?

Until now, it's been impossible to attempt to come up with a reasonable comparative data set. That's one of the main reasons we built Ohloh - to help us understand software development metrics.

Which leads nicely on to the other things I'm gaining from using ohloh: User reviews.

I was a little surprised by this statement. To be honest - I've been a little disappointed with the amount of reviews being written. We currently have about 300 reviews written for roughly 200 projects. I suspect there is some percentage of those that are shameless self-promotion - so I'd discount it another 10-15%. I find some of them very useful - so I keep hoping it will pick up more steam. Meanwhile if you (or anyone else) have ideas on how to improve our rate of review submission - let me know!

I do take the point that some projects might not want people knowing that no one has written any code for 6 months...

Perhaps I have a skewed perspective, but my tenure at Microsoft left me with a strong suspicion that they would never consider making their metrics public. What's your opinion on the percentage of closed-source projects might consider making their metrics public?

Jason Allen over 17 years ago

nod @ the first part
Seems like a good goal.

I was a little surprised by this statement. To be honest - I've been a little disappointed with the amount of reviews being written. We currently have about 300 reviews written for roughly 200 projects. I suspect there is some percentage of those that are shameless self-promotion - so I'd discount it another 10-15%. I find some of them very useful - so I keep hoping it will pick up more steam. Meanwhile if you (or anyone else) have ideas on how to improve our rate of review submission - let me know!

It is true, there aren't many reviews, and of the ones that there are, some are either less than helpful or plain ego-stroking.
However I do still read through them, as there are some gems ... for example it was user reviews here that brought to my attention Code Igniter, FreeNAS, Tomboy and freemind, all of which I'm considering using.

As a thought, I can't remember, but is there some way of noting a project for further investigation? Suppose that could be done with stacks if multiple stacks are implemented.

It might help improve the reviews if there was an rss feed of the recent reviews cough ;)

Perhaps I have a skewed perspective, but my tenure at Microsoft left me with a strong suspicion that they would never consider making their metrics public. What's your opinion on the percentage of closed-source projects might consider making their metrics public?

As I say, I think it depends heavily on the companies attitude toward their customers.
It seems like a lot more small companies that are basing themselves around open tech, web startups and the such, are trying to be much more transparent in their development models.
Ohloh is a good example. While the actual code is closed source, you listen to the users and allow the user's interests to shape the development. You also give us a reasonable idea of what you're working on, in some cases giving us previews of upcoming features.

My feeling is that companies that wish to have this kind of transparency, the ones that care more about their users than their user's money, would be interested in having at least some public metrics.

While most of the companies trying to make a living off closed source projects probably aren't interested in having the actual code publicly visible, I think it would be an interesting exercise to make allow some method of letting closed source projects feeding metrics to ohloh, and also allowing them to hide parts of those metrics ... then seeing what projects are willing to make use of them.

It could be that only a small minority make use of them, which might indicate that the software industry as a whole has far too much paranoia and guilt about their products.
it could be that a larger number of companies are willing, which would let us see which companies consider their projects to be of high quality.

I know that I'd definitely make use of it... if I want other people to pay me to use my software, I want to make use of any tool I can in an effort to show that my code is maintained, commented and of a quality suitable for their purposes.

I guess my perspective could be equally skewed by many years of coding on projects for free... now that I'm moving in to wanting to build commercial applications, I want to carry the open source mentality in to new projects.

Daniel / Nazca ... over 17 years ago

So, uh, any further thoughts on this? Or shall we let it sink for now...?

Daniel / Nazca ... over 17 years ago