Open sourcing Cursive while still providing income from it

[Mike Pence]

We are all in favor of Colin making money from Cursive, for sure. But I am sure many of us would also like to help make Cursive better, by submitting our own patches, features, etc.

Surely there are open source / business models that would support both goals?

[Rafik NACCACHE]

+1 for this. Why not a kickstarter campaign  like ambrose did for typed clojure?

[Colin Fleming]

Cursive is unlikely to be open source any time in the near future - there’s really no proven business model for software like this, and I think it’s fair to characterise making money from open source as “hard to impossible”. Literally the only successful example (without going as far as Red Hat) I can think of is Mike Perham with Sidekiq pro. Sidekiq is much easier to segment into free and enterprise tiers, sells to a market that is probably at least an order of magnitude bigger (and maybe two), and still took 3 years to become viable.

Ambrose’s kickstarter campaign raised ~$35k. Where I live and with a family, that would last me 6 months tops, probably not even that. It’s probably also ~20% of what I could get as a yearly salary doing something else. I’m really not a fan of the kickstarter model, I’d rather make something of value and charge money for it. It’s kind of old school these days, but I like it. If you’d like a counter-example look at Light Table - they raised $300k or so, burned through it in a year or two paying 3 salaries in San Francisco, and since then it’s been effectively abandoned. I don’t want that to happen to Cursive.

I’ll be releasing the extension API before too long, and at that point people will be able to add extensions and help with the implementation. Believe me, I’m swamped - no-one wants to get to the point where more people can help than me. But I’d like to still be doing this in a year’s time, and this is really the only way I can see to be doing that. I’ll never be retiring to my megayacht on the proceeds, but if I can get it to be sustainable I’m happy with that.

Cheers,

Colin

[Timothy Baldridge]

For what it's worth, I completely agree. OSS has its place, supporting a family is not one of them. 

Timothy

--

“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Ian Phillips]

+1 to you, Colin. I agree completely.

[Rafik NACCACHE]

You get a point  Colin.  If I'm keeping nagging about this it's not because I don't want you to make a living from Cursive; it is simply because from here (tunisia), I can't easily make international payments:(

Any way, when the time comes when the payment must be Done,  I'll find a way I guess...

[Daniel Compton]

While we're talking about this, it would be great if there was an option to start paying *something* for Cursive. I'm getting incredible value from it and not giving anything back. 

On the OSS note, while we all love it when we have access to the source, realistically how many people in the Clojure community (excluding Mark Derricutt and Colin Fleming) have the willingness and ability to dive into the IntelliJ plugin API to make meaningful improvements to Cursive? While that number probably isn't zero, I wouldn't be surprised if it was in the single digits.

Maybe once Colin has his megayacht he can consider open sourcing Cursive :)
--

Daniel

[Colin Yates]

I'm more interested in where a techie (albeit a great one) can make
$175K a year - I'm packing my bags right now :). But then again, I
couldn't leave England, I would miss the weather!

I can understand Colin's reticence to collaborate on this. There is a
huge efficiency in being the sole owner/contributor to something.
Adding a single person loses a lot of freedom, particularly when
things are in churn. You have to agree coding standards, explain those
narly little "hackathons" (which we really come back and re-engineer
one day, honest), agree common paradigms etc. It isn't unusual for me
to slow down by a factor of 10 when I have to collaborate with someone
else. Nothing to do with them, just communication is expensive.

As Daniel said, realistically, who would have the time to make a
meaningful contribution now? And then there is the awkward, well, I
contributed to the core which is being charged for, hang on a
minute....

Waiting for Colin to expose a stable API behind which Colin has
complete control I think makes a lot of sense.

[John Szakmeister]

On Wed, Dec 3, 2014 at 4:33 AM, Colin Yates <colin...@gmail.com> wrote:
> I'm more interested in where a techie (albeit a great one) can make
> $175K a year - I'm packing my bags right now :). But then again, I
> couldn't leave England, I would miss the weather!

Don't forget that benefits factor into the equation too--they add up
pretty quickly. So you're actual salary wouldn't be that high.

> I can understand Colin's reticence to collaborate on this. There is a
> huge efficiency in being the sole owner/contributor to something.
> Adding a single person loses a lot of freedom, particularly when
> things are in churn. You have to agree coding standards, explain those
> narly little "hackathons" (which we really come back and re-engineer
> one day, honest), agree common paradigms etc. It isn't unusual for me
> to slow down by a factor of 10 when I have to collaborate with someone
> else. Nothing to do with them, just communication is expensive.

Very true.

> As Daniel said, realistically, who would have the time to make a
> meaningful contribution now? And then there is the awkward, well, I
> contributed to the core which is being charged for, hang on a
> minute....

FWIW, I use PMEase's QuickBuild, and have been for nearly 10 years
now. It's priced right ($2,500 for a site license, and slightly less
for upgrades over the next year) and we get a lot of value out of it.
One thing that they do that's very nice is provide the source with the
license--with legal repercussions if you distribute them. I've not
held back in contributing fixes back to PMEase simply because they
make money off it. I get enough value that I feel it's worth my
while. And just to give you an idea, I provided early support for
Bazaar, which was not a simple few lines of code. :-) They asked that
I license it as Apache 2.0, and took what they need to carry it the
rest of the way. It worked out very well, IMO. And I'd do it again,
if the need came up.

-John

[Colin Yates]

Hi John,

Contributing to an already commercial tool or a tool which is going to
be open-sourced doesn't have the same opportunity for ambiguity that
contributing to a going-to-be-commercial-but-isn't-yet tool has. I
wasn't really making a big point about that in itself, just that it is
one worm of many in the can :).

I also think there are far fewer contributors like yourself (who sound
very reasoned, professional and committed to doing the right thing
engineering wise) than there are hackers whose contribution would just
produce noise.

It's a dilemma for sure - open up the gates to professional high
quality contributors/keep sole control. I sometimes see the sense in
raising the bar just that little bit for Clojure (signing a document?
shudder), then again I bemoan that decision when they also don't take
pull requests.

[Colin Fleming]

Thanks for the feedback, everyone, it’s been very interesting.

Colin & Daniel are spot on about the cost of synchronisation and the complexity of the IntelliJ API - it’s truly massive, written in Java and pretty much totally undocumented for anything non-trivial. I spend an enormous amount of time poking through the IntelliJ Community source trying to figure out how things work. Sometimes it’s easy, sometimes it’s hard, sometimes it’s pretty much impossible. The Cursive extension API, while it won’t give total flexibility, will hopefully be flexible enough over time that people can add most interesting functionality, will be written in Clojure, be actively supported, be at least somewhat documented etc etc - it’ll just be a more practical (and fun) option all around I think. And all of this is only the technical aspects, the legal aspects of accepting code from people in other legal jurisdictions to include in a commercial product are also non-trivial, although that will probably also apply to any code I bundle with Cursive that uses the API.

A lot of people have also asked about being able to pay for Cursive. While I’m really glad people feel like they’re getting great value from it, there’s no rush - more money won’t make development any faster, and I’m not going to stop any time soon for lack of funds. I was lucky enough that my last job ended in an acquisition - I didn’t get never-work-again money from it, but enough that I could take a sabbatical to find something fun to work on. So, I’m not going anywhere, just enjoy Cursive in the meantime!

Cheers,
Colin

[Colin Fleming]

> Maybe once Colin has his megayacht he can consider open sourcing Cursive :)

I hereby publicly commit to open sourcing Cursive if I ever buy a megayacht with the proceeds. It’s only fair.

[Rafik NACCACHE]

Aknowledged. If I ever see you on  a megayacht, you owe me a free copy :)

[Colin Yates]

I'm looking forward to the "Cursive roadshow" now :).

[John Szakmeister]

On Wed, Dec 3, 2014 at 5:07 AM, Colin Yates <colin...@gmail.com> wrote:
> Hi John,
>
> Contributing to an already commercial tool or a tool which is going to
> be open-sourced doesn't have the same opportunity for ambiguity that
> contributing to a going-to-be-commercial-but-isn't-yet tool has. I
> wasn't really making a big point about that in itself, just that it is
> one worm of many in the can :).

True, though it wouldn't have changed what I had done. :-)

> I also think there are far fewer contributors like yourself (who sound
> very reasoned, professional and committed to doing the right thing
> engineering wise) than there are hackers whose contribution would just
> produce noise.

/me blushes. Thank you!

> It's a dilemma for sure - open up the gates to professional high
> quality contributors/keep sole control. I sometimes see the sense in
> raising the bar just that little bit for Clojure (signing a document?
> shudder), then again I bemoan that decision when they also don't take
> pull requests.

Tru dat! :-)

-John

[Alan Moore]

FYI - as I have mentioned before on this list, we are trying to fix the problems associated with open source and the lack of viable business models. It revolves around a new kind of software license that is based on the well proven cooperative model.

In case you are not aware, cooperatives are among the most stable forms of enterprise and hold great promise for software engineering. Cooperatives are democratically controlled and profits (after paying salaries, development costs, etc.) are distributed back to the members. There is also a crowd sourcing element to our vision that allows developers to work full time on the projects that need funding up front.

The idea is to strike a balance between vulture capital/crazy SV model of startups and the (mostly) rudderless open source world. In this model developers are able to scratch their itch without having to pivot every three months looking for funding or needing to make short term returns for investors who only care about money.

There are also some very real savings and opportunities from a software engineering perspective if we rethink some fundamental assumptions because the business model allows it.

In this case, I would love to get feedback about what kind of project structure/terms would make such a license workable for everyone.

I will post a more detailed description this weekend (the day job comes first :-) and you guys can tear it apart.

BTW - lest everyone think I'm some kook who doesn't know what he is talking about I can assure you that my 35 years of software engineering in the valley give me a unique perspective. I have worked for numerous startups (most too early to market and ran out of runway/money) and the likes of Intel, HP, eBay, just to name a few. I have lived through it and can tell you that you don't need to live/work there to be a part of the future of computing.

Alan

P.S. Anyone interested in joining us in building out the coopsource.org infrastructure is welcome to contact me offlist. It is being built with clojure and clojurescript. While we are just getting started it has been many years in the planning stages and we could use some help getting it launched :-)

[Wilker]

Looking forward to see this more detailed description Alan :)

[Alan Moore]

Colin - my comments here are not meant to pressure you into such a license. The topic came up so I put my 2 bits worth out there mainly to get some feedback on the ideas.

I think this kind of thing mostly applies to new projects starting from ground zero where expectations are set up front. Also, it can apply to projects that might have failed in the marketplace due to lack of features/value and need a community to help bring it into alignment with paying customer's expectations.

I think Cursive provides enough value on it's own that it can be supported by paying customers at this point. You've done a great job with it - thanks! BTW - I watched your Conj presentation which was also very well done, congrats.

Alan

[Colin Yates]

Hi Alan, the site isn't responding for me (over here in sunny England)

[Colin Fleming]

Hi Alan,

Sure, no pressure at all. I’m very interested to see more details on your plan though, it looks interesting even if it’s not right for Cursive.

Thanks for the kind words, too!

Cheers,

Colin

[Wilker]

Hi Alan, just one thing, as Colin Yates pointed before, the site http://coopsource.org/ is not working, did you know if it's going back anytime soon?

Thanks.

[Alan Moore]

All,

Yes, the site is down at the moment. Technical difficulties and all that...

I promise this will be my last post on this topic but I did want to correct a word choice in my previous comment - I think "(mostly) rudderless" could sound like an insult to those who have worked hard to provide awesome software gratis and free.

My apologies to all who may have been offended. Maybe "(sometimes) rudderless" is a more appropriate word choice - in the sense that, as a whole, OSS grows more organically and through circumstance than through design and planning. For much of OSS this is a necessary and important property but it doesn't often make for good business models.

That's it... I'll go back to my cube now, thanks for listening :-)

Alan

P.S. For those of you who expressed an interest in Cooperative Software Engineering you can subscribe to the public mailing list here:

https://groups.google.com/d/forum/coopsource

Please feel free to carry on the conversation over there - thanks!

Alan

On Wed, Dec 3, 2014 at 9:48 AM, Alan Moore <kahun...@coopsource.org> wrote: