Elastic didn't really relicense ElasticSearch. It forked it.

🧵 A thread.

1/18

There's a lot of talk in the open source community about the cost of forking.

2/18
- "Forking is best avoided."

- "Forking is a last resort option."

- "Forking is like a nuclear weapons. It's a defensive threat."

3/18
Forking is seen as impractical and extremely expensive.

And that's a Really Good Thing(tm).

It's a forcing function for figuring out solutions that are broadly acceptable across the community.

4/18
The thing is, the cost of forking is mostly a function of three things:

1⃣ the size of the community that you can bring along with you,
2⃣ whether you need to rename your fork (who owns the trademark), and
3⃣ how much infrastructure you need to rebuild.

5/18
When that "community" is your employees, when you own the trademark, and control the infrastructure, then forking is really cheap. You just tell your employees to now contribute to your new fork, and you're done.

6/18
So the whole forcing function that the threat of forking has on the community is essentially lost. You don't get your way, and you fork.

7/18
Of course, with GPL, you can't just fork and close-up the source code, unless you've secured re-licensing right from all of your contributors. This is why the GPL+CLA combo is so prevalent with FOSS vendors.

8/18
With permissive licenses, there is no such need. You can literally embed the software into anything that is proprietary. As long as you give proper attribution and keep the open source license around FOR THAT PART OF THE CODE ONLY.

9/18
No one can stop me from forking Node today and releasing it as proprietary software.

10/18
What I can't do however is:

1⃣ move all of its community to contribute to my proprietary fork overnight,
2⃣ use the "Node" trademark, and
3⃣ leverage all of the existing infrastructure that isn't mine.

11/18
So the problem with Elastic forking ElasticSearch isn't the CLA, or its new license.

It's that it:

1⃣ *is* the community,
2⃣ owns the trademark, and
3⃣ controls the infrastructure.

12/18
So from the very start, none of what would have made forking costly was ever an issue for Elastic. At any point in time, Elastic could have forked at practically zero cost.

Of course, that's a powerful weapon and an incredible power imbalance in a community.

13/18
A key element of community stability (the shared threat of forking) was lacking from the get go.

The lack of open governance, of community trademark ownership, and of a genuine community of contributors beyond Elastic employees, are at the heart of the problem.

14/18
Folks like @beep and @adactio have started calling this "nominally open source."

I think it's more "Schrödinger open source."

Despite the license, you don't really know whether it is open source or not until you open the envelope and find out the cat is dead. 😿

15/18
With that framing in mind, ElasticSearch was never really open source. It was always in this unstable, "quantic" state of being both open and close, up until a decision was made and it was no longer open.

16/18
I've said it before and I'll say it again. We really need to start looking beyond licensing to understand open source and really assess the risk of buying into an open source project.

https://t.co/wuUJMh1RtX

17/18
Licensing clearly is a factor, but community health, governance, and trademark ownership are just as important.

It's time we truly recognize this.

18/18

More from Tech

A common misunderstanding about Agile and “Big Design Up Front”:

There’s nothing in the Agile Manifesto or Principles that states you should never have any idea what you’re trying to build.

You’re allowed to think about a desired outcome from the beginning.

It’s not Big Design Up Front if you do in-depth research to understand the user’s problem.

It’s not BDUF if you spend detailed time learning who needs this thing and why they need it.

It’s not BDUF if you help every team member know what success looks like.

Agile is about reducing risk.

It’s not Agile if you increase risk by starting your sprints with complete ignorance.

It’s not Agile if you don’t research.

Don’t make the mistake of shutting down critical understanding by labeling it Bg Design Up Front.

It would be a mistake to assume this research should only be done by designers and researchers.

Product management and developers also need to be out with the team, conducting the research.

Shared Understanding is the key objective


Big Design Up Front is a thing to avoid.

Defining all the functionality before coding is BDUF.

Drawing every screen and every pixel is BDUF.

Promising functionality (or delivery dates) to customers before development starts is BDUF.

These things shouldn’t happen in Agile.
After getting good feedback on yesterday's thread on #routemobile I think it is logical to do a bit in-depth technical study. Place #twilio at center, keep #routemobile & #tanla at the periphery & see who is each placed.


This thread is inspired by one of the articles I read on the-ken about #postman API & how they are transforming & expediting software product delivery & consumption, leading to enhanced developer productivity.

We all know that #Twilio offers host of APIs that can be readily used for faster integration by anyone who wants to have communication capabilities. Before we move ahead, let's get a few things cleared out.

Can anyone build the programming capability to process payments or communication capabilities? Yes, but will they, the answer is NO. Companies prefer to consume APIs offered by likes of #Stripe #twilio #Shopify #razorpay etc.

This offers two benefits - faster time to market, of course that means no need to re-invent the wheel + not worrying of compliance around payment process or communication regulations. This makes entire ecosystem extremely agile

You May Also Like

शमशान में जब महर्षि दधीचि के मांसपिंड का दाह संस्कार हो रहा था तो उनकी पत्नी अपने पति का वियोग सहन नहीं कर पायी और पास में ही स्थित विशाल पीपल वृक्ष के कोटर में अपने तीन वर्ष के बालक को रख के स्वयं चिता पे बैठ कर सती हो गयी ।इस प्रकार ऋषी दधीचि और उनकी पत्नी की मुक्ति हो गयी।


परन्तु पीपल के कोटर में रखा बालक भूख प्यास से तड़पने लगा। जब कुछ नहीं मिला तो वो कोटर में पड़े पीपल के गोदों (फल) को खाकर बड़ा होने लगा। कालान्तर में पीपल के फलों और पत्तों को खाकर बालक का जीवन किसी प्रकार सुरक्षित रहा।

एक दिन देवर्षि नारद वहां से गुजर रहे थे ।नारद ने पीपल के कोटर में बालक को देख कर उसका परिचय मांगा -
नारद बोले - बालक तुम कौन हो?
बालक - यही तो मैं भी जानना चहता हूँ ।
नारद - तुम्हारे जनक कौन हैं?
बालक - यही तो मैं भी जानना चाहता हूँ ।

तब नारद ने आँखें बन्द कर ध्यान लगाया ।


तत्पश्चात आश्चर्यचकित हो कर बालक को बताया कि 'हे बालक! तुम महान दानी महर्षि दधीचि के पुत्र हो । तुम्हारे पिता की अस्थियों का वज्रास्त्र बनाकर ही देवताओं ने असुरों पर विजय पायी थी।तुम्हारे पिता की मृत्यु मात्र 31 वर्ष की वय में ही हो गयी थी'।

बालक - मेरे पिता की अकाल मृत्यु का क्या कारण था?
नारद - तुम्हारे पिता पर शनिदेव की महादशा थी।
बालक - मेरे उपर आयी विपत्ति का कारण क्या था?
नारद - शनिदेव की महादशा।
इतना बताकर देवर्षि नारद ने पीपल के पत्तों और गोदों को खाकर बड़े हुए उस बालक का नाम पिप्पलाद रखा और उसे दीक्षित किया।