There's a frequent misunderstanding when people talk about freedom with respect to the GPL. The concept of "freedom" is itself not well defined, and historically there are at least two competing and somewhat opposing definitions, "positive" freedom (which is about maximizing the amount of things people are able to do) and "negative" freedom (not interfering with things that others want to do). The GPL is primarily concerned about the former, and your complaints are about the latter.

The goal of the GPL is that everybody can use the software for any purpose, and learn how any changes and modifications work; this is seen as a requirement to increase the amount of things that can be done with the software, guaranteeing that it can be adapted to any hardware or platform, with no commercial secrets getting in the way.

In order to achieve this goal, the GPL doesn't come "free" (as in "gratis", i.e. no cost): it has a cost that you must pay if you want to use it; but for anyone willing to pay it, there are no further restrictions imposed by anyone, for any modified version. In your case you *could* have merged your application code with the GPL library* for any purpose**, but you should be willing to pay the cost, which is to release your own source code when you republish the software. So, your negative freedom is reduced (you are forbidden from keeping your version of the software hidden and publish just the binaries), but the positive freedom of the system is increased - overall there are more people who know how to use your modifications and adapt them for other uses, which couldn't happen if you kept your modifications secret.

The expectation is that by adding contributions from many users to the pool of knowledge, the whole society sees an increase in the amount of possibilities to use the software ("positive freedom"); it's the same principle that motivated the patent system in the Renaissance. The "release what you know" cost is intended to publish knowledge that otherwise would not be shared, and thus cumulatively improve the whole system. Now, there are valid concerns that the upfront cost may instead work as a disincentive to participate in the system (both with patents and copyleft software), but that argument doesn't make less free.

* Assuming the original license and copyright law allowed it. (This is why the FSF recommends using only GPL-compatible licenses).
**(Including selling it, although with FLOSS software this typically only works once for each release).

In contrast, I've always thought that the primary concern was towards the interests of the software.

I agree with your view, but that terminology is anthropomorphizing an inanimate object, which IMHO makes it difficult to understand the benefits of that approach. If GPL achieves "what's best for the project", few people will care.

I've been recently describing what's good about the GPL by highlighting the knowledge about the software.

Compared to other FLOSS licenses, the GPL/copyleft ones, are the ones which best protect users interest to learn how the software-as-a project-works. Permissive licenses which allow users to close the source of their forks provide more individual freedom, at the cost of losing the knowledge about those published forks; with copyleft, that knowledge is preserved.

As you see, the logic of my explanation is the same (you maintain everything in the project), but providing a concrete reason why users of the software should care about keeping it evolving in the public sphere.

Convenience trumps ideals more often than not.

Ideals are not there to achieve convenience. They exist to steer us away from convenience, to avoid short-term gains that would push us into some long term dead-ends.

So ideals are not useful because we live by them on a day to day basis, but because they warn us when we deviate too far from them. Of course, having a few idealists that *do* live by their principles is a useful reminder for the rest of us that agree with them, but are nonetheless swayed by convenience.

Remember the Ubuntu phone? Remember what people were excited about regarding it? Notice how it hasn't been achieved due to various business cockblocks, thus leaving the gate wide open for someone bigger to step in? Hint hint.

Actually, there are a couple Ubuntu phones. Bq's Aquaris E4.5 was launched last month in Europe. (It's not the flagship device the Ubuntu Edge was suposed to be, but rather a semi-budget offering). And the Meizu MX4 Ubuntu Edition is a mid-range device.

Software testing doesn't protect against a user pressing the wrong button, which then works as expected. I agree it's a management error, but the failure in such cases is a lack of user testing.

Systems should be designed to follow the interactions that are more likely to be made by users, not the other way around - forcing users to follow the path that a developer thought would make sense. Unfortunately, user-centered design is still a foreign concept to a good chunk of developer houses.

Or you can blame the idiot designer who didn't properly explain the consequences of "doing this" in their black-box interface, so that the user could make an informed decision.

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.

However, a core property of wikis -that the structure of the page can be edited in any shape without the need for programming- is missing. Flow is a threaded conversation system by design, and only a threaded conversation system - it can't be tweaked by their users into something else, and the sequence of comments is shown in order enforced by the tool. All discussion regarding how the tool could be generalized to support other kind of collaboration workflows or those basic needs such as reordering and merging comments, which are trivial to make in the basic wiki "everything is a stream of text" model, were dodged or delayed to be studied at future "more complex" use cases. That didn't provide any confidence that those needs were understood by the design team.

I find your post interesting, and your points in many ways are an accurate analysis of many major problems with Wikipedia - yet I still find your point 11 ("The wiki is the problem") a non-sequitur. A wiki is in essence a model for data storage, where the expectations for interaction and data management are closer to control versioning than to the classic CRUD cycle. As such, it's a neutral tool that could be used in many other ways and improved to cover most of the current shortcomings; in particular, there's no reason why those other "practical solutions" and workflows for organizing content couldn't be built on top of a wiki-like storage layer, so the contradiction you see doesn't exist in essence.

The problems you mention are for the most part caused by the community dynamics and rules, with a few caused by the current wiki platform, rather than the wiki storage model itself.

The only point directly related to organizing things as a wiki is point 6, "Page ownership" - which is a real problem, but only exists because of the decision to build an encyclopedia where each page is an article that can be edited by anyone, not because the tool for storing the page is stored a wiki system. Every other point is caused by the project's original view as an anarchist playground which permeates all its policies, not any inherent limitation of the software.

-----

As for the approach taken by newslines.org, I agree that there's a need to give visibility to contributions from any user without giving the next editor in the line the possibility of removing them completely without trace; though that doesn't the benefits of a wiki.

Newslines is good for news-driven topics, but there's a need for an encyclopedia-like description of the topic, that a list of unrelated news doesn't cover; there needs to be a coherent wording that describes the highlights of the topic and how each part relates to the whole, and a wiki page covers that need. Compare the pages for Ebola at Wikipedia and at Newsline - which one would you prefer for first learning about the disease, and which one for staying up to date with recent developments? It's clear that they serve different, complementary purposes.

I've been following the development of Flow, and it's definitely not hyperbole.

The problem with Flow is not that it's not a valid talk system, it's that Wikipedia talk pages are not mere talk system. Even if Flow was the niftier, most standard, most boring talk software, there were needs in the ways that the users actually use the software that were never addressed in its design, and which caused all the backlash.

Wikipedia talk pages are based at their core on a wiki system, and wikis are the closest thing to the original vision of a hypertext made for "augmenting the human intellect" - it's the purest native digital way to store information for collaborative authoring and communication; it's the equivalent of clay for modelling thoughts, and Flow was a mere striped notebook. Flow took the power away from their users, and the users revolted.

Flow might have been an interesting tool to be used on a different new project, but was a poor fit for the existing user base, who were already used to a more powerful and flexible tool.

In other words, the computer was unable to learn to distinguish beautiful people from ugly people.

Why should it do that? It was not the purpose of the experiment.

The future of fine art. Ugly pictures because those are the only ones not generated by an algorithm.

You've just described all the *ism movements at the beginning of the XX century. Your clock is 100 years late.

Now all pictures will tend to be the same with the algorithm telling the amateur photographer how to frame the shot.

You say that as if it was a bad thing.

ÂBlock (read as "micro-block") has smaller memory footprint than AdBlock (and therefore Adblock Edge), and can use the same major privacy lists (EasyList, EasyPrivacy, Peter Lowe's Ad Server).

Why do we want semi transparent smart devices?

Take a look at augmented reality.

There are over a hundred different altcoins by now. What makes this one so different that it's Slashdot-front-page worthy?

It has hit Slashdot front-page, therefore it has got exposure to some high profile geeks (or it would, if there were any high profile geeks left reading Slashdot).