You're playing semantic shell games here. The user has no reasonable way of knowing that stripe.js came from stripe, and as such, there are no technical OR human controls that enforce that behavior.
In short, the fact that stripe.js is delivered from stripe DOES NOT MATTER, because the user CAN NOT reasonably validate this behavior.
I know you're not dumb over at Stripe; I have a hard time believing that you're not willfully lying. After all, "disrupting" onerous industry security standards is to your competitive advantage.
I run my own mail server and it's essentially zero work. I have postfix, dovecot, SpamAssassin, and RoundCube, all authenticated via LDAP.
It required some upfront configuration, but it has run itself with minimal configuration changes and 'apt-get' updates for almost 6 years now. I never touch it, and it works.
> It's not just the configuration, your service will always be subpar. At least until there's a good webmail (I have high hopes for Mailpile).
That assumes that user's want to primarily use webmail. In this renaissance of Mac OS X mail clients and mobile phones, that hasn't been the case here.
Mail hasn't changed much in more than a decade. Systems like Ubuntu update cleanly from release to release. Maildirs are very easily migratable.
You can literally set up a new mail host, and then rsync the old Maildir contents -- aka, all your user's e-mail -- onto your new host, whenever time permits, without disrupting mail delivery or reading. User's historic e-mail will simply gradually fill in.
If your VPS disappears, or hardware failure occurs, or user error strikes -- simply restore your Maildirs on a new system from your backups (tarsnap works great!).
This documentation is long and thorough, but once you know what you're doing, setting up a basic mail server, even manually, should only take you a few hours at the most.
> I don't claim that it's a particularly easy problem to solve, but it seems to have been done when people just used a mailing list and cvs, so it is possible...
It worked back when we had a mailing list, CVS, and a web page because a single individual or set of individuals owned the top-level project infrastructure associated with the name in question.
Github broke that model by making forks largely non-subsidiary to the projects they fork. They exist at the same namespace, they have independent bug tracking, wikis, and author information.
This breaks the social economy of contribution that previously existed; even if you choose to not participate in Github, your project will be forked hundreds of times via published Github-based mirrors that look like every other top-level copy of the project.
I like 0MQ a lot, but this is disingenuous. Let's break it down:
> portability
Sockets are just as portable, more so on UNIX descendants where one can rely on relatively consistent socket APIs. Beyond that, almost every single language and runtime (Python, Ruby, Java, OCaml ...) provides a portable socket API.
> message framing
Length-prefixed message framing winds up being 10-100 lines of code in almost any language/environment.
> super fast asynchronous I/O
Sockets have this.
> queuing
Sockets have buffers. The OS can use those buffers to implement flow control. This isn't the same as queueing, but the truth is that you rarely want blind background queueing of an indefinite number of messages that may or may not be delivered.
> support for every bloody language anyone cares about
Just like sockets.
> huge community
I don't think you can get 'huger' than the community around sockets.
> price tag of zero
Seeing as socket libraries ship with everything, does that mean they have a time/resource cost of less than zero?
> mind-blowing performance
Also, sockets.
> protection from memory overflows
This has essentially nothing to do with a networking library. Plenty of environments have safe/efficient zero-copy chained byte buffer implementations/libraries.
> loads of internal consistency checks
Library correctness isn't a unique feature.
> patterns like pub/sub and request/reply, batching
Ah-ha! Here finally we get to the meat of it!
If you need QUEUES, including pub-sub, fanout, or any other QUEUE-based messaging structure, than 0MQ is better than sockets!
> and seamless support for inter-thread transport as well as TCP and multicast
Inter-thread transport of already-serialized messages at the transport protocol layer doesn't make a ton of sense from an efficiency perspective.
> ZEROMQ IS JUST SOCKETS
No, 0MQ is a lightweight network message queue protocol. It's not competing with sockets.
> However, you're essentially taking it as a given that the absolute number of worthwhile projects has dropped thanks to GitHub.
Not just dropped -- they're drying up. I can only speak from anecdote (nobody has paid me to run a study), but while I've seen no dip in usage of my libraries, and I've seen my projects explode with half-baked forks on Github, I've seen mailing list participation and worthwhile code patch submissions drop to very nearly 0.
> What does, for example, Sourceforge get right that GitHub doesn't?
SourceForge essentially died out for modern projects upon the release of Google Code in 2006.
However, what (traditionally) SourceForge and Google Code did right -- and, what projects did in their own hosting for decades before and after that -- was place the project's community in the forefront, and the code in the background.
This meant that documentation, releases, mailing lists and other constituents of a vibrant community project were placed in the forefront, with the code being something that one worked on as part of the community.
By contrast, Github made projects secondary. The code was (originally) always attached to an individual account name. The primary project page was the code itself. Forks existed at the same namespace hierarchy as the projects they forked.
The result was that Github sucked community energy into Github itself, and in doing so, began to redefine the community social constructs in a way that allowed users to maximize social and personal rewards while minimizing work necessary to conform or participate in the project's community.
> There are no-fewer quality-obsessed developers participating in the community as a result of GitHub.
There is natural attrition of participants in any project; what keeps (or kept) so-called "quality obsessed" developers in abundance were the social structures -- and social currency -- of the communities built around open source projects.
In exchange for stature, learning, and intangible satisfaction, contributors would learn project guidelines, interact with project members, learn to meet the required levels of quality, and over time be subsumed as committers and trusted members of the community. This approach sustained open source for roughly 20-25 years.
However, github's social network structure supplants the traditional communities, instead creating a wholly Github community in which the previous social construct (and social economy) can no longer truly thrive, and instead, the community and social focus is redirected and reinvested in Github itself.
The similarities to the reward mechanisms and value feedback mechanisms of social networks like Facebook are quite strong.
> It sounds to me like you miss the "good old days" when the club was more exclusive.
This seems to be a recurring theme; it sounds to me like justification for cognitive dissonance borne out of a situation where two choices exist:
1) Subscribe to the notion in which one would be a junior contributor in a broad pre-existing world of established engineers, or
2) Ignore the experienced engineers and create a community of self-evaluating peers, writing off the old model as "exclusive" rather than "experienced".
I expect the truth is found in-between those two poles, but reality has trended strongly towards number #2.
1) The internet and the apps built on it still run just fine.
There is very little maintainership and investment in core difficult technology development. Most core projects that make up the foundation of the internet subsist on the oft-dwindling maintainership of what you seem to consider to be a legacy generation of engineers.
Outside of areas where companies hold direct commercial interest, many core technology projects are withering or stagnate. There are an infinite variety of new JavaScript frameworks, however.
2) Hundreds of thousands of usable and awesome open source projects available to use and contribute to
We're reinventing wheels at a prodigious pace, but your comment demonstrates and underlying shift in the opensource mindset that Github has invoked. Whereas open source was previously something to be produced as a stable, reliable entity, and consumed by users, it has instead become an expensive participatory process for all comers, in which stability and reliability and even documentation is discarded in favor of quick fixes and local patches and increased expenses for the entirety of the ecosystem.
3) More people are getting their code out to the world than before Github.
It's the conceit of every generation that they exceed the previous, but this statement (and the implication that this is due to Github's introduction) is simply not true.
Renaissance? Open source has never been less healthy. All the previous social constructs around properly documenting, testing, and releasing stable versions of your code have been swept away.
Instead we're faced with the constant churn of semi-functional code, users working in silos and then showing up with patches well after it's too late to give them direction, animated GIFs instead of careful engineering discussion.
Github optimized being lazy, and this was appealing, and in doing so they broke most of the technical and social structure that held together open source's ability to produce reliable, stable, well-documented software.
I've watched stable projects either wither and die or become commercialized, and now instead we live in a world of rolling mostly-broken hacked out releases (if there are releases at all), a confusion of forks (which one is the 'real' one?), while animated GIFs and "oh snap" responses permeate our bug trackers.
In short, the fact that stripe.js is delivered from stripe DOES NOT MATTER, because the user CAN NOT reasonably validate this behavior.
I know you're not dumb over at Stripe; I have a hard time believing that you're not willfully lying. After all, "disrupting" onerous industry security standards is to your competitive advantage.