1 puntos por GN⁺ 2023-11-07 | 1 comentarios | Compartir por WhatsApp
  • En la comunidad de desarrolladores de Apple se propuso un boicot a Feedback Assistant, con un plan de acción para no enviar nuevos bugs al sistema oficial de reportes hasta que se resuelvan los problemas
  • La forma de participar consiste primero en reportar los problemas del propio Feedback Assistant, luego dejar de enviar nuevos Feedback y responder en boicot a las solicitudes existentes
  • Las quejas se concentran en la forma en que opera el sistema de reporte de bugs: no informa si pudo reproducir el problema, cierra casos sin aviso, no permite reabrirlos, exige sysdiagnose de forma excesiva, dejó de aceptar envíos desde la web y no permite búsquedas
  • Compartir bugs en WebKit, en los proyectos open source de Apple en GitHub, y en redes sociales, blogs y podcasts queda fuera del boicot
  • El objetivo es poner en evidencia que Apple depende del trabajo no remunerado de QA de desarrolladores externos y confirmar que los desarrolladores pueden seguir trabajando y manteniéndose sin Feedback Assistant

Cómo participar en el boicot

  • Se inicia de inmediato un boicot a Feedback Assistant de Apple, y se recomienda a todos los desarrolladores de Apple sumarse
  • El procedimiento propuesto consta de tres pasos
    • Enviar un nuevo Feedback en la categoría Developer Tools & Resources de Feedback Assistant, indicando la lista de problemas y que se entrará en boicot hasta que se resuelvan
    • No enviar ningún otro Feedback nuevo hasta que Apple solucione esos problemas
    • Si Apple pide una respuesta sobre un Feedback existente, contestar que se está en boicot y referenciar el número del Feedback enviado en el primer paso
  • Se considera preferible que el Feedback del primer paso sea lo más único posible en cada caso
    • El objetivo es hacer que Apple procese los Feedback relacionados con el boicot y que note que los desarrolladores están actuando en serio

Alcance del boicot y exclusiones

  • El boicot se limita a Feedback Assistant
  • Seguir hablando de bugs en redes sociales, blogs y podcasts sigue siendo posible
  • Otros sistemas públicos de reporte de bugs de Apple quedan excluidos
    • Sistema de bugs de WebKit
    • GitHub, donde están varios proyectos open source de Apple
  • Se considera que otros sistemas de reporte de bugs son mejores que Feedback Assistant en varios aspectos
  • El primer objetivo es cambiar al propio Feedback Assistant, criticado como el reportero de bugs más hostil que se ha visto hasta ahora

Problemas recurrentes en Feedback Assistant

  • Incluso cuando Apple recibe pasos exactos para reproducir un error y un proyecto de ejemplo de Xcode, no informa o se niega a revelar si puede reproducir el bug reportado
    • A los desarrolladores les resulta difícil saber si Apple está tomando el Feedback en serio o si solo está demorando el proceso de manera burocrática
  • El Feedback se cierra con el estado Investigation complete - Unable to diagnose with current information sin pedir más información ni avisar que será cerrado
  • El Feedback se cierra sin el consentimiento de quien lo envió, y actualmente parece ser una “función” del sistema que ni siquiera los empleados de Apple puedan reabrir un Feedback cerrado
  • Si Apple cierra por error el Feedback de un bug que aún no ha sido corregido, en lugar de crear un nuevo Feedback para ese mismo bug y comunicar su número, exige al desarrollador que abra otro
  • Se pide verify del Feedback en la beta más reciente incluso cuando no se ha corregido el bug ni se ha intentado corregirlo o reproducirlo
    • Si el desarrollador no hace la verificación, ese Feedback se cierra
    • Se considera que este proceso desperdicia mucho tiempo de los desarrolladores
  • En el caso de Feedback cerrados como duplicados, los cambios de estado del Feedback original no siempre se comunican
  • Apple pide con frecuencia reportes intrusivos de sysdiagnose y parece no querer revisar el Feedback si no se entregan
    • Muchos desarrolladores trabajan en dispositivos personales
    • Se considera que sysdiagnose invade gravemente la privacidad que Apple presenta como un derecho humano básico
    • Se critica que Apple no haya creado, o haya abandonado, métodos más pequeños, específicos y menos intrusivos de recolección de información y diagnóstico
  • Recientemente ya no se pueden enviar Feedback desde la web
    • Ahora se exige usar solo la app nativa Feedback Assistant en macOS o iOS
    • Se indica que durante años se enviaron Feedback mediante la app web, y que el último envío web fue el 26 de octubre
  • Los desarrolladores no pueden buscar bugs dentro de Feedback Assistant
    • Los empleados de Apple sí pueden buscar en la base de datos, pero los desarrolladores externos solo pueden ver los Feedback que ellos mismos enviaron
    • Algunos Feedback deben mantenerse en secreto, pero muchos no lo requieren, y se considera que una base de datos de bugs con búsqueda opcional por consentimiento ayudaría a los desarrolladores externos y a la calidad del software de las plataformas de Apple

Respuesta a la objeción de que “Apple tampoco tiene tiempo”

  • No se está de acuerdo con la defensa de que Apple no tiene tiempo para responder adecuadamente al Feedback
  • Las prioridades, calendarios y asignación de personal dependen de decisiones del liderazgo de la empresa
  • Se critica que Apple valora más su propio tiempo que el de los desarrolladores y que parece no sentir culpa por desperdiciar su tiempo de forma indefinida
  • Si Apple puede decidir que no tiene tiempo para responder al Feedback, entonces los desarrolladores también pueden decidir que no tienen tiempo para enviarlo
  • Desde la perspectiva de usuarios veteranos de Apple, no es indispensable repetir actualizaciones del sistema operativo cada año, y se recuerda que en la época de Mac OS X Snow Leopard las actualizaciones con intervalos de unos dos años dejaban más tiempo para corregir bugs

No va contra ingenieros individuales, sino contra el sistema

  • Este boicot no apunta contra ingenieros individuales de Apple
  • Se considera que muchos ingenieros de Apple también quieren que Feedback Assistant mejore
  • Mejorar Feedback Assistant podría fortalecer, en lugar de dañar, la relación entre los ingenieros de Apple y los desarrolladores externos
  • El objetivo del boicot es el sistema de reporte de bugs, y busca hacer que el liderazgo de Apple reconozca y responda a problemas persistentes

Trabajo de QA no remunerado y la elección de los desarrolladores

  • El boicot también puede llamarse una huelga laboral
  • Apple utiliza a los desarrolladores para una gran cantidad de trabajo de QA no remunerado
    • Un solo Feedback puede implicar horas o incluso días de trabajo
    • Tanto Apple como los desarrolladores saben que estos últimos cumplen un papel importante al probar y pulir el software y los productos de Apple
  • Se critica que Apple trate el Feedback de los desarrolladores como si fuera un derecho adquirido, mientras que en el sistema de reporte de bugs no ofrece respeto ni cortesía básica a los desarrolladores
  • Se ha acostumbrado a los desarrolladores a creer que enviar Feedback por el bien de la plataforma es una obligación, pero las plataformas de Apple no son una obra de caridad
  • Las plataformas de Apple convirtieron a Apple en la empresa más rentable del mundo, y como los desarrolladores externos no son empleados de Apple, no debería darse por sentado su trabajo no remunerado

Los dos objetivos del boicot

  • El primer objetivo es demostrar que Apple necesita los reportes de bugs de los desarrolladores y que, sin ellos, Apple sale perdiendo, presionando así para mejorar Feedback Assistant
  • El segundo objetivo es que los propios desarrolladores confirmen que en realidad no necesitan reportar bugs a Apple
  • Se considera que muchos de los bugs enviados al final no se corrigen y, aun cuando se corrigen, muchas veces ya es demasiado tarde para evitar su impacto
  • Es cierto que los bugs de Apple afectan a las apps, pero como es difícil esperar que Apple los arregle a tiempo, los desarrolladores normalmente distribuyen sus apps con workarounds
  • Una vez implementados esos workarounds, la urgencia de que Apple arregle el bug disminuye, y reportarlo se vuelve algo más cercano a la caridad que a una necesidad

Redefinir el papel de Feedback Assistant

  • Se considera que Feedback Assistant no es un sistema que preste servicio al desarrollador
  • Más bien, han sido los desarrolladores quienes han estado prestando servicio a Feedback Assistant, y ahora eligen retener ese servicio hasta que el sistema mejore
  • Se espera que Apple resuelva los problemas de Feedback Assistant, pero existe la disposición de mantener el boicot de forma permanente si no hay mejoras
  • Independientemente de si Apple responde positivamente o no, el boicot se considera un éxito si participan muchos desarrolladores y se confirma que Feedback Assistant no es esencial para su trabajo ni para su sustento

Actualización del 7 de noviembre de 2023

  • El boicot a Feedback Assistant ahora tiene una página web oficial
  • Esa página también ofrece una dirección de correo electrónico, un feed RSS y una cuenta de Mastodon
  • Además, se está editando una lista pública de participantes del boicot, y en esa página se pueden consultar más detalles

1 comentarios

 
GN⁺ 2023-11-07
Opiniones de Hacker News
  • Estimo que solo recibí una respuesta o confirmación en alrededor del 10% de los reportes que envié mediante Feedback Assistant.
    Era un bug que se reproducía el 100% de las veces en iOS, e incluso proporcioné un proyecto de muestra aislado. Toma tiempo elaborar un reporte de bug cuidadoso y detallado, y cuando no hay ninguna respuesta es realmente frustrante; me identifico mucho con este texto.

    • Totalmente de acuerdo. Trabajo en seguridad y envié a Apple una evasión de las políticas de restricciones parentales en iOS, y me dijeron que la mandara por Feedback Assistant.
      Probarla, reproducirla y documentarla requiere tiempo y esfuerzo. No quería nada a cambio; solo esperaba que lo arreglaran, y mis hijos también usan iPhone.
      Otras empresas no son muy distintas. Envié a Cisco una vulnerabilidad de ejecución remota de código y respondieron que ya la conocían, pero que no la iban a corregir porque el producto estaba cerca del fin de su ciclo de vida.
      A lo largo de los años me he topado con muchas vulnerabilidades, pero si no me pagan por encontrarlas, normalmente termino ignorándolas. No vale la pena frustrarse.
    • Si es así, me pregunto por qué molestarse en enviarlas. Visto con cinismo, es ofrecer gratis trabajo de ingeniería de alta calidad a la que ya es la empresa más valiosa del mundo. Apple no necesita más ayuda.
    • 10% hasta me da envidia. En mi caso es 0%.
      He enviado reportes de bugs bien hechos, con pasos para reproducirlos, mi propia investigación y detalles, y aun así silencio. Se siente como si la app simplemente mandara los bugs a /dev/null.
    • A mí me pasa algo parecido. La verdad, últimamente cada vez me estoy cansando más de varias cosas de Apple.
  • Un boicot o una huelga solo es efectiva si participa la mayoría, o casi todos. Porque uno solo se suma cuando está seguro de que casi todos van a participar.
    Si esta publicación de blog hace que solo el 0,1% de los desarrolladores entre en huelga, a Apple ni le va a importar.
    La idea de una huelga de desarrolladores en sí es excelente, pero si empieza con un llamado a la acción de una sola persona, Jeff Johnson, normalmente es difícil que genere un cambio de comportamiento.
    Para organizarla, primero habría que contactar directamente a entre 50 y 200 desarrolladores importantes, conocidos y respetados, conseguir que firmen en conjunto y luego publicar una carta abierta. Así todos podrían ver que no es el deseo de una sola persona, sino una huelga seria impulsada por gente que sabe del tema.
    También tendría que aparecer en los principales medios tecnológicos, para que la vean tanto Apple como los desarrolladores.
    Y esa carta no debería ser una lista de todas las quejas, sino plantear acciones concretas y verificables que Apple tendría que tomar para terminar la huelga. No puede convertirse en una demanda sin fin, ni en una lista de deseos del tipo “arréglenlo todo de inmediato”, sino en avances realistas con fechas e hitos.
    Si van a hacer huelga, hay que organizarse de verdad. Una publicación de blog que dice “invito a todos los desarrolladores de Apple a sumarse” no es organización, y escribir que uno está en huelga no hará que alguien aparezca mágicamente a organizarla por uno.
    Como el autor dice más abajo, aquí la llamo huelga porque se trata menos de un boicot de dejar de comprar y más de dejar de aportar trabajo gratuito.

    • Él ya es bastante conocido en la comunidad de desarrolladores de Apple, y antes del anuncio también recibió muchas reacciones positivas en redes sociales. Dicho eso, creo que estás sobreestimando la voluntad y el esfuerzo que yo u otros desarrolladores pondríamos en mejorar Feedback Assistant.
      Esto no es un asunto claramente importante como una lucha por mayores ingresos. La ventaja de esta huelga es que los pasos 1 a 3 del inicio del texto requieren poco esfuerzo de todos, así que cualquiera puede participar fácilmente si quiere.
      Como también se dice al final del texto, uno de los objetivos es demostrarnos a nosotros mismos que, en realidad, podemos vivir sin Feedback Assistant. Tenemos muy poco que perder, participar en el sistema de reporte de bugs no es esencial para nosotros y simplemente podemos irnos.
      Esta huelga no es una batalla a vida o muerte que haya que ganar a cualquier costo. Por más persistentemente malo y molesto que sea Feedback Assistant, debería tener baja prioridad profesional.
      Más bien creo que esa actitud nos da poder de negociación frente a Apple. Nosotros solo somos voluntarios que se retiran de una “oportunidad” de voluntariado pésima, pero Apple depende de nuestro trabajo gratuito para sus productos comerciales, y si quiere reemplazarlo tendrá que contratar a más empleados de verdad y pagarles.
    • La frase “solo participo cuando estoy seguro de que casi todos participarán” definitivamente es cierta en el trabajo asalariado tradicional, pero esta no es esa situación.
      Nadie renuncia a su sueldo por dejar de usar Feedback Assistant. El costo de participar en esta huelga es muy bajo y, para la mayoría, participar quizá cueste menos que no participar.
      Por eso veo la posibilidad de que, con el tiempo, crezca hasta convertirse en una huelga influyente de una forma que sería difícil en un conflicto laboral tradicional.
    • En el fondo, una huelga así parte de la premisa de que a Apple le importan los reportes gratuitos que recibe de los desarrolladores. No estoy seguro de que eso sea cierto.
      Incluso si lo fuera, Apple tiene suficientes otros reportes o funciones por procesar, así que puede que no le afecte demasiado que desaparezcan todos los reportes de bugs externos.
    • Apple puede ser indiferente ante el boicot de una minoría a un proceso, pero su organización de relaciones públicas y comunicación es extremadamente sensible a la opinión negativa. Me imagino que a estas alturas ya debe haber bastantes correos circulando.
  • Ojalá cambiara la forma en que Apple gestiona los bugs. Es realmente desmotivador reproducir un bug, escribir el tipo de reporte que a mí me gustaría recibir, incluso con un caso de prueba mínimo, y luego no saber nada durante años hasta que lo cierran o te mandan un mensaje pidiéndote que hagas más trabajo para confirmar si el problema sigue existiendo.
    Me pregunto si hay alguna empresa de un tamaño cercano al de Apple que haga bien esto.
    Se me ocurren muchas razones por las que este es un problema difícil, y entiendo que asignar personal también debe ser complicado. Pero a Apple le pagan por resolver este problema, y no lo está resolviendo.

    • El problema fundamental es que, desde el primer paso, el usuario tiene que hacer todo ese trabajo. Entonces no hay forma de decirle que ese trabajo fue un desperdicio, porque ya lo hizo.
      Por eso, en general, creo que al reportar un bug es mejor hacer menos trabajo. Eso sí, el contenido que se incluya debe ser cuidadoso y claro.
    • Me harté tanto de los bugs de Apple que vendí todos mis productos Apple y compré una PC. Al menos ahora me encuentro con bugs nuevos e interesantes que nadie va a cerrar.
  • Me identifico. Incluso cuando presentas Radar dentro de Apple, muchas veces recibe un trato parecido. Aunque al menos puedes ver el estado del Radar.

    • Nos quejamos de lo mal que tratan a los desarrolladores externos, pero en general parece que Apple los trata más o menos igual que a sus propios empleados.
    • Al final, parece indicar que falta gente a la que le guste corregir bugs.
      Me refiero a gente dedicada a arreglar bugs, hacer ajustes finos y cuidar la base de código como si fuera un jardín.
  • Las acciones pesan más que las palabras. Apple está mostrando con sus acciones lo que piensa de los desarrolladores.
    Para cambiar el comportamiento de Apple, habría que armar un escándalo bastante grande. Con la montaña de efectivo sobre la que está sentada, Apple tiene muy pocos incentivos para cambiar.

    • Nunca pensé que llegaría a extrañar los tiempos en que Steve Ballmer gritaba “DEVELOPERS! DEVELOPERS! DEVELOPERS!!!”.
      Apple parece ver a los desarrolladores externos como una especie de plaga. Los sistemas y procesos que les impone parecen diseñados activamente para desalentarlos.
  • Publicación anterior: https://news.ycombinator.com/item?id=3947903
    Ahora me siento tremendamente viejo.
    Actualización: por fin encontré la carta modelo completa [1]. En su momento envié una copia, y todavía aparece abandonada en Feedback Assistant.
    [1]: https://gist.github.com/mysteriouspants/1989061

  • A veces sí hace falta reportar bugs a través de Feedback Assistant. Es cuando encuentras a un desarrollador dentro de Apple, esa persona dice que va a corregir el bug y solo necesita un número de feedback para el reporte interno de trabajo.
    Enviar reportes de bugs no solicitados es simplemente una pérdida de tiempo. No es tanto que esté “boicoteando” Feedback Assistant; más bien dejé de usarlo porque no sirve para nada útil.

    • ¿Cómo se supone que encuentre dentro de Apple a un desarrollador que vaya a arreglar mi problema?
  • Como desarrollador, me niego por completo a involucrarme con Apple de cualquier forma. La razón es la cuota anual de 100 dólares.
    Cada vez que salen a la luz cosas como esta, siento que mi decisión queda especialmente justificada.
    Imaginen que la empresa más rica del mundo te cobre por el privilegio de contribuir a su plataforma.
    Es una locura total, y nada de lo que digan me va a hacer cambiar de opinión.

    • Una de las razones para cobrar la cuota es filtrar a los malos actores o a la gente que no es lo bastante seria como para publicar una app en la tienda.
      Aun así, podrían hacerlo como Google, con un pago único, y también más barato.
    • Emocionalmente estoy de acuerdo, pero Apple probablemente diría que en realidad está cobrando por el acceso a la red de distribución.
  • Espera, ¿eso significa que ahora no se puede enviar feedback desde la web? Es realmente una estupidez absurda.
    La propia app Feedback también está rota a medias, así que aunque Apple quisiera, creo que no podría recibir mis reportes.

  • Hace tiempo escribí en un blog sobre lo descuidada que era Apple con los desarrolladores web en relación con Safari [1].
    Viendo esto, parece que Apple también descuida a otros desarrolladores y, sinceramente, no sorprende.
    [1] https://www.construct.net/en/blogs/ashleys-blog-2/safari-rel...

    • Resolví este problema tratando a ese navegador como legado y de mejor esfuerzo, como en los tiempos de IE11.
      Apple rompe con frecuencia muchas cosas, no solo funciones de punta, sino también funciones básicas. Sus prácticas de testing no parecen particularmente buenas.