1x52: Immensely Deft

But… there’s nothing wrong with that, right? Just because I’m not applying new fixes to an app doesn’t mean that I didn’t do work to make it exist in the first place.

This is the main problem I have with closed source software. If someone else wants to pick up maintenance of your project when you’ve washed your hands of it, it should be easy. I believe in someone getting paid for their work, but I also think that good software should be maintainable. And if I’ve paid money for your software, I expect it to keep meeting the needs I purchased it for, especially if you’re still selling it.

One could make an argument against new features falling under this rule. I’d argue that bugfixes and usability issues do, which makes the open source software choice easier for me. “The SLOW licence” would prevent us all from having either one of these arguments.

Past frustrations may have come through too strongly in my sarcasm. Apologies for that.

However part of the DPL process should be an evaluation of your expected return on investment. And by the time the source code goes public you should have made your money.

Because

  • it would avoid a situation where you still need to make money from an app you no longer support (which has a negative impact on your reputation and your ability to convince people to buy other apps from you); and
  • there’s always a better programmer around the corner who could very easily take your open source code, build a better app, and steal your customers from you (which would have a negative impact on your feelings towards the DPL and reduce the likelihood of you using it again).

During the discussion in the podcast it was clear that the DPL was intended for projects where the initial developer worked independently and did not expect to maintain the project long-term.

1 Like

Mm… perhaps. Personally, I think, if you’re paying a pound, then what you get is what there is. If it doesn’t meet your needs, delete it and choose something else.

At that price point, I’d agree. If the app is feature complete as of that moment, then sure. But the list of apps and programs I’ve paid a buck for (pounds don’t go as far here in the states :stuck_out_tongue_closed_eyes:) is pretty slim. Admittedly, the list of complaints in my personal workspace on this is also pretty slim, since I usually either bias toward open/free software and donate to projects that provide value, or pay for quality. But there’s a lot of very expensive applications in the OSX landscape that provided value, have fallen out of maintenance or been entirely abandoned, and are still being sold at high prices by their creators.

As I mentioned before, I definitely wouldn’t hold this to be true for feature requests specifically. I don’t expect a dev to add functionality to an app that was considered feature complete when I purchased it, even if I want that functionality. But I would like bug and security fixes, and general assurance that the software can be maintained at it’s current state as best as possible, even as time marches on. Again, I have to steer away from the Linux landscape for most of my examples, but you’d be surprised how many expensive pieces of software just quit working permanently whenever I upgrade my work MacBook. Knowing that I or someone else can pick up and keep the software working after the original creator has lost interest would put my mind as ease when dropping $20-50 on an application that might fill a critical need in my daily workflow.

I want to shower great developers in money to keep doing what they do. For now, that gets restricted to open software creators who give myself and the community the power to keep things going. More adoption of a SLOW license model would give me more options in the market, and options are good.

The selling-open-source-software model works well enough for synergy (synergy-foss.org, the 1st example that came to mind). I think if you’re not a huge company with demand enough to support multiple resellers, you can sell open source code for at least a fee that people consider worth not having to compile/build a working install themselves for (for source that needs that).

General market forces are of course in play; customers will also pay a bit (more) for reliability and reputation, so being the one place to fetch updates from first etc., or that is well-aligned to the buyer’s goals, has value. A few people care about supporting further development/fixes if they’re invested in the software, or just for that warm glow; buying from someone else not invested in the software doesn’t give them that (if amazon started selling open source code would you get a warm glow - I mean due to it being amazon not due to it being open source :smirk: ? ). So to resell it and survive, I think you either need to provide better value than the original source (could include being an active developer on it/their own fork or just providing support) - or be much louder/more discoverable. All good things for your software, if not directly for your ego, and small projects need all of that even more so than big ones. All that takes work, and why shouldn’t people get paid for that work if they want to? (you can’t copy-paste that effort :smile:)


If I’m talking nonsense, feel free to tell me, but please do so politely and constructively

Or be free. The issue here is this: imagine any Ketchapp game on phones. Free to download, but lots of ads; that’s how Ketchapp make money. If the game were open source, then I could just compile it and upload it as “Game Name (no ads)”. Yes, some people will not even discover my alternate version because I don’t have the name recognition, but anyone who honestly believes that a game called “Clash of Clans but where you have unlimited gems” wouldn’t get discovered is just wrong, I think.

(Of course, Clash of Clans is different, because you won’t have an account on the server. Apps where all the work is done on the company’s server are roughly immune to this problem, but that’s not the right approach for games which aren’t MMORPGs.)

Ahh and @sil, @jonobacon, @jeremy, @bryanlunduke PLEASE MAKE THE NEXT BV LIVE IN THE UK. We have tea… and biscuits. Many thanks.

2 Likes

Best way to have that happen is to have a conference invite us to perform the evening entertainment…

1 Like

There’s a pub opposite my house?

1 Like

Like the idea of paid for first X time period.

My initial reaction is that you will see basically a load of “code thrown into a github repo and walking away” style open sourcing which leads to difficult to engage projects (i.e lack of documentation/build steps etc). However, the fact the code is there is better than it not being there, so I think that is a moot point.

Secondly, I wonder is there any appetite within the paid app development community for us as a community to start approaching these developers and saying, listen your game has been on the market for X months/years already, would you be interested in sharing the source? and being part of this experiment.

1 Like

Agreed. 'Cos the alternative is “nobody can use or adapt that code or build new projects on it at all because the source never gets released”. The alternative of “the developer open sources it and continues diligently working on it and building it into a vibrant open source community” isn’t on the table, because otherwise they’d likely have done that from the start.

@joe don’t forget cake! We have cake!

Regarding the DPL, in general, it seems nice in preference of not releasing the source at all,
as noted on the podcast, - to the extent it remains closed to begin with - you loose the advantages of open-ness… I don’t think that can be helped though
(as mentioned on the show, you could make source available under non-oss license)… its an option of course, though I suspect anyone worried about others re-selling their work early on, would prefer just to stay closed to begin with.

There are a few keys to this working afaics…

  • Some history of writing open-source:
    There have been a few memorable cases of founders saying they would open their code (games “black&white”, “minecraft” and video editing application “lightworks” to name some off the top of my head).
    So I think its reasonable for anyone to be a bit cynical that it will be followed through with.
    … if its the first time. then just accept some people won’t take your word for it and you’ll need to earn their trust.
  • Valuable, non-trivial codebase:
    If you want to attract others to maintain your code, its got to be something quite special, where someone whos got the ability to maintain couldn’t have just written it themselves in their spare time.
    … if this code is potentially “The best open-source ____” ~ then there is real incentive for others to keep it running.
  • Well managed hand-over:
    Sounds like a detail, but be available for some period of time to assist others - This kind of promise can’t really be enforced, but at least if you announce its your intention and follow through on it… The cynics first time around will be less skeptical next time.

@sil Have you seen Fred Trotters ignite talk from OSCON on this topic? Fred calls it “Open Source Eventually”. There’s a blog post by Monty on it as well on what he calls “business source”.

1 Like

Huh. I had not. This is exactly the idea we independently came up with, isn’t it? Clearly this may be a useful idea. Maybe I’ll do something under such a licence. Might need to wander past a lawyer first, though.

I don’t know how things work in your neck of the woods, but wandering past lawyers is generally considered billable hours here in the states. Personally, I’d at least try to get some advice in exchange for my money. :slight_smile: