I don't have mod points right now, so thank you for taking the time to write a sensible comment on a very fraught topic. :)

An irrevocable patent pledge is intended to be precisely that; it's a legal document that is written to carry weight regardless of changes of ownership or management. Whether it will stand in court when tested remains to be seen, but that problem applies also to free content and open source licenses and other legal tools for sharing of information and ideas. KA can be expected to at least do one thing, which is to use the best available legal tools to create a broader framework of reuse consistent with its mission. It should reach out to experts, such as Creative Commons, to determine which tools to use, rather than relying on a weak implementation drafted by Twitter.

KA can also reject the idea of patents entirely. It has enough goodwill globally that any patent lawsuit against it, aside perhaps from highly protected areas such as video codecs, would likely to be suicidal for the entity bringing it, and a fundraising boon for KA.

Although Blackboard has filed patent lawsuits against competitors (and was briefly boycotted for it), it at least has issued an irrevocable patent pledge not to sue open source projects. I suspect ignorance, not foul play, on the part of Khan Academy is the cause.

Ironically, nonprofit Khan Academy's Twitter pledge is less permissive than that of the corporate behemoth, since it reserves the right to sue anyone, for any reason, provided company and "inventor" agree. Not sure OIN is a good fit for its needs given its close tie to usage of patents within "Linux systems". Something like CC's model patent license or a simple, broad pledge never to use patents offensively against anyone may be a better fit.

KA's policy error here is likely the result of swimming in the Silicon Valley ideological soup, where Twitter's pledge is considered remarkable. KA has never been an especially awesome organization when it comes to open source citizenry. For example, it uses the "non-commercial use" restriction for its materials, which is widely rejected within open source and free culture circles like Wikimedia, Linux, etc. Hopefully this will change over time as the organization becomes more aware of the policy discussions around these issues, since a lot of its work is otherwise excellent and world-changing.

As the summary states, Khan follows Twitter's patent pledge. This is a good first step as far as it goes, but it still explicitly allows for offensive litigation if the "inventor" agrees. That's not sufficient. At the very minimum, Khan should adopt a clear, irrevocable policy never to enforce patents against open source projects, like many Patent Commons participants. Ideally it should partner with Creative Commons to work out an even stronger patent license, consistent with its mission. CC has previously developed model patent licenses and I'm sure they'd be happy to help.

If the Khan Academy user who originally posted in Slashdot in response is reading this -- please bring these resources to the attention of management.

Videos/podcasts and similar formats are definitely not for every setting, but they do allow you to get to know a person a bit better than a simple transcript does. In a video, you can see a person's facial expressions, you can hear emphasis, and you may be able to make more of an emotional connection. For a podcast, you can listen in the background, during your commute, etc. Each format has its advantages/disadvantages.

I agree a transcript would be awesome though; sorry that I've not gotten around to that yet (I do these in my spare time and suggested to Roblimo that he might want to run a shorter version). If you want to help, I've set up an Amara import here. In general, Passionate Voices is a community project (the videos are under CC-0, i.e. free to reuse), and help is always welcome, including with doing itnerviews.

A few days ago, Sumana released this video, Pipeline, a critique of the tech industry's treatment of women. It's relevant to the overall discussion re: hospitality and worth watching (the main point being, "getting women into tech" doesn't really solve any problems if the actual experience in the industry is a terrible one).

Thank you for giving it a spin and reporting back, glad your tests worked. :-) Our policy is to not execute JS at all on older browsers like IE6 and IE7 (for security and maintenance reasons), which has the side effect of keeping us honest in ensuring all core features work without JavaScript.

Hey gl4ss, these are fair points, but I stand by my original estimate, including overhead & travel. A couple of things to keep in mind: 1) Although WMF is based in the SF Bay Area, it is a non-profit, there are no bonuses or stock options, and base comp is good but not as high as you can get elsewhere. We also hire internationally and our teams often include remote folks in regions with different pay scales. For positions like community liaisons, we often hire younger folks who don't get quite as high an hourly rate as an experienced engineer would. 2) Yes, managers need to get involved, there are meeeetings, etc., but our engineering managers tend to be responsible for pretty large groups (20+ folks) since teams working on user-facing features have their own dedicated Product Managers and most of the day-to-day decision making exists at the team level. This reduces the risk of micromanagement and keeps managers focused on supporting teams rather than getting in their way. 3) The delta in compensation between engineering managers and engineers is not as high as you might think.

Hi TuringTest, thanks for your comment! Contrary to your past tense, Flow continues to be in active development, and continues to be deployed to new use cases, most recently a new user help forum on French Wikipedia, and a technical support forum on Catalan Wikipedia. Since the only way to roll out a system like this is to replace existing use of wiki pages, we're proceeding conservatively to test it out in social spaces where people want to try a new approach, and improving it in partnership with real users in those venues.

It's true that talk pages, being ordinary wiki pages, support "making your own workflow". I love the Douglas Engelbart reference, though I doubt Engelbart would have remained content with talk pages for very long. The lack of a discrete identity for separate comments makes it impossible to selectively monitor conversations you're participating in (you literally have to use diffs to know what's going on), or to show comments outside of the context of the page they were added to. This is a pretty tough set of constraints to work with. At the same time, you're absolutely right that a modern system can't simply emulate patterns used by web forums or commenting systems like this one.

Like wiki pages, Flow posts have their own revision history. Flow-enabled pages have a wiki-style header. Each thread has a summary which can be community-edited. Threads can be collapsed and un-collapsed by anyone. All actions are logged. In short, wiki-style principles and ideas are implemented throughout the system. At the same time, we believe that as we add modern capabilities like tagging, we can replace some of the convoluted workflows that are necessary in wikitext. Already, Flow adds capabilities missing from talk pages -- notifications for individual replies, watching specific threads (rather than a whole page), in-place responses, etc. More to come.

Hello metasonix! First, congratulations on the successful article submission. In answer to your question, I was referring to LQT development. LQT was put into maintenance mode in early 2011, so of your "10 plus year project", about 7 years elapsed with a little bit of paid effort dedicated to the development of LQT. $150K max spent (not all of it by WMF) on LQT is really a high estimate -- Andrew Garrett, the only dedicated developer, also worked on other projects during that time, including the widely used AbuseFilter extension.

Flow development kicked off in summer 2013, about 18-19 months of development effort so far by a team that's fluctuated in size but currently comprises three full-time engineers, about half a person's time for UX design and research, a product manager and a community liaison. During that entire timeframe, I would estimate money spent on the project so far at less than $1M. Even if you combine both efforts, "millions of dollars spent" is pure hyperbole, and adding up elapsed time to exaggerate scale and scope of these efforts is equally misleading.

The article summary speaks of "millions of dollars spent" on a new discussion system for Wikipedia. The article actually tells a very different story -- the LiquidThreads extension started out as a Google Summer of Code project, was funded for a while by an interested third party, and then received a little attention from the Wikimedia Foundation (one designer, one developer) before development was put into maintenance mode. I would ballpark the total money spent around $100-$150K max. Elapsed time does not equate money spent. LQT continues to be in use on a number of projects, but its architecture and UX needed to be fundamentally overhauled.

Flow, the designated successor to LQT, continues to be in development by a small team, and is gradually being deployed to appropriate use cases. It is now running on designated pages in a couple of Wikipedia languages, and old LiquidThreads pages are being converted over using a conversion script developed by the Flow team. Contrary to the article's claim, WikiEducator upgraded to a recent version of LQT, and will be able to migrate to Flow in future using the conversion script.

You can give Flow a try in the sandbox on mediawiki.org and see for yourself whether the article's claims are hyperbole or not. Disclaimer: I am the person referenced in the headline of the Wikipediocracy article, so take my view with a grain of salt, as well. ;-)