Anthropic copió descaradamente el modelo de datos de Mononoke para su sistema Scion
More on Anthropic's Scion ripping off Mononoke
Un exempleado de Meta revela que Scion, el sistema de control de versiones de Anthropic, no solo se inspiró en Mononoke: su modelo de datos Bonsai fue copiado intencionalmente, incluso con personal superpuesto. El autor, que lideró el diseño de Bonsai en 2018, explica que la similitud abarca todo el modelo y las estructuras asociadas. Aunque copiar buenas ideas es aceptable, borrar los números de serie y presentar el trabajo ajeno como propio es inaceptable. El logro de Anthropic sigue siendo notable, pero menos impresionante sin la atribución debida.
No me parece bien que se borren los números de serie accidentalmente, y ciertamente no me parece bien que se borren intencionalmente.
- nickg-anthropic
¡Hola! Soy el autor original de la entrada del blog y quería aclarar un poco las cosas aquí.
Atribuimos el crédito a Sapling porque así es como Meta se refiere externamente a todo el sistema, incluido el servidor Mononoke, y queríamos seguir esa convención. Añadiremos una nota al pie adicional para aclararlo. [edición: hecho]
Nos inspiramos en muchas cosas mientras construíamos Scion, como las grandes ideas del modelo de datos Bonsai de Mononoke, y no pretendíamos ocultarlo de ninguna manera. También nos inspiramos mucho en https://martin.kleppmann.com/2015/03/04/turning-the-database..., por ejemplo, que también describe el concepto de "datos derivados" usando las mismas palabras.
Tampoco le dijimos simplemente a Claude que nos construyera un sistema de control de versiones; investigamos mucho sobre qué funcionaría y qué no para nuestro caso de uso, y partir de un gran repositorio Git existente (en lugar de Mercurial, como hizo Mononoke) requería muchas novedades más allá de algunas de estas estructuras de datos.
La intención era dar crédito a Mononoke sin entrar demasiado en los detalles de comparar y contrastar cada punto del modelo de datos donde divergíamos. Hay muchos ex empleados de Meta en Anthropic que se inspiraron en lo placentero que era usar el control de versiones gracias a Mononoke, lo cual merece mucho crédito para ti y para el equipo de control de versiones de allí. Tuvimos esa experiencia como estrella polar desde el principio mientras tomábamos decisiones que se ajustan a nuestras necesidades (diferentes).
- MeetingsBrowser
> mi suposición por defecto ahora es que las presentaciones públicas de ingeniería de Anthropic son en gran medida copias de mala fe. Eso es una lástima.
No podría estar más de acuerdo.
Me puse nervioso cuando la empresa que afirma estar trabajando en la tecnología más impactante de la historia de la humanidad se toma un tiempo para presumir de haber escrito una versión ligeramente más eficiente de un sistema de control de versiones.
El hecho de que en realidad no construyeran el proyecto paralelo ellos mismos, sino que lo copiaran de otra persona, también pone en duda su misión de buena fe de guiar a la humanidad hacia una nueva era...
- fcarraldo
Mononoke y EdenFS de código abierto en realidad no funcionan fuera de Meta. Lo investigué hace algunos años para un gran monorepo, determiné que no funcionaría y lo archivé. Si tuviera un equipo de personas y/o agentes disponibles, probablemente lo habríamos construido desde cero en lugar de adoptar la base de código de Sapling.
Parece un poco tonto armar todo este alboroto por un proyecto con licencia MIT que es tanto de código abierto como en realidad no usable. ¿Qué esperas que haga la gente con el código fuente, que lo admire?
- jfrbfbreudh
> ¡Incluso el nombre "Scion" invierte las sílabas de "Bonsai" y elimina la "B"! Esto podría ser una coincidencia, o podría no serlo.
vaya
- espeed
Al rediseñar un sistema de control de versiones moderno para proyectos de código abierto, hay que considerar que millones de desarrolladores tienen agentes de programación ejecutándose en su computadora y/o tienen cuentas de agentes de programación de Claude Code/Google/OpenAI. Y según la evidencia del repositorio de Linux y muchos otros repositorios de GitHub, los proyectos de código abierto se desbordan de informes de errores enviados por agentes de programación. Si yo estuviera aceptando un informe de error y/o un parche, querría saber el problema declarado y las razones por las que es un problema, el estado deseado o la solución y las razones por las que se prefiere, y si se suministra un parche, querría prueba verificable de procedencia: la sesión firmada del agente de programación, incluidos los prompts usados para generarlo junto con el código modificado. De esta manera, el mantenimiento de código abierto puede volverse verdaderamente descentralizado.