Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment Re:First fix (Score 1) 1836

I probably over use this term a lot, and your comment made me realize I should probably substitute it for "moving on" where applicable. However, I don't think "forward" is the only way to move, when used in such a general sense. One could "take a step back" to examine the options, for example. Wouldn't this be an equally valid use of language? Disclamer: I am terrible at expressing thoughts as words

Comment My own Marvin Minsky story on neural networks (Score 2) 76

Posted here first this morning (couple of types fixed): https://ma.tt/2016/01/minsky/#...

Wow, sad to hear the news. Marvin Minsky and I were academic peers of a sort -- he was one of George A. Miller's first students, and I was one of George's last students. :-) George told my parents something like I was the student who most reminded him of Marvin Minsky, except whereas he spent George's Air Force money, I spent my father's money. :-) Which was not quite true (I paid for a chunk of Princeton with the proceeds of a video game I wrote and with some loans) but it sounded funny. :-) My dad was actually mostly a blue collar worker, and my mother only later in life worked for county social services, so George may also not have realized my family was not that well off financially.

I met Marvin Minsky once in his MIT office in 1985 as I was graduating from Princeton. I likely gave him a copy of my thesis -- "Why Intelligence: Object, Evolution, Stability, and Model". I also wrote to him once in the 1990s about getting computer time for space habitat simulations (he was responsive in a positive way, but then I met my wife and so just let stuff like that drop). And I saw him in passing about fifteen years ago when he gave a talk at IBM Research while I was a contractor there (he spoke about multiple simultaneous mental representations, and picking from the best one). A nephew of his even lived down the hall from me my senior year at Princeton in 1903 hall, too, but I never talked with him about his uncle. But we never really connected any of those times, sadly.

One of the biggest mistake I've made in my life careerwise (or so it seemed at the time) was when visiting Marvin Minsky in his office to talk to him about the triplestore and semantic network ideas in my thesis (stuff that indirectly helped inspire WordNet which George started as I graduated). I casually mentioned in passing to Marvin Minsky very early on in our meeting something about neural networks (MIT had a spinoff then of the Connection Machine), and I guess that may have put him in one of those mental states where some of the 400 different little computers activate. :-) I had not known then that he had essentially written a book (Perceptrons) to discredit neural networks (by only considering a limited version of them) to preserve funding for more formal semantic networks he worked on. He warned me sternly about how many careers had been destroyed by exploring neural networks. Another of George's students had found a copy of Marvin's original SNARC paper (what Marvin spent George's Air Force grant money on), and I can wish I had thought to take a copy to Marvin, as that might have set a different tone for our meeting, as it turned out Marvin had lost his original and wanted to reference it in his book "the Society of Mind" he was working on then.

So, instead of MIT, I spent a year hanging out in Hans Moravec's and also Red Whittaker's robot labs, and that was interesting in its own way. That experience also set me to thinking about the implications of most of the CMU robotics work being funded by the US military, which ultimately lead to my key insight about the irony of using robots to fight about material scarcity they could otherwise alleviate.

I sent Marvin Minsky an email in 2010, with a subject of "Vitamin D, computing, and abundance", warning about the health risks of vitamin D deficiency for heavy computer users. I also thanked him for his interactions with James P. Hogan, an author whose writings have been very inspiring to me (like Two Faces of Tomorrow and Voyage From Yesteryear), as James acknowledges Marvin in the first as a major source of ideas and inspirations, so some big ideas went from Marvin to James to me at least in that sense. :-) I also thanked him for being such an inspiration in years gone by. I had been reading through all the comments at a Wired article on "DARPA: U.S. Geek Shortage Is National Security Risk" and reflecting on my own career and inspirations, and thought I'd write to him. I told Marvin the biggest thing missed in that article is just that most computer jobs in the USA are not given much room for creative expression these days. And, sadly, much the same is true for academia for reason Dr. Goodstein outlines in his "The Big Crunch" essay (as do many other authors) which I also linked to. When you think about it, even as billions of dollars are being poured into proprietary software every year, and maybe a similar amount into academia, most programmers are kept on very short leashes focused on narrow project outcomes. There are very few projects like Mozilla or Chandler with a broad mandate (and when there are, they are often badly managed). When you think about it, for example, where is the broad support for creating better GUI libraries? Sure you can point to Angular or React as spinoffs of big corporations and they are getting most of the mindshare, but the very limited support for truly creative people like Leo Horie who made Mithril on the side in their spare time is more typical. Likewise, Notch and Minecraft got all the publicity and billions but Infiniminer and Zachary Barth, the source of key Minecraft ideas, get very little returns or support. Even Bill Gates learned by dumpster diving and reading the TOPS-10 OS listings and his MS-DOS was purchased as a ripoff of Kildall's CPM, which IBM may have known about and used Gates to stay at arms length from a suspicious transaction. Sigh.

I have since some to think that, short of improved subsistence via 3D printing and flexible home and agricultural personal robotics, or a radical change to a gift economy, or broad government grants totaling in the hundreds of billions of years to any programmer who asked, about the only thing I can think of that would really fix that situation of limited time for programmers to be creative, that would really give most programmers some financial freedom to innovate, not just a few (like Marvin) who manage (often by technical brilliance of a sort, and so seemingly "deservedly") to work their way up the social/funding hierarchy, would be a "basic income" for everyone. Then any programmer who wanted to could live life a graduate student their entire life (but without grad school restrictions like pleasing an adviser) and turn out free/libre and open source software. And others might choose to do other things with that freedom (have kids, teach, write books, paint, whatever). Most such creative programming projects would fail of course, but we might still see a lot of great innovative socially-useful stuff, where programmers would have the time to really support it.

I included in that email links to my Post-Scarcity Princeton writings. That email to Marvin Minsky was also when I first created my email sig, to, as I said to him, sum up the most important thing I've learned over the past 25 years by following the road less traveled (via CMU). :-) The version then was: "The biggest challenge of the 21st century is technologies of abundance in the hands of those thinking in terms of scarcity." I changed "thinking" to "still thinking" later to be a bit more optimistic. :-)

It is a sad day for us and his family, but Marvin apparently had one of the most fun careers of anyone I can imagine, so I can't feel too sad for Marvin himself. I am sad though that I said the wrong thing incidentally in his office and so never got to be part of that fun. But a deep question to ask is, how can more people have a fun and creative life like Marvin Minsky had?

Comment funding policies in automotive intelligence & (Score 1) 276

The below is from me originally from 2001: http://www.pdfernhout.net/on-f...

Although see also this idea from a couple of weeks ago: http://www.pdfernhout.net/pled...
====
Consider again the self-driving cars mentioned earlier which now cruise some streets in small numbers. The software "intelligence" doing the driving was primarily developed by public money given to universities, which generally own the copyrights and patents as the contractors. Obviously there are related scientific publications, but in practice these fail to do justice to the complexity of such systems. The truest physical representation of the knowledge learned by such work is the codebase plus email discussions of it (plus what developers carry in their heads).

We are about to see the emergence of companies licensing that publicly funded software and selling modified versions of such software as proprietary products. There will eventually be hundreds or thousands of paid automotive software engineers working on such software no matter how it is funded, because there will be great value in having such self-driving vehicles given the result of America's horrendous urban planning policies leaving the car as generally the most efficient means of transport in the suburb. The question is, will the results of the work be open for inspection and contribution by the public? Essentially, will those engineers and their employers be "owners" of the software, or will they instead be "stewards" of a larger free and open community development process?

Open source software is typically eventually of much higher quality ( http://www.fsf.org/software/re... ) and reliability because more eyes look over the code for problems and more voices contribute to adding innovative solutions. About 35,000 Americans are killed every year in driving fatalities, and hundreds of thousands more are seriously injured. Should the software that keeps people safe on roads, and which has already been created primarily with public funds, not also be kept under continuous public scrutiny?

Without concerted action, such software will likely be kept proprietary because that will be more profitable sooner to the people who get in early, and will fit into conventional expectations of business as usual. It will likely end up being available for inspection and testing at best to a few government employees under non-disclosure agreements. We are talking about an entire publicly funded infrastructure about to disappear from the public radar screen. There is something deeply wrong here.

And while it is true many planes like the 757 can fly themselves already for most of their journey, and their software is probably mostly proprietary, the software involved in driving is potentially far more complex as it requires visual recognition of cues in a more complex environment full of many more unpredictable agents operating on much faster timescales. Also, automotive intelligence will touch all of our lives on a daily basis, where as aircraft intelligence can be generally avoided in daily life.

Decisions on how this public intellectual property related to automotive intelligence will be handled will affect the health and safety of every American and later everyone in any developed country. Either way, the automotive software engineers and their employers will do well financially (for example, one might still buy a Volvo because their software engineers are better and they do more thorough testing of configurations). But which way will the public be better off:
* totally dependent on proprietary intelligences under the hoods of their cars which they have no way of understanding, or instead
* with ways to verify what those intelligences do, understand how they operate, and make contributions when they can so such automotive intelligences serve humane purposes better?

If, for example, automotive intelligence was developed under some form of copyleft license like the GNU General Public License, then at least car owners or their "software mechanics" would be assured they could have access to the software in source form to ensure safe operation. What might be "street legal" in terms of software modifications might be a different story -- in the same way people can't legally drive with a cracked windshield or a broken headlight. For example, software changes might need to first be proven safe in simulation before being provisionally "street legal". But, the important thing is, foundations or government agencies funding code development could insist on some form of free licensing terms for automotive intelligence as a matter of public policy.

There are many other areas of human activities that the exponential growth of technology will effect. Automotive intelligence is just one of them that is here now and which I am familiar with from tangential interactions at universities with people developing it. In enough time similar issues will arise for the software behind household robotics or intelligent devices that assist the elderly or handicapped. The IBOT wheelchair by Dean Kamen using complex software to balance on two wheels is just the beginning of such devices.

Note the IBOT wheelchair was developed entirely with private funds it seems, so the reasoning in this essay does not apply directly to it. Also, in general Dean Kamen is a role model of a socially responsible for-profit inventor. Still, the issue arises of whether "Johnson & Johnson" should be funding such development, as was the case, as opposed to, say, the "Robert Wood Johnson Foundation", as was not, given the public policy issue of whether individuals should be continually dependent for personal needs on proprietary software. In either case it would be worth it to pay billions for such innovation, and the public will pay that in the end as a toll on for such devices.

There is a real question here of how our society will proceed -- mainly closed or mainly open. It is reflected in everything the non-profit world does -- including the myths it lives by. The choice of myth can be made in part by the funding policies set by foundations and government agencies. The myth that funders may be living by is the scarcity economics myth. How does that myth effect the digital public works funding cycle?

Comment Re:More code audits needed? (Score 1) 136

No, only broken when used out of specification. RNGs have a lot of uses, not all of them related to cryptography. Generators suited for cryptography could be extremely unsuitable for other uses. Take for example the ISO-C random function. It is specified for reproducibility. There is even a non-mandatory recommendation to because they saw a use for a generator that behaved the same way on a variety of systems, for example when implementing sprite behavior in games.

If you implement cryptography and uses a RNG that isn't specified for it then it is your code that is broken. It's like using a CRC designed for sequential data when communicating over a framed protocol like RS485. It isn't the one implementing the CRC that is to blame, it is the one who applied it incorrectly.

..Quoting AC rated at 0 as the only reasonable response to this thread.. (Try 2 haha, oops)

Comment Re:Javascript? lol! (Score 1) 136

We are using JavaScript for performance critical code and I can confirm that it is the most buggiest, immature technology by far that I have ever seen in my 30 years old carrier. Every second month there is a new browser version for each browser, each with a different set of new critical bugs. We even find JIT compiler bugs regularly!

I simply do not understand why they do not take the free, open source, mature, very fast Java virtual machine, and let the browsers run Java bytecode directly, and let software engineers chose any programming language which best suits their task.

Not to come across sounding like "you're doing it wrong," but I found I had a fairly similar experience when I needed to produce some solid javascript (rather intensive real-time media/graphics in mobile web). It wasn't until I realized I was trying to hammer a screw (applying my knowledge of c/c++/Java/C# to my JavaScript code) that my experiences turned around. In short, a relatively small amount of your code should be exposed to browser specific bugs, to the point where most of it can be tested without any browser at all. This makes the browser bugs easy to plan for, and code around as if routine (the unstable bits are fairly well known at this point, I would say). I would suggest getting you some static typing with either TypeScript or the closure complier (I have only had experience with the later, to great results). Then get you some JavaScript Design Patterns, and some Functional JavaScript, and you are all set. Cheers and good luck!

Comment Re: Javascript? lol! (Score 1) 136

Do you have some realistic examples?

Also, approach-ability by "random" developers sometimes trumps something that's more flexible but requires more experience or a learning curve. Staff changes such that we often have to target "middle brow" abstractions.

Sure, since you asked... I find that functional programming is better for processing "data," while OOP is better for processing/handling "events." I also think there is a line that can be crossed where functional programming simply becomes a clever form of obfuscation, but overall, there is a lot of value in simple, repeatable, and easy to use constructs, which may be composed together to express the "idea" behind the code in fewer lines. I would say that readability and maintainability ranks #1 in my book of priorities, and functional programming helps very well with this in a lot of cases. Underscorejs is a good example of FP in javascript, if you're unfamiliar.

Comment Re: Javascript? lol! (Score 1) 136

In my line work, the coder maintenance effort is usually more of a factor than client-side-browser speed/memory, or even server side for that matter. Whether (good) OOP is inherently more resource intensive than anonymous function prototypes remains to be solidly proven. It may depend on coding style.

As far "simpler to parse", if that were the main factor, we'd all be using Lisp. Being human-friendly and being machine-friendly are not necessarily the same thing. Machines are generally cheaper than humans (code maintainers) such that economics often favors being human-friendly over machine-friendly (speed/memory). What I personally like is another matter; I'm paid to make my employer's org more efficient. (The database is usually the bottleneck, not the application, I would note.)

In short, I question how you are weighing the factors being compared. I agree that different niches emphasize different factors, but in general an application language (or usage) should favor humans over machines when you look at the total economics involved. Unfortunately, JavaScript is often being used for application development AND systems software (OS-like services and low-level libraries). One-language-fits-all is a tall order, and probably in impossible order if we want to optimize the language design for its actual usage patterns.

I shared this same opinion, but have found protipical inheritance (accompanied with static typing ala closure compiler) to be quite nice. In fact, it has made me more aware of how/when OOP constructs can provid actual value above a more functional approach (hint: it's not as often as you may think)

Comment An democracy needs confident people & good too (Score 2) 161

On ageism, it's not just whether programmers work, it is the quality of the work and the independence of the workers. Where might that matter? Consider the democratic need for programmers to follow ethical standards about privacy and democracy and openness and user empowerment (in their designs) that much centralized proprietary behind-closed-doors big data CS just ignores.

As I found in academia (for example in the PU CE&OR department in the late 1980s), when half or more of the graduate students in an academic department are foreign nationals being paid by their governments to get degrees, where when going back home without a degree would be a huge disgrace and maybe loss of career, the atmosphere of the place changes. That might explain why dealing with systematic financial risk was not a big topic at the time then.

So, if most programmers are nervous about their jobs with tons of H1Bs and cheap young labor, what effect is that going to have on taking a stand for important issues? And these are not just ethical issues, they are even issues like pushing back on inefficient or brittle designs, or designs users won't like, or whatever. It takes a certain level of confidence to do that (a confidence that includes knowing you can always easily get a job elsewhere, which may be true for a fifty year old civil engineer but is less true for a fifty year old programmer). And I'm not talking the brash confidence of youth or even a willingness for self-sacrifice like Snowden or Manning -- which is a different thing. I'm talking about a well-earned confidence in the context of a supportive community which is the basis of day-to-day successes by a democracy accountable to the needs of citizens.

See also:
"Smile or Die" (which discusses the financial crisis in part resulting from no one being able to point out systemic risks without losing their jobs)
https://www.youtube.com/watch?...

And:
http://conceptualguerilla.com/...

And even my other post here mentioning John Taylor Gatto who talks about compulsory schools as being designed specifically to shape compliant workers.

My latest folly is based on remembering what computers and our democratic culture were like in the 1970s and 1980s, is to want to help create software that respects a citizen's needs for private data controlled locally and shared peer-to-peer (like via email) instead of a typical web business' needs (like Slack or gmail) to centralize and control other people's data: :-) Here is that project:
https://github.com/pdfernhout/...

I started that with the news that Mozilla, supposedly about internet freedom and privacy and user empowerment, is going to kiss off Thunderbird, meanwhile billions of dollars are poured into the web space to make the opposite of Thunderbird (and some of those dollars are going to Mozilla in a way as a conflict-of-interest). See also my post here:
http://it.slashdot.org/comment...

The USA should be funding thousands of people to work on such FOSS tools. Meanwhile, Thunderbird suffers for lack of a funding model. Volunteers and open source go together well -- but relying on volunteers is problematical when you have literally one gigabyte of legacy C++ and XUL source code that need to track every security issue in Firefox.

If this was really about increasing interest in computers, just give green cards instead of H1Bs, insist on overtime for programmers, require every employee have a window (like in parts of Europe) and do basic stuff like that. It might also help if we reduced the churn in "new" technologies that are often not as good as the old one (still waiting for something a lot better than 1980s Smalltalk, for example). Getting rid of software patents would also be a big help in the USA, as would reducing copyright scope and duration to make building materials more available.
http://www.it.slashdot.org/sto...

Comment Another John Taylor Gatto in the making? :-) (Score 1) 161

See: https://archive.org/details/Th...

And: http://www.newciv.org/whole/sc...

More links on how schooling is not about education, and how schooling is a form of (prison-like) adoption:
http://p2pfoundation.net/John_...
https://www.youtube.com/watch?...

Check out John Holt, too. That's all a big reason we homeschool/unschool.

More links: http://p2pfoundation.net/backu...

Enjoyed your informative post from the trenches, thanks! Especially your point about teacher incentives. You get what you measure -- so, as you imply, if you incentivize teachers to dumb down kids faster and better, that's what you'll get more of.

Long term, I feel a basic income may be part of the answer:
http://www.pdfernhout.net/towa...

As for what you can do in the short-term, it's tough. If you walk away, your (virtually adopted) kids will suffer. And you'll lose your income in a tough economy.. And one less voice for change in the system will be lost. But it's a painful situation if you care about what you do (although you run a high risk of burnout). Don't know what to advise, but at least you are not alone! :-)

Comment Sprint for Thunderbird webapp proof-of-concept (Score 1) 388

AC wrote: "We've lost the arms race for content over presentation in this medium. Pages with perhaps a kilobyte of text take over a megabyte to download and 10 seconds to render. Firefox is mortally wounded. Safari and Opera are hobbled. Chrome is a trojan horse. Guys, I think the Gopher people were right."

This is a very insightful AC post. That is a big part part of why for the last week (since hearing about the Thunderbird uncertainty) as a sprint, I've been working towards a webapp / server called Twirlip as a proof-of-concept for a server version of Thunderbird. The idea is to support the same functionality as Thunderbird (and more) but use standard Firefox as the client loading a Thunderbird-like webapp from a local Node.js server. The project repository is currently here:
https://github.com/pdfernhout/...

The sprint is not "blessed" by Mozilla or the Thunderbird Council at the moment. It is just my own take on things and to demonstrate what is possible. And given I just blew all our cash/credit writing another FOSS project (NarraFirma, a webapp in TypeScript/Mithril/D3 with Node.js and WordPress backends) over the past year or so, financially, this is so stupid for me to be doing right now instead of finding a paying job. :-)

That said, the leader of the Thunderbird Council (Kent James) suggested in September considering making Thunderbird into a webapp, so the idea is not completely new, or presumably unwelcome as a proof-of-concept demo:
"Future Planning: Thunderbird as a Web App"
https://mail.mozilla.org/piper...
"As we are discussing our future, both in relation to radical changes expected in the Mozilla platform, and our need to express where we are going to potential partners and donors, we need to discuss and agree on some big-picture issues. One of those was end-to-end encryption that we discussed recently. I want to discuss here our future platform, and how it related to users and their needs.
tl;dr Thunderbird over the next 3 years needs to convert to being a web app that can run on any browser that supports ES6 Javascript and HTML5. (web app does not imply cloud-based, only that the underlying platform is js/html)."

Here is an update on my last week's progress sent to the Thunderbird Planning list.
https://mail.mozilla.org/piper...

I've used Thunderbird for over a decade, and have a million messages in it totaling over 15 GB (mainly from a bunch of mailing lists). I know of others who have 50 GB in it. So, I'm obviously concerned about its future.

All that said, there is no immediate reason to panic. Thunderbird still works well for what it does.

In looking into this issue though, maintaining Thunderbird is apparently difficult though because the codebase includes a copy of Firefox, which bloats the source code by 20X or more up to about a gigabyte of mostly C++.Any security patch to Firefox needs to be evaluated and then likely integrated into Thunderbird to keep it secure. That may be the biggest issue -- and it is worse now that Mozilla has essentially defunded Thunderbird over the last few years to make it a "community" project, so synergy has been lost with the Firefox development team. (SeaMonkey, formerly the Mozilla application suite, is in the same boat and uses essentially the same codebase.) Thunderbird itself also has a lot of XUL to define UI functionality, but Mozilla has deprecated XUL (not reasonably, but there are consequences) creating an obvious future maintenance issue of sizable proportions. Thunderbird plugins likewise are written with XUL. So, while Thunderbird can be maintained, given that codebase and the size and the need to closely track Firefox, maintenance is hard and probably not a lot of fun (given the C++ and XUL) as a legacy thing.

As others have said, this is a big amount of "technical debt". And Mozilla is less and less interested in helping service that debt, let alone pay it off. So, what energy is available in the Thunderbird community generally needs to go into maintenance and not new ideas. Maintenance is important, but may not happen long-term without substantial funding given the scale of the issue. That commitment to substantial maintenance of that gigabyte of source code might happen though if a foundation concerned about democracy or privacy got behind Thunderbird as-it-is. Frankly though, as much as I feel free and open source is the way to go, it is really a full-time job to support big complex applications, and that effort should be funded somehow, whether by grants, donations, or other means including perhaps someday a basic income.

An alternative though is to re-envision Thunderbird somehow, like Kent James suggests. That is like deciding to build a new house next door because the old one has too many issue to fix cost-effectively. Disentangling a gigabyte of C++ and XUL is probably not going to be much fun, and given the nature of C++, will almost certainly lead to security issues and lowered stability for a time. But long-term, any issue in Firefox is potentially then a know and exploitable security vulnerability in Thunderbird by a maliciously-crafted email.

Ideally, both maintaining the old Thunderbird and building a new Thunderbird could be done with enough money or volunteer energy. Even with other email clients out there, given over 100 billion emails are sent every day, email is very important to modern society. There is a more general information access issue as well that AC wrote about. Thunderbird should not have to languish for lack of support on the order of millions of US dollars a year when billions of dollars a year are getting poured every year into proprietary web sites like AC implies that just make knowledge harder to access.

By the way, see comments at the next link from a few months ago about how unhappy Firefox (not Thunderbird) developers are with recent Mozilla decisions about XUL and plugins. Unfortunately, Mozilla has not invested in tooling to make migration from XUL to standard DOM easy for plugins and there are other complicating issues well as other issues related to locking down Mozilla plugins more.
https://blog.mozilla.org/addon...

That all means is the pool of people who remotely care about XUL is going to quickly shrink.

Here are comments by me on why Mozilla should reinvest in Thunderbird as-it-is and as-it-might-be as part of supporting peer-to-peer technologies like email
https://groups.google.com/d/ms...

From an equity issue too, it is unclear to me what percent of Mozilla's previous donations received are due to Thunderbird and the email part of SeaMonkey?

Overall, the current situation is not a healthy one for Thunderbird as-it-is given the expected upcoming maintenance costs (like having a house that needs a new roof and a new foundation and a new septic system all at the same time). However, that situation could change overnight with a commitment from a foundation or some other source. Houses do get fixed up all the time even after having incurred a lot of maintenance / technical debt. But new houses get built too. And our society is so wealthy materially we should be able to afford *both*. It is only ideology that gets in the way, leading to so many resources to instead go into creating the problems AC bemoaned (in part from unbridled competition and quests for de-facto vendor lockin, such as now with Slack and before with gmail or ymail and Facebook and MySpace and so on).

As this 2008 Slashdot article on what the now-current Executive Director of the Mozilla Foundation said back then when a Shuttleworth Fellow:
"Is Open Source the Answer To Giving?"
http://news.slashdot.org/story...
"Mark Surman, Shuttleworth Foundation fellow, writes that open source is the answer to philanthropy's $55 trillion question: how to spend the money expected to flow into foundations over the next 25 years. While others have lashed out at 'Philanthro-Capitalism' -- claiming that the charitable giving of Gates and others simply extends power in the market to power over society -- Surman believes that open source shows the way to the harmonious yin-yang of business and not-for-profit. Sun, Microsoft, Cisco, IBM, Yahoo, and Facebook are big backers of Creative Commons; Mozilla has spawned two for-profits. Open source shows that philanthropy and business can cohabit and mutually thrive. Indeed, philanthropy might learn from open source to find new ways to organize itself for spending that $55 trillion."

So clearly, the existence of resources is not the problem here. It is the allocation of resource to the important issue of email and peer-to-peer information exchange in general.

As I see it, Mozilla has a fundamental conflict-of-interest between relying on commercial partnerships with big companies like Google or now Yahoo which to support Firefox (funded by them to access proprietary social media and commercial search engines) and obtaining funding for peer-to-peer software like Thunderbird which provides an alternative like AC (and I) prefer.

So, as I see it, given what Mark Surman wrote in 2008, he and/or Mitchell Baker (Executive Chairwoman of the Mozilla Foundation and of Mozilla Corporation) could be approaching a lot of foundations to increase support for the Mozilla mission for peer-to-peer. Here is a list they could start working through: :-)
https://en.wikipedia.org/wiki/...

But first they need to acknowledge this conflict-of-interest in relying on a big centralized web company as a funding source when you claim to be interested in promoting privacy and data security and individual empowerment on the internet and reflect on it, rather than just kiss off Thunderbird (which actually supports all that!!!) as a concept (even if the current Thunderbird implementation needs refreshing to deal with accumulated technical debt).

Slashdot Top Deals

Regardless of whether a mission expands or contracts, administrative overhead continues to grow at a steady rate.

Working...