BYBLACK DUCK

Tag – You’re It!

By on May 15, 2012 in blog

Tagging on Ohloh has long been less than ideal. The user interface for tagging a project, and for searching or browsing by tags is not exactly intuitive. Allowing an unlimited number of tags per project encourages people to add lots of tags in an effort to get their projects to show up in search results. So we end up with some (beloved) projects that are tagged like this:

Which doesn’t distinguish or selectively associate projects, and doesn’t help people browsing projects find what they’re really looking for. We’d love to encourage the evolution of a folksonomy of tags on Ohloh, but we don’t want to make things too complex, or impose too much structure. So, we’re thinking of changing Ohloh tagging as follows:

  • Allow only 13 tags per project. So you’ll have to pick and choose – which is good! Why 13? Because we are not superstitious!
  • Help you select tags that will differentiate projects from one another by encouraging you to pick existing tags that are not in common with other projects.
  • Simplifying the user interface so it is straightforward to edit the tags on a project, and browse projects by tags.
Here is a proposed design for the tag editing feature:

In this design, we’d show you projects with similar tag sets, as a guide. You can add or remove tags from a project to either differentiate it from these similar ones, or more closely associate it with them. But with a limit of 13 tags, you’ll have to give some thought to what would really help people find this project.

When you add a new tag, we’ll auto-complete a list of matching existing tags below the box. While you can add a new tag not yet in Ohloh, we’ll be strongly encouraging you in the UI to pick from the existing set, to help minimize “tag proliferation”.

So, what to do about those projects that have more than 13 tags today? We could grandfather in their tags and require that the number be 13 or fewer after an edit. Or we could analyze their current tags and pick the 13 that most differentiate that project from the rest of the projects in Ohloh. If we did this automatic tag reduction, we’d only do the analysis and de-tagging after you’ve had plenty of time to edit your tags down yourself.

What do you think of this idea? Any suggestions for improving the concept, or the interface? Should we just grandfather existing tags or, should we de-tag those with more than 13 according to some method? Any other techniques we should consider to manage this collaborative tag hierarchy? Think this could work in nudging the Ohloh community to build that folksonomy?

About Rich Sands

I'm the Director of Developer Communities at Black Duck Software, and the product manager for Ohloh.
View all posts by Rich Sands →
  • Marc Laporte

    Hi!

    I think the Ohloh tag system is quite good. It’s better than any other software directory I know of.

    Limiting the number of tags is a bad idea. It doesn’t solve the root problem and tags work better when there are a lot of tags. The important thing is not the quantity but the relevance. Software with more features will have more tags. If there are tags that don’t make sense, they should be removed. 

    I don’t think a grandfather approach is a good idea either. Why advantage old projects? New projects should have fair access to visibility.

    To improve relevance (and indirectly discoverability of software):
    1- Right now, there are some projects which have set permissions to prevent us from updating tags. There should be a way to at least suggest tags additions and removals.

    2- As is often the case with tags, there are duplicates like zend_framework and zendframework. Tags are messy with all the synonyms, and underscores, squished words. wiki wiki_wiki wikiwiki wiki_engine, wikiengine. Would there be a way to have tag aliases or to have a form to suggest the merge of two tags?  Ohloh already has contributor aliases to aggregate the contributions. 

    3- Could we have a wiki page for each tag? (or group of tags). WikiMatrix has a wiki page for each feature: http://www.wikimatrix.org/wiki/feature:blacklist  A great thing would be that it would help us create a community-made ontology of software (which is an awesome goal in itself). Right now, there are tags like “security”. For some people, this means SSL, for some, it means a permission system, for some it’s security penetration software. CMS can mean Content Management System or Course Management System. Does Apache mean the license or that it works with the webserver? In these cases, we should do like Wikipedia and have a disambiguation strategy. When you try to use “security”, the system should offer the 3-4-5 alternatives. It would then be much easier to remove an ambiguous tag from a project.

    4- Conventions: if there is an accepted term for a category of software: ex.: “Learning Management System”: should we encourage people to use “Learning Management System” or “Learning_Management_System”?

    5- Sometimes, we use tags of other project names to indicate that the software interacts or re-uses code (ex.: Zend Framework, jQuery). Is this a desired use of tags? Could/Should there be another way to link projects to each other? it is certainly an interesting information for visitors.

    If after these strategies, there is still a problem (I am sure there won’t be): it would be much better to have tag weigting than a limit.  Ex.: if a project has 20 tags, they are worth 5 points each. If a project has 10 tags, they are worth 10 points each. 

    In addition, here are other tag-related suggestions:
    6- Many projects have no tags and they are hard to find. Could we have community initiatives?  Ex.: Top-30 projects by number of users/commits/etc. that have no tags yet.

    7- Filtering by tags is great: Ex.: https://www.ohloh.net/tags/java  Now, it would be great to have additional sorts (like we do in search) for number of contributors, etc. with a bookmarkable URL.

    8- I wish there was a tag convention to distinguish server software from client software from libraries (code to be included, but useless to end-users) because this is fundamental in what people are searching for.

    Best regards,

    M ;-)

  • richsands

    Marc, thanks for your detailed comments!

    I hear you that a system that encourages more relevant tagging would help solve the problem we’re addressing. But right now, the one searching and browsing method we offer besides basic keyword search is by tags. Not saying that we shouldn’t have more sophisticated faceted search (your item 7) – that is on our feature list. But with tags such a critical method for finding projects, and no limits on the number, the current system is an open invitation to game the tagging system to manipulate search results. While some people are being careful to add large numbers of relevant tags, others appear to be adding tags willy-nilly. When that happens it looks as though there is a visibility land-grab going on,  There is little incentive to be relevant – or rather, the incentive to be relevant is swamped by the incentive to show up in search results. The inverse of over-tagging is the impulse to de-tag competing projects so they do not show up. This may be one reason some projects limit edits to managers.

    I really like your crowd-sourced tag merge idea – that could be a quick and easy way to streamline the tag set and eliminate the worst duplication.

    Do you really think that most developers would invest the time to maintain a tagging wiki? The new design tries to minimize the effort needed to tag a project. I think one big reason a lot of projects have no tags at all is that our current interface is a pain in the butt to use and people look at it and say, “nah…”. Asking people to define what they mean by tags they add seems like a big hurdle. This could mean that only a few well-intentioned people will add tag descriptions, leaving most tags still undefined. We want to make tags less ambiguous, and for people to select the most relevant tags, but how do we do that without imposing too big a burden on developers?

    As for conventions, the design we’re floating here would strongly encourage you to add tags from the existing set, rather than inventing your own. Of course, you could add your own tags but before you do, you’ll be presented with matching tags to pick from. Your idea to establish some major tag conventions like client, server, library could also really help. Do you think that would be sufficient to help eliminate tag proliferation? 

    Another feature we’re actively thinking about adding is a crowd-sourced dependency graph – “this project depends on that project” kind of information. You rightly point out that people are over-loading the tag feature to capture some of this. Perhaps a different way to specify dependencies would help. Similarly, if it were easy to do faceted search on things like language and declared license: “Show me only C++ projects”, “Show me only ASL2 licensed projects” that might reduce the urge to add tags like “java” which do very little to help you find what you want.

    I really like your idea of community projects! That might work for more than just tagging. We’re also thinking of adding features that would encourage more contributions – like participation badges and such.

    So – help us figure out how to prevent tag spam without limiting the number of tags. We’ve been scratching our heads over that one and haven’t come up with an answer we think would work. If you know how to do that though, we’re all ears!

    • Marc Laporte

      A recap of my concerns:
      1- This is a general change which affects everyone to address a very limited number of projects with perceived issues. Lets focus on the challenges for the majority of projects/data and not make rules / deploy efforts for exceptions.
      2- This is a technical solution to a social problem. I am very worried some dev time will be invested, not solve the real problem, and make tags less useful than they are today.

      Here is a real-World example from September 2011: I sent a message to the project leader of DokuWiki asking him about DokuWiki tags which seemed inappropriate. He answered: “Thanks for the notice. Looks like somebody decided to add tags for everything we might have a plugin for. I cleaned this up to look less spammy ;-) ”

      The first thing to be done is to establish proposed guidelines of what is expected of contributors. As of now, there is not, AFAIK, a single guideline on what contributors are supposed to do or not to do.

      Then, identify examples of potential problems (top 1-3 percentile in terms of number of tags) and contact these projects and share the concerns and proposed guidelines and ask for feedback:
      1- How to improve the guidelines
      2- Ask the projects to justify their tags. This will clarify a lot of things. We will find out why they used the tags and this will help improve the guidelines. Or at the very least clarify what the real differences of opinions are. Some may also self-censor or realize that someone else has vandalized their project page.

      About the importance of guidelines, here are some concrete examples:
      1- Tiki is a general purpose groupware/content management system. We wanted a drawing feature, so we added SVG-edit into Tiki, calling the feature Tiki Draw. The code ships with Tiki out of the box (not a 3rd party extension), and it’s a feature, like hundreds of others. Should we use the tag “drawing”? If you are an end-user that needs a web-based drawing application that just works (drawing, saving data, etc.): yes. If you are a developer looking to integrate a drawing lib into your application, no. (well, it’s still interesting to you to know that Tiki does drawing and, from there, you can find out that it uses SVG-edit and this can influence your choice. We are in a similar situation for Spreadsheet, Timeline, etc. It would be really awesome to be able to indicate to Ohloh these kinds of relationships (works-with, integrates code, can export to, can import from, etc.)

      I do it informally with stacks:

      Bundled in Tiki:
      https://www.ohloh.net/stacks/79934

      Interop with Tiki:
      https://www.ohloh.net/stacks/79937

      Tiki dependencies:
      https://www.ohloh.net/stacks/79935

      2- Tiki uses PHP/MySQL/jQuery/Zend Framework and Smarty. Should we use these tags?  On one hand yes, because these are fundamental components. If someone is looking for a PHP/MySQL app, he should find it here: https://www.ohloh.net/tags/mysql/php  But is the PHP tag intended for tools that use PHP or make PHP? (ex.: IDEs)

      So we need to establish clearly what is expected of people (community guidelines), as you did above but in more detail. This should be built collaboratively (ex.: wiki page for consensus and a forum to discuss)
      * Do we want tags for plugins or just the core software?
      * Should there be a level of maturity involved?  (ex.: no experimental features)

      Back to the questions you raised in your comment:

      1- “sophisticated faceted search” -> I suggest to look at: https://www.ohloh.net/p/simile-widgets

      2- “others appear to be adding tags willy-nilly” -> The expected behavior should be in the guidelines.

      3- “impulse to de-tag competing projects so they do not show up” ->  I’d be extremely surprised to see this happen intentionally from FOSS developers. It’s one thing to add a missing tag, it’s another to remove from a similar project. This also should be part of guidelines (like Wikipedia does).  In any case, we have a log, and we can warn/ban offenders. 

      What is the benefit for a project to add a tag that is incorrect?  The site visitor may indeed discover the project, but then, after more investigation, will discover that the tag is bogus and will have a bad opinion of that project.

      4- “This may be one reason some projects limit edits to managers.” -> If at least, we could propose tags

      5- “crowd-sourced tag merge idea – that could be a quick and easy way to streamline the tag set and eliminate the worst duplication”  -> Right on!   So this could be a wiki page. You have a syntax like (alias(Content_Management)) on the “Content Management System” page. Or it could be like contributor aliases.

      6- “Do you really think that most developers would invest the time to maintain a tagging wiki?” -> Most, no. But we don’t need most. We need 10-20 dedicated people and it will get done.  Let’s aim to clean up/merge and define the top-400 or 500 tags: https://www.ohloh.net/tags?page=5 20 people x 20 tags = 400. I personally commit to doing 100. Just make a top-10 undefined tags somewhere and I’ll nibble away at it :-)

      7- “I think one big reason a lot of projects have no tags at all is that our current interface is a pain in the butt to use” -> I disagree. I think the main reason is that projects with no tags are rarely found and thus, the tags just don’t evolve. Give me a top-10 of active projects with less than 5 tags (that are at least in one stack, and that have at least one commit in last 12 months) and I will personally tag hundreds of projects. One thing that would make community tagging easier is to be able to see the description of a project while you are tagging. If you are tagging a random project, you need the description to pick out the keywords.

      8- “Your idea to establish some major tag conventions like client, server, library could also really help. Do you think that would be sufficient to help eliminate tag proliferation?”  Yes, along with guidelines, a dashboard (call to action to all registered users) and tag aliases. That will solve 80% of the problems of tags on Ohloh.

      9- “help us figure out how to prevent tag spam without limiting the number of tags.”  -> In addition to above, make it easy for people to report “I think this project is tag spamming. The tag XYZ was given to the project and I disagree”. Give a chance to the project to explain their position. There could be “disputed tag” status.

      10- “Your idea to establish some major tag conventions like client, server, library could also really help. Do you think that would be sufficient to help eliminate tag proliferation?” “Similarly, if it were easy to do faceted search on things like language and declared license: ‘Show me only C++ projects’, ‘Show me only ASL2 licensed projects’ that might reduce the urge to add tags like “java” which do very little to help you find what you want.

      Since tagging is there to help 1- the visitor choose a project and 2- See which projects are related, I think we should start with this in mind.

      Client, server and library is definately the first thing. When I am looking for software: I want to have a short list of 5-10 alternatives with some stats. I will then dig deeper I learn more about each project.

      Filter #1 “Platform”
      * Desktop-Windows
      * Desktop-Linux
      * Desktop-MacOSX
      * Linux-Server
      * Android
      * iOS
      * etc.

      If I am looking for a cross-platform desktop app, I’d like to tick all three Desktop-Windows, Desktop-Linux, Desktop-MacOSX. It really annoys me that there are so many permutation for this now.

      mac 
      macosx 
      osx 
      macintosh 
      mac_os_x
      apple
      macos

      If I am looking for a server app, I generally go by programming language
      * Python
      * PHP
      * JavaScript
      * Java
      * etc.

      Another facet is the functionality or use case
      * Spreadsheet
      * Project Management
      * Learning Management System
      * etc.

      Since I can’t really trust 100% the current tags, I will sometimes start with this last search, and see if some projects are missing some tags. I will also check project name/description.

      License also feels like it should be a specific filter although I don’t see myself using it. If a project is great, but not the right license, you can ask author(s) to re-license or dual license.

      Even better (similar to WikiMatrix): Make it possible to add a link to the reference of why these are indicating this tag. Say I tag the Tiki project with Spreadsheet. I can add a link to http://doc.tiki.org/Spreadsheet On WikiMatrix, it’s a wiki page ex.: http://www.wikimatrix.org/wiki/Tiki%20Wiki%20CMS%20Groupware:Blacklist This has two benefits 1- For the visitor, it’s additional information of what is meant by that. OK, you have a spreadsheet, but is it good?  2- It makes tag spamming really hard.

      Best regards,

      M ;-)

      • richsands

        Thanks again for your very detailed and insightful comments!

        Abhay got us some statistics. Of all the projects on Ohloh, about 199,000 or 36% are tagged. Of those projects, only 5,226  - less than 1% of the total – have more than 13 tags, so you’re right, the “rule of 13″ is not going to affect a lot of projects. It is for just this reason that we’re not overly worried that this change is going to mess up Ohloh’s tagging.

        Your explanation of how you add tags for Tiki is both interesting and illuminating. You’re using tags as a way to categorize Tiki across a wide range of criteria. Makes sense, since Ohloh today does not have a good way to do this besides tagging.  

        As for guidelines – we think most projects have a few very essential elements that distinguish them – make them similar to other projects, and then differentiate them from those similar projects. So, Tiki would be most similar to other wikis, tagged with “wiki” and “cms” (or “content_management” – assume we dedupe the tag set). Using criteria similar to the WikiMatrix.org wizard, I’d expect wiki projects to pick tags like “wysiwyg” – the most crucial differentiators for discovering the right wiki projects. The trick here would be to avoid guidelines like: “non-CMS features of CMS projects that are also available stand-alone should normally not be tagged.” I think such detailed guidelines could become unwieldy very fast, as you might have to wade through a lot of stuff to know how to choose good tags. It is our hope that by limiting the number of tags, projects spontaneously will pick the most essential tags in their problem domain to aid discovery, and leave out the non-esential ones.

        Question: would you like to see Ohloh develop a set of specific taxonomic filters such as “Platform”, “Type” (Client/Server/Library), “Function”, etc., and perhaps a way to indicate inter-project dependencies? Or would you prefer to see a set of tagging conventions for these different aspects of projects, and use browse by tags to implement filtering? I can see the benefits of both approaches – the tagging approach is very flexible, but it might be more complex to formulate queries or select the right tags for filtering. Likewise, taxonomy filters must cover the most common differentiators, and there always will be facets that are missing for some people, but they may be easier for infrequent Ohloh users to understand quickly.

        Our team agrees with you that tagging and taxonomic filters are there to help a visitor choose a project, and to see which projects are related. But we think these features should be optimized for the visitor’s experience, rather than the person maintaining project metadata. So we’re leaning towards more fixed filters, rather than the tagging convention approach. But we’re listening! What is your take on relative ease of use for visitors of these two approaches?

        If you were to prioritize these elements of your tagging proposal, what order would you put them in? Which are essential, and which are nice to have?

        - Guidelines / taxonomy
        - Tag definition wiki
        - Flag this tag as inappropriate/disputed
        - Tag dedupe/alias interface
        - Community tagging contests / crowdsourcing
        - Links on tags to substantiate tag choices like WikiMatrix

        If we implemented more fixed taxonomy elements, rather than a comprehensive tagging feature, which of these elements of your tagging proposal would you still consider to be essential for a tagging feature intended to complement taxonomy metadata?

        Again, thanks for your very thoughtful ideas. We’re listening! We’d like to try the simple tagging interface, limiting the number of tags to make people really think about their project’s place in FOSS, and its special characteristics, and then implementing some of your suggested ideas. Please keep the dialog going, and please help us continue to improve Ohloh!

        • Derigo

          “If you were to prioritize these elements of your tagging proposal, what
          order would you put them in? Which are essential, and which are nice to
          have?”

          Essential:

          1. – Quick, non-centralized tool for aggregating synonyms/misspelled (by crowdsourcing aggregation/disaggregation): Tag dedupe/alias interface.

          E.g. when entering the tag “maths”, I would like to see a box appearing and asking whether I agree on the list of synonyms that other users already reported:

          “The tag `maths’ you added has already been reported to be a synonym of the following tags: do you agree (please, select/deselect the corresponding checkboxes ?
          [x] math
          [x] mathematics
          [ ] mathematica
          [x] mathematicalsoftware
          [x] mathmatics
          [ ] mathml

          Could you suggest other synonyms: _____________ [add]”

          Then, the synonym with the highest score is the “official” one (for the moment!) so that all other synonyms
          a) are preserved as entered by taggers (they should be able to read what they exactly entered for the project XYZ, e.g. “maths”); and
          b) are hidden to all others (so that a generic user would read the project XYZ as tagged with  “mathematics” instead of with the original tag “maths”): this would add a consistent tagging interface for all projects. At the same time, evolution/improvement of “official” tags remains possible.

          2. – Quick, non-centralized tool for generating and maintaining taxonomies (by crowdsourcing them): taxonomy (and possibly optional definition of them).

          E.g. when entering the tag “array-oriented-programming”, I would like to see a box appearing and asking whether I agree on the list of parents (“is-part-of”) that other users already reported:

          “The tag `array-oriented-programming’ you added has already been reported to be part of the following category-tags: do you agree (please, select/deselect the
          corresponding checkboxes ?

          [x] programming

          [x] array

          [ ] functional

          [x] parallelization

          Could you suggest other category-tags which contain the tag “array-oriented-programming”: _____________ [add]”

          Then, each tag would become part of one or more tag-trees. Only leaves would be displayed to the general user. Therefore, if I tagged my project XYZ as “array-oriented-programming”, “array”, “programming”, only the leaf “array-oriented-programming” would appear in the list of tags for XYZ.
          Nevertheless, users looking for projects tagged with “array” should be able to transparently discover my project (because the tag “array” is parent of “array-oriented-programming”). Again, associations “parents/children” would be strong or weak depending on the number of users who already associated a certain child-tag with another parent-tag. The search engine could of course take advantage of this natural ranking when suggesting projects which are e.g. correlated with the tag “array”.

          Nice to have:

          3. automatic harvesting of information on licenses from the Free Software Directory. Projects already submitted to the Free Software Durectory should have a flag/icon/box automatically highlighted. E.g.

          “The XYZ project has been reviewed by the Free Software Directory and certified as covered by the license GNU GPV v3+”

          Thank you for your “listening effort”!
          Best regards, D.

  • Derigo

    p { margin-bottom: 0.08in; }a:link { }

    Hi,Thank
    you for opening this informal survey on free software tagging.

    I
    tend to think that tag proliferation – per se – is neither good nor
    bad. The reality is complex and – to be honest, oversimplifying it by
    forcing people to squeeze tags for meeting the ridiculous length
    allowed e.g. by a micro-blogging post (some 10 or 13 or 15 tags),
    seems to me not particularly wise nor exciting…

    A)
    Avoiding unreasonable tag proliferation…

    Nevertheless,
    discouraging noisy tag clouds with tons of replicated content would
    be desirable and perhaps could easily be done so to still respect the
    contributors’ personal opinions and their freedom of express them.
    Within the broad topic of semantic tag proliferation, we should
    discern between

    * tags
    conveying new pieces of information about a project and

    * tags
    whose role is of merely technical workaround (e.g. tag replication
    due to synonyms and chains of parent concepts).

    We
    should also distinguish between
    * complex
    information involving project contributors’ opinions and goals and

    * claims
    on facts whose verification is completely deterministic even if
    nontrivial.

    A
    quite relevant example of deterministic facts involves license
    related tags which may be misleading and, in perspective, possibly
    damaging for other projects which could decide to rely on a given
    dependency because of a claim on its license of use: what if the
    never-verified-claim eventually results to be incorrect? What if this
    happen (Murphy…) after several person-months or years of work
    relying on that dependency? As a workaround, several developers
    actually tend to expose their code to proprietary
    software drift by weakening the copyleft protection they apply on
    their code. While in some cases this is intentional planning, in many
    others it is just a quite risky short-cut way for escaping from addressing
    licensing issues. At least, for the moment… Other developers would definitely
    prefer to use instead strongly copylefted dependencies, exactly because
    of their intrinsic legal robustness
    guaranteeing from future proprietary drifts. In both cases, providing
    a way for assessing the degree of reliability of a license-related
    tag would be of immense help.

    B)
    …without damaging expressiveness

    On
    the other hand, a desirable aspect of introducing new tags – which
    should be preserved – is obviously the possibility to expand the
    inherently limited subset of crowd-sourced semantic contents. Tags
    also may mutually enrich their expressiveness if carefully
    associated: in this sense, I believe that relatively long lists of
    reasonable tags are not only tolerable but maybe recommendable when
    trying to convey to the readers the correct semantic perspective of
    nontrivial free software projects (and I tend to believe that most of
    the free software projects are culturally led by quite rich set of
    motivations and topics).
    The point is how to support meaningful tagging and discourage noisy ones.

    C)
    Three proposals

    1) I
    also especially agree with point 2- as proposed by Marc Laporte.
    Introducing synonyms (and perhaps also homonyms, to help people to
    discover better ways for unambiguously associating their concepts
    with existing tags) would perhaps be the easiest innovation with the
    highest impact in reducing tag proliferation. For example, the tag
    mathematics ,
    math and maths
    are likely to be synonyms… Aggregating them so that tagging a given
    project with “math” would automatically list it also under
    the other two tags, would be probably not too complex to introduce
    and would greatly help to remove “technical”
    tag-duplications. Also, having a unique joint list of all projects
    tagged either as mathematics
    , math or maths
    would be highly appreciated by several users, I guess…2)
    The second innovation could maybe be to introduce at least the tag
    aggregation “is-part-of” so to include sub-tags as semantic
    sub-topics of a given tag (or of a set of synonymous tags). For
    example, the tag physics
    is clearly a sub-tag of the tag science
    . The tag array-oriented-programming
    appears as a highly correlated concept if compared with
    array_processing
    (perhaps not exactly a synonym) and both could be considered sub-tags
    of both tags programming
    and array
    , therefore highlighting the evidence that a certain concept/tag may
    have multiple parents.3) A third innovation could be to
    import – either as default for non-tagged projects or generally for
    really critical tags, such as those related to free software licenses
    - the highly reliable tagging system of the Free Software Directory
    (e.g. http://directory.fsf.org/wiki/Category/Use – by the way,
    again a wiki technology boosted such a successful tagging). This is
    based on source code peer-review by human experts so that it is an
    authoritative way for providing minimal tagging for projects which
    are aware enough to properly fulfil the legal obligations required by
    the free software licenses they “claim” to be covering their
    work. Randomly inspecting license-related self-tagging in Ohloh –
    or also license relationship between project’s source code and its
    dependencies – is actually an alarming experience: it is really
    impressive the overall share of free software projects whose
    application of licenses is contradictory and basically illegal (e.g.
    projects using dependencies or mixing contributions covered by
    incompatible licenses). In this sense, automatically detected
    source-file licenses as reported by Ohloh and reliable, in-depth
    human-based source code peer-review as performed by the Free Software
    Directory appear as prefect complementary approaches which may
    greatly benefit from each other.

    I
    would suggest to highlight with a graphical sign (perhaps a new
    factoid could be better suited as a complement to the corresponding
    verified tag) those project whose licensing policy is authoritatively
    peer reviewed by the Free Software Directory.

    Best
    regards,D.

  • Pingback: Tag – You’re It! The Sequel… | Ohloh Meta