Making LTS version **LONG** term support as the corporate world hears it

[nanuxbe]

So here is an idea, not sure how easily feasible it is but might be worth digging into since the subject has already been mentioned on the Django mailing-list. This proposition is mainly based on Django and not other open-source projects but I have the feeling this discussion is mostly geared towards the Django eco-system in general and not the open-source community. And this is just another one of those "find something to sell and use the money to fund the rest".

A lot of companies with means hear 10 or 15 years when they hear LTS, not 3 or 4 years. So I understand that maintaining 1.4 (or 1.6 as it's the version of Django shipped with several LTS linux distros) for another 6 years represent some work and that there will be security features that will be harder to port than others.

But companies are currently paying huge amounts of money to RedHat to have those LTS versions, why not try to get a piece of that money by having Django propose "VLTS" versions for a fee (like for access to a dedicated Pypi server)?

It seems to me that: a) porting security fixes back to older version, in general, is, in itself not the hardest job that a community has to face (not the most interesting one either, I agree) b) the customer base is already there c) that customer base has demonstrated willingness to pay lots of money for "special treatment"

[freakboy3742]

This is a very interesting idea, and one that is pretty much immediately actionable in the Django world (and probably a few others). I'll take it up with the Django core team and see what their reaction is.

[freakboy3742]

There's probably going to be some kickback from people complaining that the rules are changing underneath them. The answer might be to introduce fees for VLTS (i.e., continued support for 1.4), and signal that the next LTS (1.11) will be for-pay.

[nanuxbe]

I think that could be a very good idea indeed. Just want to make sure we are talking about the same thing though, 1.11's LTS part would be for-pay, not the initial release, right? (that would make things awkward I think, if non-paying parties had to skip every LTS version)

[freakboy3742]

So, my immediate thought: the current "trunk" and "stable" releases would continue to be free, and available for download. So, if the policy was in place right now, 1.8 is our current "stable", so it's freely available (along with all updates). 1.8 has also been flagged as an LTS, so when 1.9 becomes the new stable, we'd cut one last public 1.8 release, and then move it behind a paywall. If a security problem was then found in trunk (1.10), we'd backport to 1.9 (the stable release) and to 1.8 (LTS) - but you'd only get the LTS patch and tarball if you were an LTS subscriber (for $$). Depending on interest, we might even backport to 1.4 (VLTS), but the subscription there would be $$$$. In theory, if we were at LTS 2.2, VLTS 1.11, VVLTS 1.8, VVVLTS 1.4, we could still be backporting... but the price for 1.4 access would be VERY high. But that's fine - if one company that really needs to have 1.4 access is paying for half our Fellowship program... I'm not going to stop them :-)

[nanuxbe]

Ok, so yes we are speaking of the same thing and I hope I'm right when I believe this could be "easy money" compared to fundraising or other approaches.

[xordoquy]

This is probably the most interesting idea for Django project itself. Might be worth investing that for DRF as well (ping @tomchristie)

[hawkowl]

This sounds reasonable -- LTS releases are what people should pay for because it requires extra work on behalf of the Django team to keep the LTS user's things working and secure.

[nanuxbe]

I guess it could be done for a substantial part of the ecosystem. Like south for example is a very important part of the Django 1.4 ecosystem, DRF is too but there are others. If proven to work "at small scale" with Django, maybe the DSF could become a "centralizing" party for all applications that: a) are willing to provide a VLTS version for a fee b) paying customers are interested in

[spookylukey]

I want to respond to the idea of having 10 or 15 year support for web software.

My attitude generally is that if you want to develop for the web, you cannot have the attitude "we've built it, now it's done", or "we want to avoid upgrades". Rather, you need to view continuous upgrades as a way of life. If you can't upgrade quickly, securely and robustly, (at every level from OS upwards), it is irresponsible to be running any kind of online business, and it might be irresponsible of us to imply otherwise.

I recently did business with a web ads company that couldn't access our HTTPS site because they were using a Java version several years old which couldn't handle > 1024 bit SSL keys (or something like that). Months later they still can't fix it. IMO, they should get out of the web business.

I understand the corporate world has a different view, and think they don't need to move at the pace of the rest of the world for internal apps, and they don't need security updates etc. But they do actually need security updates, and this attitude actually holds back the rest of the world (e.g. IE6 had to be supported forever, because of businesses stuck in the dark age).

In addition to vulnerabilities, there is the fact that new browser technologies provide opportunities that should be embraced. The cost of living in a world where we expect this year's phone/laptop to be (a lot) better than last year's, and to provide a better experience, is that tech companies should get with the program, or get out.

So, I'd be more keen on this if we defined Very Long Term Support as 3 years, and started making people pay for that (although obviously not changing anything for current LTS).

[nanuxbe]

@spookylukey even if you don't believe it's a good choice, you said that the corporate world uses outdated software (and they often pay good money to support those software, like with IE6) so why do you think it's a bad idea to do some work to go get large amounts of money from that corporate world? Not that having a 3 year LTS paying version is a bad idea but why not take more money for longer support as @freakboy3742 mentioned?

[nanuxbe]

And the corporate world does need security updates to stay SOX- or whatever-other-norm-compliant to keep their share-holders happy and their income safe (although for a lot of those norms, saying "I know there is a security issue with this software" is enough to stay compliant).

[mathieubellon]

@nanuxbe idea is really clever. We have big corporate clients for our django powered webapp and recently one of their engineer asked me a lot of questions about Django + DRF. He asked if a LTS version was proposed. And he was speaking about 10 years indeed.

@spookylukey Big corp move really slowly. Not because they are dumb or lazy but because they are really complex. It can take them more than a year just to determine if they can upgrade Internet Explorer safely. Not doing the actual upgrade, just to prepare it. An other of my client told me they worked almost 2 years to move from IE8 to IE9. If Django can hear their need and offer 10/15 yrs support that's something that may interest them. If not they will go with a proprietary soft with support (whatever the quality of the product)

[spookylukey]

@nanuxbe @matthieubellon : I'm not opposed to the proposal, and I understand the big corps are slow. But they do need to understand that all across the world they are getting hacked left, right and centre, and user information leaked, because they have a culture which needs to have a different attitude towards change and keeping up with security etc. With server-side software especially, and the growth of devops, automated testing, continuous deployment etc., the tools are in place for a better way to do things. I don't know what is the best way to encourage that though. I just don't want us to encourage a culture that will continue to hold back the web.

[nanuxbe]

@spookylukey I'm not sure who you think about when you are referring to big corps, if you are referring to Google, Twitter, Facebook and the likes, they are not the ones stalling upgrades, they are often on the opposite side of the spectrum being the creators of things like react or bootstrap. For myself, I'm referring to IBM, banks, large grocery store chains and for those, most of the time, their websites are not part of the corporate networks and are out-sourced to PR/web agencies whenever possible and that's not where they are stuck with stale software, it's with internal applications (web technology doesn't mean internet). And some of those apps still run on AS400 servers and/or in Cobol.

Also, I'm not sure where you are going with the "holding back the web" argument. I thought that what was holding back the web was browser compatibility and as far as I'm aware, the fact your html5 and ccs3 will display correctly in IE8 isn't dependent on the backend you are using? Or maybe I'm missing somethings?

Finally, it's quite funny how what you see is holding back technology I see as an enabler for technology to move forward faster. Let me explain: Let's say (and this is purely hypothetical) Django wants to drop support for python 2 with their Django 2.0 release. While being a clear move forward, in the current situation, that move will have a very hard time being accepted because there is a size-able part of the potential customer-base still running with python 2. Now if there is a viable 1.11 VLTS, that move towards python 3 only will be much easier to make since potential customers know that 1.11 won't die 2 years later, even when Django will have reached 2.5, there will still be a viable python 2 version of the software while, by only supporting python 3, the framework will have progressed somewhat faster because it didn't have to maintain compatibility with python 2.

[pydanny]

@nanuxbe, I believe this is a brilliant idea. I love the idea of when Django 1.11 arrives (or whatever they are calling the next LTS release), that Django 1.8 would become a $$$ project, with support releases on private branches sold to corporate interests. This would certainly provide consistent enough revenue stream for the DSF that they could hire core Django developers to maintain Django.

[spookylukey]

@nanuxbe We have the same idea about the kind of corps that are slow to move (I was especially thinking of the large supermarket chain my wife works for).

Those are good points regarding Python 2 etc.

The kind of situation I'm thinking of is this:

In 2025, Django 6.0 is being developed. The team really want to drop support for HTTP 1.x and also HTTP 2.0 - after all HTTP 2.2 was standardised 5 years previously, fixing the various issues in HTTP 2.0, and all recent browsers fully support HTTP 2.4.

However, many millions of people are not using recent browsers - they are still using Internet Explorer 12, whose inadequate HTTP2 support means you are limited to HTTP1. These people turn out to be all business machines - home users are all on Internet Explorer 18 or later. Business machines haven't been upgraded, because there is a mutually dependent set of reasons for not doing so. Their critical internal business web apps run on Django 1.8, with an old stack of other software, which works fine with IE12 and is still supported (paid). There is no motivating case to upgrade either browser or server software, which work fine together, and they would have to upgrade both a long way to get any of the improvements of HTTP 2.4 (or other advances), so they don't bother.

So, Dango 6.0 developers are annoyed that they are still having to support legacy browsers, and slightly more annoyed because promises they made in the past have actually contributed to the problem.

It's with this kind of thing in mind that I'd be hesitant to promise something as long as 10 years support. If we could promise less ahead of time I'd be more happy.

[nanuxbe]

@spookylukey Ok, I see your point but I still have a feeling that if microsoft still supports Internet Explorer 12 in 2025, it will still be installed on those corporate machines independently of whether Django 1.8 is still supported or not. Those corps make a lot of decision in consideration of their existing setup rather than on available technologies. It will then just be potential market shares lost for Django.

It all depends on your audience of course, but I personally see less then 1% traffic from IE <10 on the websites I manage. And I see between 35 and 50% of mobile traffic so I really believe this is a non-issue.

Not sure how good those are but here an interesting link about global browser usage stats: http://gs.statcounter.com/#browser_version-ww-monthly-201501-201509

[mjtallx]

Some questions come to mind. Who will do the job? Will they get compensated? Will the patches be open source?

[mathieubellon]

Yep, Who is going to work on this 'service' ? That's a good question. If we want this idea to go further down any validation process this question needs to be answered or at least we must provide some scenario.

I was looking at Symfony. This FOSS is backed by a company SensioLabs. SensioLabs offers entreprise services : https://sensiolabs.com/en/packaged-solutions/enterprise-subscription.html

Among all these services (mainly formation) we have the 'old versions support' we are talking about ("Extended Symfony support on earlier versions ")

To my knowledge it seems that SensioLabs participates in Symfony evolutions and releases its work under open source licence.

So in this 'architecture' we have an open source framework which is managed by its community and benefit from the paid work of a decoupled company.

I also realised that, from a corporate point of view, it is almost impossible to 'buy' a product without a well known company selling services (support, formation, expertise) for it.

I think it is an interesting scenario, not easy to implement though. But in this case the community can provide more services than only VLTS and hired Django experts not to only work on the VLTS but also on other services.

[nanuxbe]

Not sure I would use the word decoupled when it comes to SensioLabs and Symfony, they are almost as tightly coupled as the DSF and Django...

Speaking of which: why would it have to be a company? Why couldn't the DSF, PSF, FSF, whathever-else-SF assume that role? They are all legal entities with the ability to collect money from other parties, the only difference is they are non-profit entities, hence have to pour that money back into the community they were built for (more or less depending on their by-laws)

[mathieubellon]

I meant a 'company' by 'entity allowed to bill other parties and collect money'. Non-profit entities are evidently preferable. Be it the DSF but I would advise to set up an isolated entity for this paid work purposes.

By 'decoupled' I meant : If the company closes the software is not going down with it.

[freakboy3742]

@nanuxbe The short answer is that the DSF's legal structure makes it difficult for us to do this. The US IRS doesn't view writing open source code as a "charitable activity", because writing source code is something you can be paid for - so 501(c)3 organizations (which is the legal structure under which the DSF is incorporated) can't hire people to write code without potentially losing our Not-for-profit status. The job description for the DSF Fellow is very carefully worded - they aren't writing code, and "writing new features" is explicitly listed as something they don't do. The DSF fellow is paid to do community management.

That said, there are other not-for-profit legal entities under the US tax code that would allow the DSF to hire programmers directly - most notably, 501(d), which is a "Trade organization". There are some other consequences of making that change, so it's not a completely no-brainer. If the DSF is going to get involved in actively paying for code development, it's something we'll probably need to look at.

[nanuxbe]

@matthieubellon sorry I misunderstood.

@freakboy3742 although I'm sure it comes with a price, maybe a second structure affiliated with the DSF as @matthieubellon proposed might be a more realistic solution. And maybe there are other legislations under which it might be easier (I'm thinking maybe UK, Canada or Australia or any other English-speaking country -to make it easier for the community to be involved- but I really don't know)

[mathieubellon]

@nanuxbe absolutely no problem, I used incorrect words (company is mainly for-profit entity)

[wolftune]

@freakboy3742

• "is something you can be paid for" is not a valid reason to disqualify a 501(c)(3). Hospitals can be for-profit and can also be 501(c)(3).
• 501(d) is a religious community, not a trade group https://www.irs.gov/irm/part4/irm_04-076-029.html — trade groups are 501(c)(6)
• The reason DSF can't hire people to just write code (assuming that's true) is strictly because of the mission and scope that you have in your bylaws
• Lots of 501(c)(3) FLOSS organizations do hire people to write code, it's just that the code has to be directly about serving their 501(c)(3)-approved stated mission

[jefftriplett]

I have several friends who are directors and work for 501(c)(3) non-profits in Kansas and they are compensated. It's rare to not be actually but there was a fear that money would pollute OSS ten years ago which does not exist today.

So maybe this clause is the heart of the argument:

"1.3 No part of the net earnings or other assets of the Foundation shall inure to the benefit of, or be distributable to, its members, directors, officers, contributors, or other persons in their private capacity, except that the Foundation shall be authorized and empowered to pay reasonable compensation for services rendered and make payments and distributions in furtherance of the purposes set forth in this Article."

If so, I'd suggest amending the bylaws which is completely doable and requires refiling. Here are the bylaws for further reference: https://www.djangoproject.com/m/foundation/bylaws.pdf

[pydanny]

@mjtallx, @matthieubellon here's how I would do it if I were calling the shots:

Who will do the job?

Paid employees of a "Django Software Corporation", an entity that mirrors the DSF the same way Mozilla has an 501(c)(3) mirror it's corporate site. Their job would be to keep the LTS support versions running for as long as those LTS support versions are supposed to work.

We would also have 'transition staff' whose job it is to help firms go from one LTS version tot he next.

Will they get compensated?

Absolutely. Real pay, real benefits. Since this entity would have Enterprise-level customers who pay serious money for this kind of LTS, which I call 'Enterprise LTS', they would be paid at least market rate.

Will the patches be open source?

Since I'm calling the shots on this one, the patches would NOT be open source. To build up the initial customer base for Enterprise LTS Django after years of Django being 'free' in everyone's mind, it would have to be private (although the source code would be made available to paying customers). Eventually it might be opened up to the world as open source, but not for a few years

---

While I'm not calling the shots on this one, I will say that if I had a spare million dollars lying around and an inclination to run a business-to-business company, I would start this plan TODAY:

1. To the DSF I would offer whatever percentage of net profits that the DSF would insist on to make this happen.
2. I would start making it known I was hiring Enterprise LTS Django developers.
3. I would be contacting potential customers (corporate and government) and old clients to line up the business. That includes advertising, marketing, and sales.

You know what? At the margins and profit I anticipate this making, I would make myself have the inclination. That only leaves the issue of financial resources for getting it off the ground. Oh well...

[buddylindsey]

@pydanny well from there you just need a good salesman who can sell initial support and get paid something upfront. That would seed the company with money. If you made the sell then you could setup the business.

[freakboy3742]

@wolftune Sorry about the 501(d) gaffe - I was thinking of 501(c)4, which is what RubyTogether is incorporated as.

@jefftriplett Regarding getting paid by a 501(c)3: there's nothing prohibiting a 501(c) from paying anyone . However, what we pay for has to be aligned with the DSF's declared charitable goals. The restrictions exist on what can be considered the charitable goals of a 501(c)3. There are several examples of open source organisations that have had their 501(c)3 status refused (e.g, the Yorba foundation on the basis that the IRS doesn't consider "software development" isn't a charitable activity. The DSF is incorporated:

...to promote, support, and advance its open-source project: in our case, the Django Web framework.

The foundation's goals are to:

• Support development of Django by sponsoring sprints, meetups, gatherings and community events.
• Promote the use of Django among the world-wide Web development community.
• Protect the intellectual property and the framework's long-term viability.
• Advance the state of the art in Web development.

So, we can support development of Django, but we can't fund the development of Django. The DSF fellow is hired as a community manager, not as a software developer.

Yes, we could amend our bylaws, but that would also affect our 501(c)3 registration, and current balance of evidence would suggest that adding "develop Django" to our bylaws would result in us losing 501(c)3 status.

There's another a good reason to keep software development out of the DSF's pocket - the DSF must continue to exist. It owns the trademarks, and if the DSF were to ever fold, it could mean those trademarks (as valuable property) could be owned by a debtor. @pydanny's suggestion is probably the best approach here - start a second company that manages the commercial contracts. That company might be a normal for-profit, or it could be a 501(c)4, or a B-corp - either way, it puts up a firewall between the DSF's finances and the "support organization's" finances. This is the same arrangement that the DSF has with DEFNA, to insulate the DSF from the (not insignificant) financial risk of organizing conferences.

[wolftune]

@freakboy3742 501(c)(4) isn't a trade org, that's 501(c)(6), but yes, 501(c)(4) is a legitimate type of org for us (and can certainly pay devs if it fits the org's mission)

[freakboy3742]

@pydanny I completely agree with what you're proposing. Especially in Django's case, but probably more broadly as well, I can see this being a very viable business model.

The problem will be pushback from the community. I floated a test balloon with the core team about making LTS a pay-only feature, and the response was... less than enthusiastic. I'm hoping the upcoming DuTH core team meeting will give me an opportunity to change some minds.

[freakboy3742]

@wolftune ... it's very early in the morning, and my coffee hasn't kicked in yet. You're completely correct - 501(c)6 is a trade organization, and that is what RubyTogether is incorporated as. Sorry for leading everyone astray... multiple times...

[ericholscher]

An example of this: https://stablelib.com/

On Wed, Oct 21, 2015 at 5:13 PM, Russell Keith-Magee < notifications@github.com> wrote:

@wolftune https://github.com/wolftune ... it's very early in the morning, and my coffee hasn't kicked in yet. You're completely correct - 501(c)6 is a trade organization, and that is what RubyTogether is incorporated as. Sorry for leading everyone astray... multiple times...

— Reply to this email directly or view it on GitHub https://github.com/pybee/paying-the-piper/issues/32#issuecomment-150059395 .

Eric Holscher Maker of the internet residing in Portland, Oregon http://ericholscher.com

[mathieubellon]

@freakboy3742 " I floated a test balloon with the core team about making LTS a pay-only feature, and the response was... less than enthusiastic" > Are they against that precise Entreprise LTS service or against the whole idea (isolated entity that make money to fuel the project) ?

[freakboy3742]

@matthieubellon Broadly, the objection was that charging for something is contrary to the spirit of the project, especially if we're charging for something like security updates, or for anything at all that we've historically given away for free (or have "committed" to giving away for free, like Django's LTS releases)

[nanuxbe]

@freakboy3742 it's not about charging for something that has been historically given away for free, it's charging for something which hasn't been given before (yes, it's still security updates though)

[freakboy3742]

@nanuxbe In Django's case, depends if we're talking about LTS or VLTS. We have an advertised LTS policy, and it has been freely available for almost 4 years now.

VLTS would be an entirely new product, so it would be easier to introduce a new policy. However, even that got some pushback (just the idea of "charging money for security").

[nanuxbe]

@freakboy3742 yes, I was thinking about VLTS, LTS staying the same way it is for the moment.

I'm not sure how to formulate this, but maybe it might be interesting to think about how to introduce it as an added benefit, a new feature to increase security in general, rather than just "charging for security". Maybe starting by something like "this is something the core team isn't willing to do for free anyways" or something like that?

[xordoquy]

Time is a limited resource and the core team can not afford to spend it on maintaining LTS because it slows down new features ?

[pydanny]

I'm with @nanuxbe, and I should clarify: I'm not talking about charging for LTS support, I'm talking about charging for VLTS (LTS Enterprise in marketing-speak). Nothing about the current status of things would change, there would just a be a firm whose role it would be to support (for a fee) much older versions of Django used by larger, less flexible organizations.

To wit: Django 1.8 LTS wouldn't become Django 1.8 VLTS until late 2017 (if my dates are right). Only then would it become a commodity with paid support.

Another bonus to this concept is INCREASED data security. Right now my data, your data, is being used in applications running on legacy versions of tools (be they powered by Django, ColdFusion, Rails, .Net, etc). By providing VLTS the Django world helps secure that data stored using legacy versions of our code.

[ericholscher]

https://railslts.com/ for a similar idea.

[jarshwah]

My concerns raised elsewhere regarding paywalling LTS versions was specifically against "current" LTS versions. It has only been about 6 months since django core committed to the new version numbers, support periods, and LTS terms. I don't think Django could back out of having free LTS on 1.8 without serious blowback.

I also think offering a free LTS version keeps Django relevant in smaller corps that appreciate medium term support but don't really have the dollars to commit to traditional support contracts. It's important Django is still able to capture these users, because that is what will get the bigger corps continuing to use Django. Our commitment to LTS really is medium term support (3 years?).

Once a version falls out of the free tier of LTS, we should definitely be adding that to a corporate support contract plan. Paywall it (I remove my previous objections to this) and make it valuable. Optionally, add some non-LTS versions to a similar plan. Django 1.6 would probably have worked with this method considering community interest in privately supporting 1.6.

I really like @pydanny's Django Software Corporation idea. I wonder how viable it'd be. That is, what kind of dollars you could afford to pay developers based on incoming contracts. I especially like the idea of hiring out contractors to help with migrations - though that'd eat into support contract monies. If this idea goes ahead, please do not limit to US employees only! It'd definitely be something I'd consider putting my hand up for.

[gampleman]

I think a similar approach to making money could be with major version bumps - i.e. sell for profit a plugin that makes migrating from version v2 to v3 easier.

[tomchristie]

The issue with selling around the edges eg "sell for profit a plugin that makes migrating from version v2 to v3 easier." or "have a pro option for deployment", or "sell pro tutorials alongside the project" is that you're putting work in, but then not getting the maximum possible value out of it, by imposing these restrictions.

Part of what makes OSS a compelling model is that it necessarily gets the maximum possible value out of the effort put in, because the final product is freely available, rather than having supply be artificially restricted.

My take is that the best approach for the projects themselves is to promote and sell sponsorships largely on the basis of "buy development time and help improve the tooling that you're using". Ie sell the software (development process) itself rather than using indirect approaches.

Where I do think that selling around the edges is in allowing for healthy ecosystems where other interested parties can take up bits of slack that the project owners themselves haven't chosen to prioritize. (Eg. Extended LTS as a viable business for a third party business to provide - adding value to the ecosystem without having compromised the project author's goal of "provide maximum utility, openness")

[wearpants]

This is not only an issue for large companies. As a solo freelance developer, its a real challenge to keep up with the release cycle, especially when my contact with clients basically ceases after initial development.

Not looking for 10+ years, but something akin to Ubuntu (3-5 years) would be really helpful. Could probably only pay $ not $$$, but I'm not the only one in this position by a long shot.

[ncoghlan]

As far as the VLTS idea goes (especially in the context of a web framework like Django), it's important to keep in mind that the continuous deployment and infrastructure-as-code practices of the internet-era giants are in the process of going mainstream - that's why Canonical have been able to build a Linux business despite limiting their LTS model to 5 years rather than mirroring Red Hat's 10, why Red Hat introduced Software Collections in order to better enable faster component updates (and rebased Gnome in RHEL Workstation 7.2), and why CoreOS are able to make rolling upgrades of the host the default behaviour and still garner commercial interest. The selective security backport model makes sense when regression testing is expensive, but rolling upgrades make more sense when regression testing is fully automated and hence relatively cheap.

On the idea of encouraging direct contributions of development time, one of the main techniques organisations like the Linux Foundation and the OpenStack Foundation use is to collect and publish contribution metrics to see which commercial redistributors and major end users are pulling their weight. While companies can't feel shame, the people running and working for them can, so these metrics can have a significant impact on employee satisfaction, and depending on the customer base, on customer satisfaction as well.

The Eclipse Foundation goes in the direction of offering discounts on certain kinds of sponsorship if an organisation commits to funding a full time developer role working on the upstream project (to the tune of $125k per developer)