Material original: The GNOME Release Team (3 de Abril de 2009)
Traduzido por: Tiago Paranhos Lima (8 de abril de 2009)
Durante os primeiros meses de 2008, alguns membros do Time de Lançamento discutiram sobre o estado do GNOME. Não foi nada oficial, e isto poderia de fato ser considerado como alguns amigos falando sobre coisas com as quais se importam muito. Alguns achavam que o GNOME deveria continuar no branch 2.x por muito tempo dado nossos sólidos métodos de desenvolvimento, mas este não era o futuro que a nossa comunidade deseja ver acontecer. Por motivo da falta de excitação. Devido à falta de visão. Lentamente, um plano começou a emergir. Ele evoluiu, mudou, foi se tornando mais sólido. Começamos discutindo com mais algumas pessoas, conseguimos mais feedback. E assim, na GUADEC, o Time de Lançamento propôs um plano inicial para a comunidade que levaria o projeto ao GNOME 3.0. Mais algum tempo se passou; na verdade, muito tempo se passou porque muitas pessoas estavam ocupadas com outras coisas. Mas nunca é muito tarde para fazer a coisa certa, então vamos levar a sério o GNOME 3.0 agora!
Primeiro vamos divergir um pouco e discutir sobre a impressão geral de que o GNOME está precisando de “visão”. Se você observar nossa comunidade de perto, seria errado dizer que as pessoas estão sem visão; mas o projeto como um todo parece ter esse problema. O que nos falta são pessoas “abençoando” uma visão específica e tornando-a oficial, oferecendo objetivos à comunidade para que possamos todos trabalhar juntos na mesma direção. Nos dias pré-2.x, a comunidade como um todo aceitava uma visão específica, e esta “benção” não era necessária. Mas durante o ciclo 2.x, com nossos calendários de 6 meses, parecia que tudo (comunidade, processo de desenvolvimento, etc.) estava funcionando tão bem, e como a visão foi cada vez mais sendo atingida, os termos de longo prazo tornaram-se menos importantes e nos focamos em polir nosso desktop. Mas agora alcançamos um ponto onde nossos próximos passos devem nos levar a um outro nível, e estes próximos passos requerem decisões importantes. Isto é parte do que um Time de Lançamento deve fazer. Observe que os membros do Time de Lançamento não tem que ser aqueles que possuem a visão; “apenas” temos que ser a voz da comunidade.
(Para efeito de nota, o processo de roadmap que tentamos reestabelecer a 2 anos atrás foi uma primeira tentativa de consertar isto. Infelizmente, o que aconteceu foi que nos faltava o mais importante: um roadmap para o projeto como um todo. Isto porque uma coleção de roadmaps individuais não é o suficiente para criar um roadmap para o projeto como um todo.)
Então vamos para o tópico principal, discutir o que o esforço do lançamento do GNOME 3.0 deveria ser. Propomos a seguinte lista de áreas nas quais devemos focar nossos esforços:
* Renovar nossa Experiência de usuário
* Simplificação da Plataforma
* Promoção do GNOME
Existem também outras áreas potenciais que são dignas de exploração se houver interesse suficiente da comunidade.
A partir de uma perspectiva de gerenciamento de lançamento, existem várias questões que são levantadas no contexto do GNOME 3.0. Definitivamente precisamos de um plano para organizar o desenvolvimento (veja abaixo mais detalhes sobre isso), mas também precisamos aproveitar esta oportunidade para pensar em como nós entregamos o GNOME: os conjuntos de módulos ainda são a melhor maneira de entregar o GNOME? Não existe uma resposta óbvia para isto, mas a forma na qual iremos apresentar o GNOME no futuro certamente terá um impacto nisso.
MUDANDO NOSSA EXPERIÊNCIA DE USUÁRIO
Quando falamos com algumas pessoas na GUADEC sobre o GNOME 3.0, uma preocupação recorrente foi a de que seria um erro fazer o GNOME chegar à versão 3.0 sem alguma grande mudança visível aos usuários. Embora alguns de nós não necessariamente entrem em consenso sobre isso, ainda assim isso era uma preocupação válida. Mas parece que se você diz à comunidade que haverá algo após o 2.x, então a comunidade irá parar de pensar vagamente sobre idéias futuras e irá começar a trabalhar em planos concretos.
Parece bem claro agora que existem 2 idéias importantes que podem ter um impacto realmente positivo na experiência de usuário:
* GNOME Shell: a idéia do shell não é apenas sobre mudanças no painel e no gerenciador de janelas. É sobre mudar a forma através da qual você inicia uma atividade e como você alterna entre 2 atividades diferentes. Ou de forma mais geral, em como você gerencia atividades diferentes no desktop.
* Mudar a forma através da qual acessamos documentos (através de um journal, como o GNOME Zeitgeist): ter que lidar com um sistema de arquivos em seu trabalho diário não é o que torna os usuários felizes — pelo contrário, eles geralmente querem apenas acessar seus documentos e não navegar em seu disco rígido. Prover novas soluções para este problema (usando linhas de tempo, tags, bookmarks, etc.) é algo que tem sido de interesse da nossa comunidade por um longo tempo, mas nunca imergimos completamente nisso. E deveríamos.
Estas 2 idéias podem formar a base para uma experiência GNOME revisada; e não são as únicas mudanças que podemos e iremos fazer, mas elas definitivamente são os projetos mais avançados para nos ajudar a dar o próximo passo em termos de experiência de usuário. Os projetos GNOME Shell e GNOME Zeitgeist na verdade já estão progredindo, com código em andamento e um forte desenvolvimento já acontecendo há aproximadamente 6 meses. Isso quer dizer que o esforço não é sobre iniciar estes projetos, mas sobre primeiro completá-los para que as pessoas possam trabalhar diariamente com eles, e então melhorá-los.
Existe uma questão óbvia relacionada a estas mudanças potenciais: o que irá acontecer com a velha maneira de fazer as coisas? Por exemplo, ainda iremos deixar o Painel GNOME disponível se, por alguma razão, as pessoas não estiverem imediatamente felizes com o GNOME Shell? Não há uma resposta óbvia para isto, que terá que ser discutido. Alguns de nós acreditam que pode ser algo bom continuar provendo os elementos antigos por um tempo limitado, para facilitar a migração. Isto sendo dito, tornar isto realidade obviamente irá demandar recursos de desenvolvimento e desacelerar o trabalho no que deveria ser o futuro. Não é uma escolha fácil, claro. Todavia, é válido observar que as distribuições e outros membros da comunidade usando o GNOME para construir produtos enterprise irão certamente ajudar a manter o shell GNOME 2.x ainda por algum tmepo, e que o projeto irá suportar isto da melhor maneira possível.
SIMPLIFICAÇÃO DA PLATAFORMA
Uma vez que o GNOME 2.0 foi lançado em 2002, tem havido algumas mudanças em nossa plataforma de desenvolvimento: novas APIs foram criadas e outras tornaram-se obsoletas. Existem ainda algumas bibliotecas da plataforma que agora são muito pouco utilizadas. Isso cria alguma confusão e não facilita a vida dos desenvolvedores. Uma vez que desejamos que as aplicações sejam desenvolvidas para o GNOME, isto é um problema que precisamos consertar.
Além disso, faz perfeito sentido retrabalhar nossa plataforma e tentar torná-la mais clara para recém-chegados. Aqui existem alguns passos que devem ser considerados:
* mover todas as bibliotecas obsoletas para fora da plataforma, para que as pessoas parem de utilizá-las em novos códigos;
* criar uma área de “estágio” na plataforma para bibliotecas que desejam estar em nossa plataforma mas não oferecem garantias suficientes no momento (como o GStreamer): isto irá tornar claro o que deve ser usado;
* incluir novas e excitantes tecnologias que estão começando a se utilizadas em nosso desktop. Exemplos óbvios são efeitos 3D (com o Clutter) e geolocalização (com GeoClue e libchamplain).
* retrabalhar a forma em que apresentamos a plataforma para integrar também algumas dependências externas: como, digamos, D-Bus ou Avahi são dependências externas, elas são definitivamente o que desejamos que os desenvolvedores usem. E é fácil ser mais explícito sobre isso.
* mover os bindings para mais perto da plataforma quando falamos sobre bindings, para torná-los ainda mais visíveis e atrair desenvolvedores de todas as linguagens.
O trabalho que tem sido feito na introspecção GObject também irá mudar profundamente a forma em que desenvolvimento GNOME pode ser feito; já começamos a ver como isso pode ser alavancado no GNOME Shell, e o fato de que ela pode trazer novas linguagens populares como Javascript para o GNOME é um enorme benefício.
Tudo isto tem, é claro, impacto em nossas aplicações: teremos que portar novo código das APIs pbs, mas também preparar nossas aplicações para as mudanças vindouras, como o GTK+ 3.0. Por sorte esta é uma tarefa que pode ser mensurada facilmente e seu progresso pode ser acompanhado em uma simples web page.
PROMOÇÃO DO GNOME
Nossa comunidade tem historicamente sido forte no lado do desenvolvimento, mas temos sempre lutado para promover o GNOME. Porque isto certamente não é uma tarefa fácil. Nossa base de usuários tem todavia crescido significativamente desde que nosso projeto começou, e falhamos em recrutar pessoas que poderiam ter ajudado aqui. O GNOME 3.0 é uma oportunidade de mudar isto e atrair colaboradores que possam ajudar a forjar a comunicação em torno do projeto GNOME. A promoção do projeto é definitivamente parte do que faz um bom lançamento, e o Time de Marketing pode contribuir muito para o sucesso do 3.0.
Claro que um objetivo óbvio da promoção do GNOME neste contexto seria preparar o lançamento 3.0 e a comunicação em torno deste release. Depois de destacar as mudanças feitas especificamente para o 3.0, outra idéia imediata é simplesmente mostrar o progresso que o projeto GNOME tem feito desde o GNOME 2.0: O GNOME 2.10 poderia ter sido nomeado como 3.0 se comparado ao 2.0, e o mesmo pode-se dizer do 2.20. Isto poderia servir como uma base para o trabalho de explicar porque nossa abordagem evolucionária no desenvolvimento funciona bem.
Um ponto comum que geralmente vinha à tona quando discutíamos sobre como promover o GNOME era que promover o desktop como um todo é difícil. Mas não há necessidade de fazer isso. Podemos ao invés disso focar nossa comunicação em torno da experiência GNOME: a experiência GNOME básica é simplesmente o GNOME Shell; mas os usuários não querem só um desktop básico, eles usam aplicações. Nunca explicamos porque as aplicações desenvolvidas para o GNOME são boas; nunca realmente colocamos estas aplicações sob os holofotes. Por exemplo, porque não poderíamos por na página principal do website do GNOME uma mensagem clara sobre um bom gerenciador de músicas? Não deveríamos ter que escolher entre o Rhythmbox ou o Banshee: podemos promover ambos, uma vez que ambos são bons de formas diferentes, e ambos são bons exemplos da experiência GNOME.
Isto nos leva a um terceiro item: relançar nosso website. Enquanto nosso website atual é conhecido por ser defasado de várias formas diferentes sob o ponto de vista da comunicação, não temos sido capazes de liberar uma nova versão que pudesse consertar estas coisas. Consertar o website é uma grande tarefa, mas não deveríamos desistir disso: o website GNOME é parte principal da identidade GNOME, e não podemos ignorar os problemas atuais. Isto aconteceu por falta de mão-de-obra, mas a boa notícia é que existem desenvolvedores web que são apaixonados pelo GNOME e apenas não sabem como ajudar o projeto.
E o fato de que desenvolvedores web podem ter um importante papel também é válido para todos os nossos usuários. Atualmente, não estamos realmente dando poder aos nossos usuários para promoverem o GNOME: o que um usuário deveria fazer se ele quisesse fazer isso? Sabemos todos como alguma comunicação viral pode beneficiar um projeto como o nosso, então a solução é simples: vamos dar a nós mesmos a chance de isso acontecer!
OUTRAS ÁREAS POTENCIAIS
As áreas apresentadas acima não são uma grande surpresa para aqueles que acompanham o desenvolvimento do GNOME e são escolhas óbvias. Todavia existem outros candidatos que podem tornar o GNOME 3.0 um sucesso. Esta áreas de foco potencial apenas precisam de pessoas que deem um passo a frente para que as expectativas possam ser cumpridas.
* Testes do Desktop: com a criação recente do Time de Teste do Desktop, este tópico se torna mais e mais visível. Podemos inovar lá, e realmente deveríamos: ajudamos a mostrar o caminho no mundo do software livre quando se fala de usabilidade e acessibilidade, e não há motivos para não focarmos em uma experiência similar para os testes de desktop.
* Arte: Uma hackfest sobre a API GTK+ Theming aconteceu em fevereiro, quando algum consenso foi atingido sobre como os temas devem ser feitos no futuro. Isso nos dá uma nova oportunidade para um look and feel mais atualizado. Isto pode acontecer com a ajuda de artistas: se tivermos artistas e programadores trabalhando juntos, com os programadores sabendo das necessidades dos artistas, então não há dúvidas de que os resultados simplesmente vão arrasar.
* Pessoas: o framework telepathy tem progredido muito bem durante os últimos anos e está oferecendo grandes perspectivas para integrar mensagens instantâneas e, de forma mais geral, a interação com pessoas em outras aplicações. Com algum foco, ele poderia contribuir para tornar o GNOME um desktop social onde você não apenas trabalha em documentos, mas também interage com seus amigos.
* Mobile: A plataforma GNOME Mobile foi introduzida pela primeira vez no GNOME 2.24, e ajudou a tornar visível nossa presença no mundo mobile. Muitas das mudanças que estão planejadas sobre a plataforma são de interesse direto do Time Mobile.
ORGANIZANDO O DESENVOLVIMENTO
Precisamos definir um timeline claro para o desenvolvimento, com um calendário que nos permita checar se ele está no caminho certo. O objetivo final é simples: queremos entregar o GNOME 3.0 a tempo do release 2.30. Isto faz sentido por vários motivos: de uma perspectiva técnica, o timing é bom para a integração de novas tecnologias ou projetos (o GNOME Shell, por exemplo); sob um ponto de vista de comunicação, a evolução do 2.30 para o 3.0 é lógica e fácil de entender. É válido apontar para o fato de que se você comparar o GNOME 2.26 com o GNOME 2.0, é realmente surpreendente ver que ainda tenhamos mantido a numeração 2.x enquanto poderíamos estar no 3.x, ou até mesmo no 4.x. Tornar o GNOME 2.30 3.0 é, claro, um objetivo ambicioso, mas podemos fazer isso graças ao que aprendemos no passado.
Os métodos de desenvolvimento que adotamos durante o GNOME 2.x são métodos bons no geral e a comunidade tem estado acostumada a eles. Por exemplo, os colaboradores entendem as razões dos freezes que possuímos e fazem o seu melhor para respeitar estes freezes. Isto não é algo que deve ser mudado porque agora temos a oportunidde de tentar de outra forma; pelo contrário, estes métodos irão tornar o caminho para o 3.0 mais fácil. Algumas regressões foram apontadas durante os últimos ciclos: isto não deve ser ignorado e acreditamos que parte das razões pelas quais elas aconteceram é que apenas uma pequena parte de nossa comunidade estava tentando seguir adiante, o que criou alguma controvérsia; possuir um foco como comunidade deveria limitar estas controvérsias, e desta forma também as regressões como sentidas pela comunidade.
O ciclo de 6 meses é agora parte de nossa cultura e tem um impacto no ecossistema do software livre, com distribuições baseando seus calendários no nosso. Tentar mudar este elemento crucial do gerenciamento de nosso lançamento, que funciona muito bem, certamente não iria nos ajudar de forma alguma. Logo, iremos manter nossos calendários de 6 meses. Mas possuir objetivos como projeto e a longo prazo requer alguma adaptação. O GNOME 2.28 não será um lançamento independente ou um destino em si mesmo, mas será um passo lógico em direção do GNOME 2.30, e portanto para o GNOME 3.0.
Claro, deveríamos estar preparados para considerar o fato de que o GNOME 2.30 pode não estar bom o suficiente para o chamarmos de 3.0. Todos os nossos lançamentos agendados são também baseados em qualidade: se o Time de Garantia de Qualidade sentir que um release deva ser adiado, então ele será adiado. No contexto do 3.0, isto é algo que devemos estar preparados para diagnosticar durante o ciclo de desenvolvimento do 2.29 e não devemos ter medo de manter o GNOME 2.30 como 2.30 e esperar o GNOME 2.32 para o lançamento do 3.0, por exemplo. Isto estando dito, queremos que a comunidade tente o mais arduamente possível tornar um sucesso “GNOME 2.30 = GNOME 3.0″.
Em uma nota mais geral, sobrepor um ciclo de desenvolvimento de longo prazo (3 anos por exemplo) com metas em nível de projeto no topo de nossos agendamentos de desenvolvimento de 6 meses é algo que queremos manter após o GNOME 3.0.
CONCLUSÃO
Você já pode checar o agendamento dos ciclos de desenvolvimento das versões 2.27 e 2.29. Eles contem alguns passos concretos e deadlines que irão manter nosso projeto focado para tornar o GNOME 3.0 uma realidade.
Como já mencionado, isto é um plano ambicioso e irá somente ser concretizado se todos ajudarem. Companhias podem contribuir muito — por exemplo, o esforço GNOME Shell está indo bem graças ao envolvimento da Red Hat. Mas o GNOME sequer existiria sem todos os voluntários que são apaixonados pelo projeto. E é porque esta paixão é tão forte que podemos constuir um plano como este!
Estamos chegando lá. Acreditamos fortemente que tudo isto pode ser um bom plano para o GNOME. Claro, não é perfeito. E haverão controvérsias e problemas ao longo do caminho. Mas este é o caminho a seguir.
Time de Lançamento do GNOME
***
Material originalmente publicado no seguinte endereço: http://live.gnome.org/ThreePointZero/Plan. Esta é uma tradução livre com o único intuito de disseminar conhecimento entre a comunidade de usuários linux do Brasil. Todos os direitos e idéias divulgados aqui são de propriedade dos autores originais. Para sugestões/críticas/errata, utilize o espaço para comentários desse tópico ou envie um e-mail para tiagoprn@gmail.com.
***