Live data from Hacker News

Email Encryption Software Relies on One Guy, Who Is Going Broke

propublica.org

361–370 of 469 posts

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#361

Earlier quoted context omitted.

There's no general answer to your question. It's like game theory, depends on the players and context (technical, legal, financial, market maturity). Juce and PyQt were created by single developers, so it's not impossible. Staking out and defending a niche would be a prerequisite, open-source or proprietary.

Is there a list of specific answers? I don't even know of all the ways one could organize a project. I suspect that might generally be the case for a lot of people, too. Publishing and promoting a project is a completely different skill set from developing it. It feels like the majority of developers default to thinking of "release open source" or even just "release" as meaning "publish on Github with the MIT license…

The basic recipe for software biz success is the same whether proprietary or libre. ~80% of revenue comes from ~20% of customers and features. Ship something into the market somehow anyhow so you can identify the critical 20%. Then you can commoditize (open) the remaining 80% of features to reduce costs and help the long tail to become self-supporting. Pricing and defending and growing the revenue features is then like any other business, i.e. strategic conflict with other mice who will come after your cheese.

"Open" is as much a state of mind and development practices as it is a license. JIRA shipped with full source code while remaining proprietary. This removed customer concerns about JIRA going out of business, no need for source escrow. Customers ended up making modifications to the source, which then influenced the Atlassian roadmap. Conversely, one can have an open-source license, but a dev culture that rejects external input, e.g. Calibre. If a vendor focuses on business goals first, then creates a culture to support those goals, license choices will become clearer.

There are useful history lessons among these links:

1) Free Software Business mailing list archives (1993 to early 2000s), http://www.crynwr.com/cgi-bin/ezmlm-cgi?iis:0:201311#b

2) Self-publishing docs+screencasts with 90% royalties, earned railstutorial over six figures in a market where most technical books are lucky to earn $10K. Relevant to OSS biz models: https://news.ycombinator.com/item?id=7350265 & screencast toolchain: https://news.ycombinator.com/item?id=8932387

3) Bootstrapping 101, http://discuss.bootstrapped.fm/ & http://www.startupsfortherestofus.com/

4) ISV (Stardock) 2014 report, http://www.stardock.com/press/CustomerReports/Stardock2014.p...

Resources on business models:

5) The Business Model: Theoretical Roots, Recent Developments, Future Research, 2010, https://noppa.aalto.fi/noppa/kurssi/23e21090/luennot/23E2109...

6) Free Software and OSS Business Models, 2008, http://www.springer.com/cda/content/document/cda_downloaddoc...

7) Any good book on organized crime / unregulated business. Boundary conditions inform risk management, i.e. early recognition of failure scenarios to be avoided.

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#362
post #76

Earlier quoted context omitted.

Wrapping the command line should be a little bit safer from a security perspective, since a memory exfiltration bug won't transfer across processes. Just don't use the shell between the wrapper and the command.

Is this really the case? I recall that proper library support is slow-coming, not because of security model concerns, but because "doing it right" takes more time / money that there is in GPG development at the moment. EDIT: For example, I believe that it would require rewriting a lot of code, and that means said code would need to be audited to make sure no security bugs were introduced. It's "easier" to just wrap t…

I'm sure you're right, but because of this "laziness" we get a slight security boost at the cost of a slight performance loss.

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#364

Earlier quoted context omitted.

Why in the world would this be downvoted? There is nothing inflammatory about this post at all. He's bringing up a widely debated point in our industry.

Probably because we're talking about encryption software ITT, and nobody would trust closed source encryption software.

> nobody would trust closed source encryption software.

ORLY? Have you read much source for BitLocker or FileVault, recently? WhatsApp? Skype? And those are just the most popular ones off the top of my head...

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#366

Earlier quoted context omitted.

https://www.fsf.org/about/financial The FSF had revenue of 1.25 million in 2013. I'm not trying to comment on where it came from or where it went to. I'm only pointing out that they are not in a very similar position.

So… enough pay for about 20 developers?

In India? Do you know how expensive developers are? (Especially fully loaded, ie with all the overhead that a company has to pay.)

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#367
post #12

It's a sad day when Farmville can become a billion dollar business and Werner can't feed his kids. I'm curious if he's truly living on ~$20k/year. That seems ridiculously low for life in Germany. Or if he's got other sources of income to bolster that. Either way, what really needs to happen is companies that build programs off his work need to make a concerted effort to donate to the project. Heck, set aside a small…

I personally know lots of people here in Germany living off 20k/year and less. More would be better, but it's doable.

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#368

For bitcoin donations, you can go to [1], which gives the address as 12LKeo24XCzgz6ASSxcUa8BvUfzkEyCpGq [2]. The address is not generated per user, and is dedicated to GnuPG. [1] https://www.wauland.de/en/donation.nojs.html [2] https://blockchain.info/address/12LKeo24XCzgz6ASSxcUa8BvUfzk...

Thanks. Way easier to donate 0.5 bitcoin than it is USD.

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#369
post #357

Earlier quoted context omitted.

You are right that we, as a community, are really bad at supporting key open source infrastructure. But I also think that relying on donations from individuals like us is a fundamentally wrong model. I don't benefit directly from GPG, but I benefit from many services that make use of GPG and make lots of money off of me.

I completely agree that the services and companies that rely on those technologies should also contribute. But as a software developer, I use openssh daily in my job. I use tmux, I use nginx, I use openssl and a lot more opensource projects and they allow me to make a living. So, it makes sense for me to contribute.

I don't disagree at all, but as you say, you do those things in your job. It's likely that you also use them outside your job for personal purposes, which is why I agree that it makes sense for you to contribute. But most employees don't (and shouldn't) feel like it's their duty to pay for the tools they use to do their jobs.

Re: Email Encryption Software Relies on One Guy, Who Is Going Broke

#370
post #64

Earlier quoted context omitted.

You are using Ubuntu, I see from your profile. How much have you paid them? This is how the stories goes: we haven't figured out how to make good work worthwhile. Perhaps we can learn something from our vast experience in profitably peddling shit?

We're our own worst enemies. Software developers have this sort of circular firing squad where nobody wants to be the first to keep their source closed and try to charge for it. Because then you're just "greedy" and not pure enough. But that'll never change unless all of a sudden we say "Ok, on the count of 3, everybody stop giving away their hard-earned expertise for free. 1... 2... 3..." We're like musicians nowada…

> where nobody wants to be the first to keep their source closed and try to charge for it

Seems like there's another option -- open source your project and also charge for a license to use it. By open sourcing people will trust it more which will cause its value to go up. And then more people would be willing to pay for it.

Post reply on HN