We should try to make the web faster. But it seems to me as though that in this process, there is no discussion about keeping the web readable. (Sourcemap's can be turned off.)

I don't think these two features, fast+readable, oppose each other. Not in the long run at least. I'm sure we can find a solution to keep the two together, as long as we consider both to be essential.

It could be addressed culturally. There's no need to mandate a single channel for distribution to humans (source) and machines (binary).

We could define a standard discovery mechanism for embedding a source URL, e.g. github repo + changeset, or PGP-signed javascript.

This would be even better than "View Source" (e.g. source provenance, change history and human reviews/comments), and the browser can still correlate runtime inspection with relevant source code.

What I find interesting about this discussion is the implicit realization that the freedom to inspect the source code is valuable. It has not always been the case that one could make such a statement and expect the majority of readers to instantly understand. What a long way we have come!

I suspect, though, that we still have not come far enough to be able to deal with this problem culturally in the mainstream. The technical solution you present would work exceptionally well along side licenses like the AGPL and would definitely be a boon to the free software community. However, are people as eager to provide freedom to others as they are to take advantage of it?

I choose to mention the AGPL on purpose because it goes a fair way beyond what you propose. It grants all 4 free software freedoms, not just the freedom to inspect code. I could well understand if someone felt that they were very keen on the one freedom to inspect code, but couldn't bring themselves to champion the other 3. The problem is that many, many other people feel exactly the same way about all of the 4 freedoms. Not only do they not see particular value, but they are actively opposed to it.

I think you would fight a losing battle trying to implement this in a standard. In the same way that I couldn't realistically expect to convince most people to use the AGPL in their web projects, despite the obvious benefits that I see, you probably could not convince enough of the powerful players to do this. As a programmer, once you live in a world where this freedom is ubiquitous, it is obvious and even jarring when the freedom is witheld from you. As a decision maker protecting corporate interests, it is merely a matter of tradeoffs and the value is not apparently clear. Certainly, it is not something that most people outside of the programmer community would want to encourage as the default course of action, even if they are willing to engage in it as an exceptional case.

Of course, I would love to be proven wrong ;-)

I view the situation slightly differently: we now have a few examples of business strategies which employ open-source as part of a freemium sales model or for strategic commoditization. Such businesses can identify the subsets of code which qualify for one or more of the software freedoms, i.e. they have already done the legal groundwork for source-controlled separation into different asset classes. A "marketing standard" for View Source would let them earn incremental returns on the already-cleared code.

Github would have a lot to gain from such a standard, as they are already in the code history and metadata business. It could be prototyped with a browser extension, prior to standardization. In time, businesses will care more about software supply chain transparency, for open and closed code. A "View Source" standard could optionally request authorization before the source is made visible, e.g. from a private Github repo. The value comes from the run-time coupling of source and behavior, and it can be derived from source anywhere on the licensing spectrum between proprietary and public domain.

> A "View Source" standard could optionally request authorization before the source is made visible, e.g. from a private Github repo.

Or they could make a protocol to select which version you want to see: the webm or the plain JS. No need to mix external websites like Github in the loop.

A cultural solution, to me, sounds like the ultimate goal. But I observe that culture usually arises from the constraints that a society lives with.

I think many people would gladly opt-in to adopt the standard you proposed, but perhaps commercial projects won't have the incentives to do so.

Like the web itself, commercial companies will eventually come around. It can be the "new new" content marketing, since it's a small step from source-discovery to company-brand-discovery. Code becomes a proxy for author-reader connection, like prose.

We can culturally transform "view source" into a reputation metric that impacts visibility and revenue.

Look at the code snippets in the recent Bloomberg article, "What is Code", http://www.bloomberg.com/graphics/2015-paul-ford-what-is-cod.... Imagine a weekly NY Times list of Top 10 New Code, or Genius.com annotations, or CC-BY code comments which appear in search engine results, etc.

Society will increasingly care about coding, as writing code|prose influences thought, and more people will seek to understand the tools that make us as we make them.

Thanks for raising this important requirement.

Very interesting.

Are there any books/studies/examples of commercial companies doing something like this?

It's more of a vision than an observation :)

Web site easter eggs and job ads-in-code are a precursor, http://www.bbc.com/news/technology-25826678 & https://www.smartrecruiters.com/blog/the-5-most-creative-dev...

W3C has an Annotations Group working in this area, which includes commercial companies and educational institutions, http://www.w3.org/2014/04/annotation/report.html