> "Both agents declined to comment for this article, but according to two people briefed on the investigation..."
What are the odds the "two people" are "both agents"? That's like the lamest off the record attribution ever. Also amazing that some random agent using Google broke the case. Apparently anyone could have figured out who DPR was.
> Apparently anyone could have figured out who DPR was.
I think that's the most interesting part. Obviously not just everyone would have the knowledge that he would log in as DPR from a coffee shop a few hundred feet from his apartment, but they could still place him as a strong suspect based on his posts as altoid that identify himself and mention Silk Road. Something that even the FBI didn't do.
I tried to use google to find his post as altoid to no avail. Maybe it was taken down.
I thought the config error was debunked by his attorney. I think the question many people have is if parallel construction was at play and if TOR is compromised.
The FBI argument was 'leaky CAPTCHA'. The defense argument was that the application was hacked. The most likely scenario is an info leak or debug page as Ross was known to live edit/debug the application.
This evidence wasn't tested in court on 4th amendment grounds since the defense didn't demonstrate ownership of the server:
buttcoin.com reported on the leaked ip when it happened, long before it was brought up in court. buttcoin.com was bought by butterfly labs and shut down when they had their assets frozen but dailydot reported on it here: http://www.dailydot.com/news/silk-road-ip-address-leak-drug-...
> As ever, responses to this news will largely fall into two categorizes: those who believe that the U.S. — and other governments — should do everything within its power to find and apprehend criminals; and those who feel that the government is again running roughshod over privacy rights.
This is a false dichotomy. If you care about apprehending criminals actually responsible for crimes you should care about this too. A reoccurring subtext is that law enforcement cares more about quantity than quality, but data quality is hugely important. These dragnets are the equivalent of a House TV Series body scan, and the arguments that characters in the show made apply here.
One of the consequences of a dragnet and too much low quality data is the risk of circumstantial evidence leading to the conviction of the wrong individual. The minds of investigators and district attorneys are susceptible to all the biases that plague any other field including confirmation bias. Project Innocence has revealed heaps of wrongful convictions based on low quality data, even when police corruption wasn't at fault. Dennis Fritz and Ron Williamson for example were convicted for murder based solely on bad circumstantial evidence while the real perpetrator remained unpunished for over a decade.
It's not just privacy advocates who should care about stopping these kinds of surveillance techniques. That is unless the dragnet apologists don't care about who is being punished for crimes just as long someone is punished whether or not they actually committed a crime.
You're right, it is a false choice. But before we get to discussing that, we should first be considering whether there's a choice that needs to be made at all.
I personally am far from convinced that law enforcement has a significant problem with locating fugitives. I may be wrong with this, but I haven't seen anything concrete to dissuade me from those views. How often are such location services actually needed, and what are the consequences of not having them available?
I'm not a particular fan of pie charts or donut charts, but the visualization used in this tool is actually helpful at understanding and comparing nested amounts.
The reason I don't usually like pie charts or donut charts is because it is difficult to make comparisons between circular shapes. In most places people use a pie chart, I think a bar chart would be better. It's easier to compare different lengths of rectangles than guesstimate differences of pieces of pies or half circles.
Something about this type of visualization with nested depths seems to be an outlier. If this information was portrayed in rectangles I'm not sure it would be better.
Yeah, I generally agree about pie and donut charts. I thought about unrolling this one, so that the inner most circle would just be one long bar, and each successive step would just be an adjacent bar. I'm not sure that makes it better (and might make it worse, since the whole thing might end up being really tall).
There might be a clever way to do this with a tree map, but it wouldn't be particularly intuitive to read.
I've been going back to cash instead of using credit cards because I've been exposed twice now via Target and Home Depot. I want to even avoid using ATMs and go into the bank to get cash because you can't really even tell when an ATM has a malicious card scanner installed.
Once we have automated cars maybe we'll go be back to walking and riding bikes to avoid being victimized by remote car jacking.
Imagine the mess hijacked delivery drones might cause.
Your phone can be cloned remotely. You can't easily clone a rotary phone that plugs into the wall.
I'm definitely not looking to automate my home, especially after reading how Chinese hacker had installed back doors on wall mounted AC devices or whatever which had access to the internal network at the New York Times building to keep infiltrating and reinfecting all the machines on the network.
Maybe we jumped into the digital world a little bit too quickly.
Serious question - why do you very concerned if your credit card number is stolen? By law, credit cards have > 30 days (I forget the exact amount) of fraud protection as long as you report it. The only downside I can see is the pain of getting a new card. Your money really isn't at risk.
That said, I do agree that security is becoming a major issue in our world.
Yeah there are laws, but you have to catch it, and you have to report it and sometimes you don't realize you've been defrauded until months later. Hackers in my experience don't empty your account out, they charge $30 here, $19.99 here, sign up for this thing for a monthly charge of $9 you didn't realize. My time and stress costs me. And you can lose money.
It's best to just not have to deal with it. My credit card number has been put up for sale twice now, twice. Because I used it at a Target and a Home Depot. Ok, I just don't want to go through that again. I don't care if there are laws, if I use cash, I'll be fine. It's no problem, cash is accepted everywhere. I'm not likely to be mugged where I live and I don't carry a lot of money.
The aggregate pain and aggregate loss of using cash for transactions in a credit-card dominated world is much larger than the concentrated pain of replacing a credit card once a year. I make significantly more than $30 here and $20 there on rewards - on the order of $500+/year
Sign up for Mint, and quickly scan all of your transactions on a monthly or bi-monthly basis. It's a good idea anyway, so that you can easily account and keep track of how well you're doing at saving.
> The aggregate pain and aggregate loss of using cash for transactions in a credit-card dominated world is much larger
I have not found this to be the case.
> Sign up for Mint
I don't intend to increase the available surface area for attacks by giving my credit information to a third party. Nor do I need this kind of a monthly or bi-monthly hassle.
Eh, I don't view it as a hassle - I view it as a progress check. My savings is important to my future, and checking the budgets, etc. helps keep me on track.
Point taken on the attack surface area, that's definitely something I've always been worried about, and I have no counter.
It's a nightmare sometimes to cancel credit cards, especially if you're travelling.
There are some banks that simply won't cancel the card until you visit your local branch. A tricky maneuver when it's 2000 miles away (I don't know if they've changed this now). Likewise, there are things that are hard to find if you use your cards a lot and don't keep detailed receipts on everything you buy. This happened to me when I discovered someone's been deducting a small sum from my card for several months without me noticing as I was overseas. Of course they could only take care of the last charge before cancelling my card.
I have never heard of a credit card that couldn't be cancelled immediately by calling the number on the back of it. That's the whole point -- when a card is stolen, it has to be deactivated on the spot.
What bank would ever require a visit in person to deactivate your current card? That would be insane, since the bank would simply be opening itself up to more losses, since it (and not you) are responsible for fraudulent expenses.
It was actually a credit union. And yes it is crazy, but then so are a lot of their other practices. Also, I was calling them internationally so even though the private questions they asked me verified my identity, it was still an arduous process. The number of times I called to finally get the card cancelled actually made my long distance charges greater than the stolen value ($25).
NextStep was built with enterprise in mind but became wholly consumer in its next life as OS X and then iOS. The massive consumer success of the iPhone led to employers giving in to employees who wanted iOS devices instead of Blackberry devices, a phenomenon called BYOD, "bring your own device". BYOD has given rise to an entirely new Apple presence in enterprise which I think Apple is just getting started with. Prior to this Macs were used by designers and engineers, creators, but hardly the stuff of serious enterprise.
Right now the services Apple provides are all about fulfilling features that consumers want: email, cloud storage, being able to buy content, and apps. They're meant to augment and also perhaps cynically lock consumers into Apple's sphere. The hardware devices sold at high margins make the money. This may change, and we might also see a two Apples where apple starts selling its services with higher margins for enterprise.
Incidentally long ago Apple really dominated in education. Most of the 80's Apple IIes and macs were popular in K-12, but that went away in the later 90's. Now iOS, in the form of iPads, are making inroads in education once again, competing with Chromebooks. Education isn't enterprise, and I don't see any services Apple would offer schools, but it's related.
Almost every where you look though, Microsoft is under assault. I think the last remaining stronghold is the Windows PC workstation. I don't think Apple, Linux or Android have made any inroads here. I can see Chromebooks becoming more relevant in the future, but for now workstations are dominated by Windows and probably will be for the next decade. The enterprise level services Microsoft provides here with ActiveDirectory and sharepoint, and the sophisticated controls for deploying Windows workstations across big organizations is pretty unrivaled. Maybe RedHat is also in this space, but not at the level of Microsoft.
Just a nit pick, BYOD is when a employee brings his/her own device to work in order to use it to do work. At some places it's viable to let employees choose the tools that work best for them, and not force every employee onto the same 6 pound HP or Lenovo or Blackberry.
New and improved provision schemes will make this even more viable in the future, where applications and data that belongs to the employer can still be kept reasonably secure no matter who owns the hardware.
It's an interesting area. I don't think BYOD has the rosy future the breathless posts on LinkedIn will have me believe. The problem is one of security. If I'm going to enforce security on a device I will need to wipe/reset the BYOD phone and apply my enterprise policy (password on start, device encryption, find-my-phone, remote wipe and so on).
At the other end of that equation you have a consumer who has a shiny new phone, and is being asked by her employer to yield control of the new shiny to the enterprise. Not appealing, when said consumer foots the bill for the phone, data and calls.
That conflict will result in CYOD (choose your own device), I think. And if we get a company phone, will mean we walk around with two phones. One fore work, locked down and able to access corporate email and SharePoint, the other for play, which has no corporate policy applied to it and only has Internet access.
> If I'm going to enforce security on a device I will need to wipe/reset the BYOD phone and apply my enterprise policy
Which is exactly what happens in a BYOD scenario and the process is getting better for both employees and employer. For example, my employer can now "wipe" all my corporate data on my iPhone while leaving all my personal data intact. Of course, as long as I have their data the security policy (password on start, device encryption, etc) is enabled.
We do have CYOD but we only facilitate the connection between the employee and the provider -- the employee owns the device. Mobile devices are very personal things and nobody wants to carry two of them.
I have been using fastmail for a month now after switching from gmail. I quite like it, but the two drawbacks are that it's just a little bit more likely to let spam in than gmail, even with aggressive spam options enabled, and with fastmail I'm missing out on the growing gmail ecosystem (Streak, Dropbox mailbox app, others).
It's fine though, I really am happy to be paying for an email service instead of depending on Google. I am quite happy with everything else. Really easy to set up and integrate. Works well with Android's email app and Mail.app. The webmail isn't terrible but I just use it to report spam. Having an Android app now is super exciting.
We're talking to Dropbox about mailbox app - hopefully it will support us soon, as with everything it's a matter of engineering resources.
We're also talking to many companies about a better API for everyone - the draft spec is at http://jmap.io/ - it's based on the API that our app already uses.
That's great to hear. Regarding the Android app having just checked it out, my first request, if you're taking them, is multiple account support. I can only log into one fastmail.com account at a time with what is here now. The reason I have two accounts is because I have two domains that get emails. Otherwise seems like a solid app. I'll probably start using this as my calendar app. :)
http://jmap.io/ seems pretty awesome, I guess I can use that to build my own fastmail app integration?
> That's great to hear. Regarding the Android app having just checked it out, my first request, if you're taking them, is multiple account support. I can only log into one fastmail.com account at a time with what is here now. The reason I have two accounts is because I have two domains that get emails.
Yep, its high on the todo list for a future update.
> http://jmap.io/ seems pretty awesome, I guess I can use that to build my own fastmail app integration?
JMAP does indeed look very interesting. In my (very, very slow) path towards writing my own email client, I've also come to expect that a new, simpler protocol is probably a better bet than imap. Partly this belief is bolstered by the fact that the creator of sup went on to make heliotrope: https://github.com/sup-heliotrope/heliotrope
[ed: I suppose the canonical repo is https://github.com/wmorgan/heliotrope -- but afaik they are the same (and both appear dead)]
Is the code on: http://jmap.io/server.html actual code? If so what kind? Lua? It'd be great if you could publish some test cases, even if you don't have implementations to go (open source) with it at this time.
I'm sure fastmail can bring a lot of real-world testing and experience to the table when/if designing a new protocol for email -- and I'd be very surprised if we actually need more than one... (at least considering we already have smtp, lmtp, pop3, imap and maildirsync over ssh, along with rsync/unison -- that cover a lot of use-cases already).
Regarding heliotrope: wmorgan has left the field a long time ago to our great despair. He did start heliotrope, which I hacked a bit because it looked cool. I even started a heliotrope-to-imap bridge [0]. After a while the community decided to create a common repository to host them, at which time I abandoned heliotrope because its client was still too buggy and sup was already working very well, and I needed a working MUA.
So the current state is: heliotrope kind of works, the client a little less, we are now fully working on sup. If you want to hack on heliotrope though, feel free to ask -- but there will most likely be no code from me.
Sup, on the other hand, works like a charm ! Visit us at supmua.org !
I think I'd probably gravitate more towards notmuch and friends, if I were to use a (in notmuch's case, almost) "ready to go" mua. However, I've yet to find a mua that's simple enough, and also does what I want (Steve Kemp's lumail is another interesting project[1]).
So far, the back of my envelope contains clojure, or possibly something else[2] that is pleasant to code in and feasible to both get to run (well) on Android and in the console, possibly web and/or desktop (GUI, that is -- not a great priority for me, but "advanced" features such as displaying image attachments in-line could be nice -- and is a natural fit for Android anyway), and a sync (possibly push) solution.
It's in the sync part, that heliotrope and jmap come in -- mostly as an alternative to either making my own, or just trying to shoe-horn everything into couchdb/puchdb etc.
Personally I don't really need IMAP (as I control both the server and the client), and I'm unsure if it's worth the effort; maybe with some clever hacks like sticking some meta-data in "special" mail-folders...
Other than that, I suppose caldav/carddav can handle contacts (or perhaps make an embeddable ldap-thing... but like imap it sounds like overkill...) -- the only remaining problem is quick search, which means good full-text search, which means multi-lingual stemming etc... mostly I'm thinking the server should do the indexing, and the client should be able to sync both index and content. Tricky part is making it incremental, so I can keep X GB email with full-text search on the server, and not need a significant % of X GB space on the Android device to get off-line access to the last month (or whatever) worth of email along with good search over that subsection...
[1] http://lumail.org/
[2] So far my short-list has clojure (pleasant, start-up time and possibly resources seem to be a (real) issue on Android), kawa scheme (try to keep the interesting stuff in somewhat "standard" scheme, either use kawa scheme everywhere, or try to stradle two scheme implementations...) and kotlin (it's a better java, but not sure if I'd call it pleasant).
You must be aware that notmuch is only the search backend, and for a full MUA you need frontends. I believe the official one is the Emacs one, so it should be fairly usable. There's also a web one [0] you should be able to play with.
Another contender in the space (label- and search-centric) is mu and its ui, mu4e [1]. Something else to have in mind.
Now if you want something that works on desktop and mobile, something worth a look would be using SQLite and its built-in full-text search... see how far you can go with that. SQLite is available pretty much everywhere, Android even allows full-text search. Now what you have to do is synchronize SQLite dbs. It "shouldn't" be too hard to remove old emails from the db so you can keep X MB worth of it. You can even shoehorn it into couchbase-lite [3][4] so that sync is automagically taken care of.
JMAP looks cool (definitely more interesting to implement than IMAP) but it seems to be more a query API than a sync API, although there are facilities to "get changes since last time" (a HUGE improvement from IMAP as deployed everywhere). OTOH if you can shoehorn it into couchbase-lite, you can use a generic sync protocol that can be used for other things too (caldav/carddav).
Heck, you've piqued my curiosity, I see something doable here. I'd love to hear more. I might even hack something just for fun.
Hm, we're too deep it seems. So replying to myself.
> You must be aware that notmuch is only the search backend, and for a full MUA you need frontends.
Absolutely. I tried to imply that with my wry parenthesis; but it's absolutely worth pointing out clearly to unwary readers. In no way is it fair to either notmuch or sup to compare the two as equals.
I'd probably lean towards mutt-kz[mk] for an out-of-box "notmuch" mua (but... mutt. Meh ;-) There's also "alot"[a].
> Another contender in the space (label- and search-centric) is mu and its ui, mu4e [1]. Something else to have in mind.
> Now if you want something that works on desktop and mobile, something worth a look would be using SQLite and its built-in full-text search... see how far you can go with that. SQLite is available pretty much everywhere, Android even allows full-text search. Now what you have to do is synchronize SQLite dbs. It "shouldn't" be too hard to remove old emails from the db so you can keep X MB worth of it. You can even shoehorn it into couchbase-lite [3][4] so that sync is automagically taken care of.
I've considered sqlite for some of these reasons. But couchbase-lite != sqlite, right? (Or does it use sqlite in a meaningful way; ie: can/should one use sql to interface with the stored data?). Btw, looks like you're off-by-one, in your references ;-)
If using sqlite, there are a couple of schemas one might use for inspiration, such as dbmail:
The main sticking point, is do we really want(need) to re-index everything everywhere, how do we transparently do search local-first, while supporting hits from the server along with fetching hits/mails that are missing locally (what k9 calls "cloud search") - how do we consolidate/sync data (the two hard things in computer science is caching and naming things...).
I'm not entirely convinced sqlite+built-in full text search is the best approach (I envision a useful search across some gbs of mailing list threads -- not convinced about the ranking -- but I could very well be the victim of premature optimization. And I'm a little wary of abandoning maildir for storage (on the server) -- but that might be useful anyway.
> JMAP looks cool (definitely more interesting to implement than IMAP) but it seems to be more a query API than a sync API, although there are facilities to "get changes since last time" (a HUGE improvement from IMAP as deployed everywhere).
Yes, that's pretty much what I gathered from the heliotrope story, that syncing was a bit of a mess.
> OTOH if you can shoehorn it into couchbase-lite, you can use a generic sync protocol that can be used for other things too (caldav/carddav).
Exactly. All the hard work done! For free! But seriously, couchdb was born from the ashes of lotus notes, and at least in spirit it was made for this kind of stuff... so couchdb sync, and some kind of half-assed search might be the way to go (on the server, elastic-search would probably work fine... not sure about on something like Android).
> Heck, you've piqued my curiosity, I see something doable here. I'd love to hear more. I might even hack something just for fun.
Great :-) If you do, please feel free to drop me an email (see profile).
Right now we don't have a lot of real JMAP code. FastMail's implementation technically isn't JMAP. To write JMAP we took our current protocol and filed off a lot of the pointy edges. We're working to update our own implementation, and we're also working on open-source reference servers and clients.
Note, that if you send a subscribe email, you'll be subscribing the from-email in the mail you send (I usually subscribe with unique addresses to lists and accounts, so that I can more easily see which are harvested/given away for spam abuse. So far linked-in, and adobe are top (the latter presumably due to the big account leak) -- and that's a bit of a hassle as all email clients suck ;-).
Not yet. We're working on a small server and client to act as a reference implementation, and there are longer-term plans to build it directly into Cyrus. We're also planning to do a proxy that you can put in front of any IMAP server to make it talk JMAP.
Mailbox App gets access to and copies your Gmail server-side. In addition Dropbox has Condileeza Rice on its board. So for people switching to Fastmail out of privacy concerns, don't bother. It would be better if we users would ditch Dropbox and Mailbox App (which I love, so not easy for me to say) in the same spirit we want to ditch Gmail.
with fastmail I'm missing out on the growing gmail ecosystem (Streak, Dropbox mailbox app, others).
While I have no doubt a better ecosystem around would be appreciated by some, the ecosystem thing as a whole is a double-edged sword.
I personally fled the Google-sphere because I felt I was gradually getting locked into something non-standard, non-portable.
These days I'm very hesitant to using non-integrations which aren't strictly needed. For instance: I prefer to create a proper user-account over "just" signing in with Facebook or Google.
I properly own my own domain and email-address. My Google or Facebook-account not so much.
Edit: To be clear, the value-add for me is that fastmail isn't some non-replaceable thing tied to an ecosystem, but a standards-based service provider which I can mix and mash with other best of breed-services as I see fit.
I have the opposite complaint, Fastmail marks my bank receipts as Spam, but I don't mind at all.
My bank probably is dumb enough to send newsletters, promotions and other spam-like mails next to notifications, statements and other not-spam-like mails from the same sever, also, Spanish is like a third-class citizen over the Internet, so I got accustomed to the language barrier.
Well it's patched now, but it didn't affect you unless you were running a "Windows Server" although all recent operating systems were affected. If your Windows machine is behind your home router and you were not forwarding ports to it you're probably fine. I doubt this vulnerability was known well enough that enough people were scanning for vulnerable IPs to exploit them.
The window from disclosure of patches to duplication is narrowing and it appears from the bulletin that client connections are affected as well. Furthermore any computer you take anywhere outside your home router (and can you really trust your home router as security boundary nowdays?!) will be easy to manipulate into an SChannel connection. Inside your home network, clients are still vulnerable to attack - any javascript/flash ad/referer can point a computer behind a router at an attacker server and serve up malicious SChannel packets. That is to say your home computer can be attacked on outgoing connections which your router will be happy to allow.
ssh into a box that is set up to use tor, install squid, set up firefox to use your squid/tor box as a proxy. Your home is no longer broadcasting that you're using tor. Your box could be outside of the country.
>It's a nice concept but I'll start using it as soon as someone creates a FOSS clone.
I like FOSS, and am grateful for the work open source engineers put into software, and I have also contributed, but this attitude right here where you wont even consider something because it's closed source? What's the point of that? Why shouldn't an engineer be paid? It's very difficult to capture value with open source software. Please explain to me how they could monetize this on par with the effort put into developing this and still have it be open source. This isn't a service that runs in a website, this is something you download and run.
Can't tell for others, but I'm very reluctant to spend time learning a tool that I know from the beginning I won't be able to debug / improve later and that the owner may change in a way that doesn't fit me or even stop to support.
The only non-FOSS tools I've been using on a daily basis for years are Gmail and Google Calendar. I can't tell I'm really happy with how they have evolved out of my control. Oh, and Google Reader — you know what happened to it…
And it's really not about money. I'd be happy to pay a developer for some tool I use everyday if asked for. I already pay for music under CC or FAL.
How do you charge for something that can be freely redistributed? How can I charge you $50 for software that you can then take and give to everyone for free because of the open source license? Where are people going to get that software from? From me where it costs $50 or from you where they can get it for free? The GNU website says you can charge for distribution, but that was written back when people distributed CDROMS. Now that it's all over the internet, that model doesn't work anymore.
You put binaries up for download, charge $50, and anyone can pay you the $50, take that binary and legally redistribute it for free. Or they could just take the source and build it for nothing and do the same thing. Talk to me about the economics of making that viable. Please, because if you can I would love to do it that way. I would prefer the source code I write to be open source, but I have to eat and my children have to eat and we need to pay rent, and so I have to capture the value too. Software firms with modest sales can't afford to lose a dime they make, so how could they go FOSS?
Thank you for your reasonable perspective. This open source criticism seems particularly endemic for developer tools that aren't backed by a cloud service. There are very, very few companies that have made money with open source tools in this space and they typically require huge VC investments to get to a place where the product is good enough to warrant large enterprise support contracts and professional services.
Commercial licenses and training. This may not be FOSS, but it can be open source. Or you can have a partially open source product with some closed source extensions, like JetBrains does.
Even paying for software doesn't guarantee they are going to keep the product the way you like it (OSX, Windows).
This attitude seems to think that open source is some magic wand and that it will be around forever just because it is open source. Open sourced code falls by the wayside all of the time, so I don't think this really matters in the scheme of things.
Some did not like Gnome 3, they created MATE. Some found GCC was too conservative, they created EGCS. And MariaDB. And LibreOffice. And ffmpeg… And…
That's how you guarantee software will continue to fit your needs in the future. It's not paying for Microsoft Works that made people able to open *.wks files with Microsoft Office when Microsoft discontinued the former office suite (though they are some converters available). But it's open-source that made people able to open TrueCrypt files with CipherShed when the developers gave up.
Even at my level, I'm able to tweak the tools for my needs. The last version of zsh is not available on AIX? I can build it myself (and send the fixes upstream). Vim doesn't provide the feature I want? I can add it (and who cares if it's not yet merged upstream? it still does what I want it to do, now).
With FOSS software, an enterprising and capable individual always has the ability to modify/update/or other wise change the software to suit their needs.
I find your line of thought to hold little weight.
Sure, and the parent I was replying to said he is happy to pay money for software he uses. I don't see why paying for closed source software (to encourage the dev to keep developing it and also to allow you to comment on what to improve) is a bad thing just because the project is not open-source.
Misunderstanding here (bad wording on my part): what i meant by "it's not about the money" is that the advantage of open source is not that it's free, I'm happy to pay, but in the other values which the person i replied to mentioned.
shouldn't he? EDIT: fixed bad wording. sorry, English is not my native.
> Please explain to me how they could monetize this on par with the effort put into developing this and still have it be open source.
paid closed-source plugins supporting enterprisey protocols, paid support, custom functionality. these are from top of my head, so pretty sure wirefloss devs could think of something as well.
And who is really going to do that? Do I have time at my day job to port some network packet editor to the platform of my choice? Is management going to fund such an effort, or are they just gonna pay for the app?
If your management sees it as an opportunity to advance, why not? It's about having the ability to do so vs not having it because somebody else decided this for you.
They can release the free version as FOSS and release the paid version as closed source. I don't see how he would make any less money with an open source free software compared to a closed source free software. He's already said how he would monetize it, by offering a premium version with support like REHL. Also, I would not mind at all to pay a fee to use the normal edition and access the source. Free means libre, not gratis.
This is actually a good example. There are no linux ARM builds available, which makes this product useless for me. A lot of closed source software (cough sublime text cough) neglects the less common processor architectures, while with open source software I can usually just compile it myself.
I didn't say it wasn't but a build for a very recent Ubuntu the build is useless. Also it doesn't work for XP for which there can be no technical reason.
What are the odds the "two people" are "both agents"? That's like the lamest off the record attribution ever. Also amazing that some random agent using Google broke the case. Apparently anyone could have figured out who DPR was.