willnorris

UX definitely ended up being one of the hardest parts. We also never got to the point of really building a compelling product on top of the protocols. We did actually do some work on privacy though, but it never got super far. For example, you could set simple access controls on content that was only available to friends that logged in with an OpenID. I think I had it so that certain of your hcard attributes were only included for authenticated users as well.

Some of the work we did then still exists today in various forms. Activity Steams led to Activity Pub, which has seen far more adoption than we ever did.

And microformats are still widely used in some communities, though certainly not like it could have been, largely things to Google putting weight behind schema.org. For example, nearly all of the indieweb.org work is based around microformats at the core, with things like webmention, micropub, etc

same team. different company.

We currently only list project that are or were primarily developed by Google. We decided to include projects that started at Google and were since donated to foundations, such as Kubernetes.

But we aren't yet including projects where we are just heavy contributors, but they're not "Google projects". That includes Linux, git, LLVM, and a host of others. We do want to recognize them in our project directory, but want to make sure that they are distinguished from Google projects so that we're not implying something that is accurate.

> The default google approach to open source is unidirectional source dumps after all the work is done.

I can definitely say that is not our default approach to open source; in fact it's a very small minority of projects that actually operate in that fashion. However, I can understand that it could feel that way to some people.

We've long said and continue to believe that there is no one way to do open source. That's true of nearly every aspect of a project including licensing, governance, community management, etc. Project are released for different reasons, with different motivations and goals, and so the way they are managed often differs.

One area I know we could do better is to set better expectations for projects around many of these topics. How is the project managed, how are decisions made, how committed to this are we (ie. are we using it in production), etc? If those aspects of a given project were clearer, would that address some of your concern (with the understanding that some projects may be be held closer to the vest than others) ? Or are you objecting to the tighter control in general?

Thanks. What you said definitely exemplifies the problem we were trying to solve. People often look through one or two of our GitHub organizations, but don't realize that we actually have over 100 of them. Plus many of our projects aren't actually on GitHub (or at least only mirrored to GitHub). The goal of this directory was to help discover those projects.

The problem is that we have over 2,000 projects, so simply listing them all on one page doesn't work very well. Hence why we built this directory, which allows browsing by category, by tag, by language, as well as full text search.