Ils ont annoncé redistribuer le code en apache avec un délai. C'est ce qu'on retrouve avec l'open core de gitlab par exemple.
Je ne sais pas ce qu'il en est d'Elastic Search, mais Gitlab n'a pas de politique de publication à retard « programmée ».
Certaines fonctions sont ajoutées simultanément dans toutes les versions de Gitlab.
Certaines fonctions sont réservées depuis de longues années aux versions payantes de Gitlab et ne sont sans doute pas près d'être étendues à la version libre, car elles font partie de celles qui incitent les entreprises à payer (celles qui le peuvent vu le cout que représente une licence de Gitlab).
D'autres fonctions sont d'abord réservées aux versions payantes de Gitlab, puis un jour, Gitlab décide de les étendre à la version libre. Le second évènement arrive parfois quelques mois après le premier, parfois des années après.
Je suis admiratif de la maturité de Gitlab vis-à-vis du libre et de sa communauté. L'entreprise a opté pour un modèle open core assez classique, mais la plupart des éditeurs qui optent pour ce modèle n'ont pas l'intelligence d'enrichir continuellement (et avec des fonctions attrayantes) la version libre. Ils ne songent qu'à accroitre l'écart fonctionnel qui sépare la version libre de la version payante, en espérant que cela conduira les clients à payer. Or, en faisant cela, ils nourrissent l'amertume des utilisateurs de la version libre, qui finissent par se tourner vers une alternative dès qu'ils le peuvent. Ils frustrent en outre terriblement les quelques contributeurs qu'ils arrivent à ferrer et ceux-ci finissent eux aussi par tourner le dos au projet. Le modèle open core, souvent mal géré, asphyxie les communautés. L'éditeur ne réalise pas qu'il se condamne à endurer tous les inconvénients du libre, sans jamais bénéficier de ses avantages et de la dynamique qu'il peut susciter.
Gitlab a compris cela et entretient intelligemment sa communauté, il la nourrit de nouvelles fonctions chaque mois (une nouvelle version de Gitlab étant publiée le 22 de chaque mois), organisant même le buzz à l'approche de la libération des fonctions les plus excitantes. Il interagit avec elle, lui pointe des bugs faciles à corriger, des fonctions qu'il serait ravi d'intégrer, mais qu'il a décidé – en tout cas pour l'instant – de ne pas implanter lui-même (cf. label Accepting merge request). Bref, Gitlab sait qu'il a une communauté exigeante et il sait être à la hauteur. Sa communauté accepte du coup plutôt bien la logique open core qui la révulse chez d'autres.
Ceci étant, notons que cette intelligence est sans doute aiguillonnée par le fait que Gitlab doit évoluer dans un écosystème très concurrentiel, entre outils libres (Gitea), outils propriétaires gratuits (Github) ou payants (suite Atlassian), sans oublier d'autres outils open core (Tuleap).
[^] # Re: libre
Posté par Sébastien Dinot (site web personnel) . En réponse à la dépêche Amazon OpenSearch - fruit d'une rivalité avec Elastic ?. Évalué à 4.
Je ne sais pas ce qu'il en est d'Elastic Search, mais Gitlab n'a pas de politique de publication à retard « programmée ».
Je suis admiratif de la maturité de Gitlab vis-à-vis du libre et de sa communauté. L'entreprise a opté pour un modèle open core assez classique, mais la plupart des éditeurs qui optent pour ce modèle n'ont pas l'intelligence d'enrichir continuellement (et avec des fonctions attrayantes) la version libre. Ils ne songent qu'à accroitre l'écart fonctionnel qui sépare la version libre de la version payante, en espérant que cela conduira les clients à payer. Or, en faisant cela, ils nourrissent l'amertume des utilisateurs de la version libre, qui finissent par se tourner vers une alternative dès qu'ils le peuvent. Ils frustrent en outre terriblement les quelques contributeurs qu'ils arrivent à ferrer et ceux-ci finissent eux aussi par tourner le dos au projet. Le modèle open core, souvent mal géré, asphyxie les communautés. L'éditeur ne réalise pas qu'il se condamne à endurer tous les inconvénients du libre, sans jamais bénéficier de ses avantages et de la dynamique qu'il peut susciter.
Gitlab a compris cela et entretient intelligemment sa communauté, il la nourrit de nouvelles fonctions chaque mois (une nouvelle version de Gitlab étant publiée le 22 de chaque mois), organisant même le buzz à l'approche de la libération des fonctions les plus excitantes. Il interagit avec elle, lui pointe des bugs faciles à corriger, des fonctions qu'il serait ravi d'intégrer, mais qu'il a décidé – en tout cas pour l'instant – de ne pas implanter lui-même (cf. label Accepting merge request). Bref, Gitlab sait qu'il a une communauté exigeante et il sait être à la hauteur. Sa communauté accepte du coup plutôt bien la logique open core qui la révulse chez d'autres.
Ceci étant, notons que cette intelligence est sans doute aiguillonnée par le fait que Gitlab doit évoluer dans un écosystème très concurrentiel, entre outils libres (Gitea), outils propriétaires gratuits (Github) ou payants (suite Atlassian), sans oublier d'autres outils open core (Tuleap).