proposal: x: decide policy for sub-repositories

[adg]

[this is not a proposal yet, just a problem statement]

There are several proposals to add new packages to the x/foo "sub-repositories". (See: #16353, #13432, #12332, #16257, #15985, #15406, and more.) The proposals are all different, but they circle around the same issue: what should and should not be in a sub-repository.

Currently, the sub-repositories contain x different things:

1. Packages and tools that are part of a loose set of Go tools (godoc, goimports, benchcmp, x/debug, etc)
2. Packages and tools that support the Go web services (godoc, present, x/playground, x/tour, etc)
3. Tools that support Go project development (x/build, x/benchmarks, x/review, etc).
4. Packages that augment the standard library (x/text, x/image, x/crypto, x/sys, etc).
5. Other projects worked on by Go team members at Google (x/exp, x/mobile, etc).

To me, it's clear that 1-2 belong in the sub-repositories, and should be an official part of the Go project.

For 4-5, this code only lives in the sub-repositories either for historical reasons or mere convenience. The Go contributors are accustomed to the process (tools and reviews) of writing code in that style, so the sub-repos were just the obvious place to go.

(3 is a fringe case, as the tools could be worked on elsewhere, but the people working on them work on Go full time and work on that code solely to support the project, so I am inclined to ignore this code for the purposes of this issue.)

As the project grows, it attracts people who want to contribute new packages to these sub-repositories (see the issues cited at the beginning of this issue). The reasons for inclusion include:

1. To provide an official package for doing X.
2. To provide a supported package for doing X.
3. To contribute to the Go project.
4. To use the project's development processes (gerrit, etc).
5. To have their code reviewed by other Go contributors and to benefit from their expertise.
6. To use the same consistent license (with CLA) that the project uses.
7. To provide a single package for a single purpose, and avoid duplicate effort.
8. To provide an official package for interoperating about (but not necessarily doing) X.
9. To act as a dependency for something else under x/.

[What are the other reasons? I'd like to enumerate them all here.]

---

My opinion begins here:

None of the above reasons are good arguments to add new packages to the sub-repositories. Taking each in turn:

1. The "official" packages, such as they are, are generally of high quality because a small group of dedicated contributors have invested constant energy in them. But there are other high quality packages elsewhere in the Go ecosystem (many of higher quality than some of those in the sub-repos), it's just harder for people to find them and they don't have "prestigious" import paths. Rather than moving more stuff into the Go project, I'd think we should address this issue by making it easier to find and recognize high quality packages. (One way to do this is to improve godoc.org, but there are many other ways.)
2. Putting something in the sub-repositories does not imply support. People are not more or less inclined to work on a package just because it's in a sub-repository. The current set of Go contributors are stretched pretty thin as it is. I think that by moving more stuff into the sub-repositories we set expectations of support where there is none. That's bad for our users.
3. Moving more code into the project just for the sake of contributing is not a net win. There's plenty of work to be done on the code that is already part of the project (and the many, many open issues).
4. If people want to use our processes, I think that a better approach is to find a way to use those processes outside of the project. That's a solution that scales much better.

[see discussion below for other points]

In general, I'd like to make the Go project smaller rather than bigger. (In the same sense that we would remove stuff from the standard library, if we could.)

As I said, this is just my opinion and perspective. I have created this issue to gather feedback from other [potential] contributors.

Personal opinion ends.

---

We need to set a policy for what belongs in the sub-repositories, and in doing so more clearly define the boundaries of the Go project.

[bradfitz]

Nice summary. Thanks for writing this up. I agree with your opinion too.

[quentinmit]

I have a very different opinion. I think there is significant value in having a set of "semi-blessed" packages, and random packages that can be found (more or less easily) on godoc.org do not meet that bar. I think one of the big reasons that languages like Python have taken off is that they are "batteries included"; their ~standard libraries include a wide swath of functionality, such that the average program can be written without adding any third-party libraries. If anything, I think more should be included than we have now.

I think the x repos today have already improved on the "batteries included" model, by making it clear that "these are good packages, but they're not great packages, and we don't make as many promises about them". I would actually like to see a future where we include a snapshot of the x repos in release tarballs, attaching the same disclaimer.

I see your proposal as directly advocating for fewer packages in x. I disagree that that is a worthy goal.

That said, I don't think that #2 and #3 necessarily have to live in the same place as #1 and #4. I would be happy to separate the "random part of the Go project" repos from the "semi-blessed packages" repos.

[ianlancetaylor]

@quentinmit I think we absolutely do need a way to tell people "these are good packages" and I think that is what @adg was alluding to with his point 4 above. The question is what that mechanism should be.

The disadvantage I see with the current golang.org/x system is that these packages are effectively owned by the core Go developers. That isn't scalable or even desirable. If we can solve that problem within the golang.org/x name space, then, fine. But how? And who controls the golang.org/x name space?

I think it would be better to have a scalable mechanism for identifying and maintaining good packages, and I don't see why that should be, or even can be, associated with golang.org/x.

[griesemer]

Great summary of the issue. What @bradfitz said.

[cespare]

As a consumer of many third-party packages, I think I agree with @quentinmit (or at least with @ianlancetaylor). If I need a package for $task and there is an /x package for $task, I've generally found that while it might be incomplete, it's usually of high quality (the scope and style matches the standard library; the test coverage is quite good; the documentation is thorough and concise). If I have to go browsing through $task packages on godoc.org and pick the best one, it's often of such poor quality that I either do an extensive cleanup/refactoring/testing/docs pass before bringing it into my repo or else I choose to write my own package instead.

@adg said:

I'd think we should address this issue by making it easier to find and recognize high quality packages. (One way to do this is to improve godoc.org, but there are many other ways.)

but I'm skeptical that a process outside the Go team will produce a quality bar that is usefully high for me.

I'd like to see [high-quality package identification mechanism] exist and be proven to work well before any trimming down of /x.

[adg]

If I have to go browsing through $task packages on godoc.org and pick the best one, it's often of such poor quality that I either do an extensive cleanup/refactoring/testing/docs pass before bringing it into my repo or else I choose to write my own package instead.

I'm advocating that we fix this problem.

I'm skeptical that a process outside the Go team will produce a quality bar that is usefully high for me.

The "Go team," such as it is, is only a handful of people, and they do not have the cycles to review any new packages. If you want more packages in x/ then they must be written, reviewed, and maintained by other people. That being the case, there's no reason why they should be in x/. They're not going to be any better or worse for it.

[adg]

@quentinmit said:

I think one of the big reasons that languages like Python have taken off is that they are "batteries included"; their ~standard libraries include a wide swath of functionality, such that the average program can be written without adding any third-party libraries. If anything, I think more should be included than we have now.

Both Python and Go have suffered from having large standard libraries, too. In some cases, the standard libraries have become out of date and superseded by other packages in the ecosystem (or in the case of Python's urllib, by urllib2 in the same standard library!). Then we're left with prominent packages that are not suitable for common use. That's a net loss for our users.

If I understand your sentiment, you're advocating for including (a lot) more packages in the x/ repositories, as an extension to the standard library. Producing our current standard library (not the sub-repositories) was a massive concerted effort over many years, by people who are mostly domain experts in the functionality of those packages. I have two main questions:

1. Who is going to do this work? How do you propose we maintain the same quality level across many more packages that our well outside our areas of expertise?
2. Why does it need to go in x/? Why should we be the arbiters of which packages are prominent? Aren't we short-changing the ecosystem by neglecting third-party package support?

[rakyll]

From my perspective, being able to work under an x allows me to reach out to the go approvers and this is what I care when I am designing ecosystem-wide core libraries for a niche topic. I don't think it is possible once the experimentation is not considered a part of the Go project.

[adg]

To expand a little on my goals here: by defining what does or does not belong in x/, I hope to remove bureaucracy.

Today, if someone wants to put something in /x/exp they need to ask permission. People shouldn't have to ask for permission to experiment; that has a chilling effect on experimentation.

Similarly, if something is to be included in an /x sub-repo, they need to ask permission. Why should they? Shouldn't they be able to put their high quality code in a repo somewhere else, and have it be regarded just as highly as anything in /x? Code should be judged on its own merits, not by its location.

[quentinmit]

I'm not sure I think I would agree with "a lot", but yeah, I think x/ should perhaps be twice the number of packages it is now.

1. Who is going to do this work? How do you propose we maintain the same quality level across many more packages that our well outside our areas of expertise?

Go project members will do the work, just as they do today. The people who are proposing these new packages are working in their area of expertise. But I also don't think it's "outside" our areas of expertise; our area of expertise is designing idiomatic Go APIs, and that can be equally applied to something like video compression as it can to XML or JSON marshalling.

1. Why does it need to go in x/? Why should we be the arbiters of which packages are prominent? Aren't we short-changing the ecosystem by neglecting third-party package support?

That's a hard question. For me, I have a soft definition of "low-level" support packages that I think deserve to be centralized. To use an example I am personally familiar with, I think video and audio formats should be in x/video or x/media, ala the current image support we have in x/image. I think a streaming server built on top of those libraries, or a GIMP clone, does not belong in x/ because that is not something foundational.

I do think making high quality third-party packages easier to find solves a large part of this problem, but we are not there yet. And even if we do make them easy to find, packages that are separate from Go still have more adoption problems we can't possibly solve: for example, they may be under various licenses, and it may be cumbersome to import into a commercial codebase. That may be appropriate for a library to interface with a Siemens PLC from the 1990s, but I don't think it's appropriate for OpenGL.

[adg]

Go project members will do the work, just as they do today.

The reality is that there are hundreds of open CLs (some pending for more than a year) and thousands of open issues. The work is not getting done. The present structure does not scale. To encourage more development that we cannot support is irresponsible and unfair to the contributors.

I do think making high quality third-party packages easier to find solves a large part of this problem, but we are not there yet.

My argument is that we will never get there if we use the sub-repos as a crutch.

[adg]

From my perspective, being able to work under an x allows me to reach out to the go approvers and this is what I care when I am designing ecosystem-wide core libraries for a niche topic. I don't think it is possible once the experimentation is not considered a part of the Go project.

I think external packages will see more high quality reviews if they are more prominent. Everyone in the ecosystem has an interest in improving the most useful (and used) packages.