Sự kiên gan bền bỉ điên cuồng
Mark Shuttleworth's Radical Vision
Insane Persistence
Thursday, October 1, 2009 04:49:57 PM
Theo: http://www.linuxplanet.com/linuxplanet/reports/6861/1/
Bài được đưa lên Internet ngày: 01/10/2009
Lời người dịch: Mark Shuttleworth đưa ra tầm nhìn mới cho việc phát triển các phần mềm tự do nguồn mở. Đó là Nhịp độ, Chất lượng và Thiết kế, và ông cũng thể hiện rằng ông tin tưởng, trung thành và chuyên tâm cho Phần mềm tự do. Ông nói: “Mọi người thường hỏi tôi vì sao tôi quá bị quyến rũ bởi phần mềm Tự do, và vì sao tôi đặt quá nhiều thời gian, năng lượng và tiền bạc vào Ubuntu... Tôi thực sự tin tưởng sự tiến triển của phần mềm Tự do là đúng cách để xây dựng các phần mềm”
Bài phát biểu chính của Mark Shuttleworth tại hội nghị Linux – Linucon – đã gây được nhiều sự chú ý. Một số người cho là nhân vật nổi danh lớn của Linux, một số cho là việc đưa ra một số bình luận đáng tiếc, và một số ít cho thông điệp thực sự của ông. Tôi sẽ nói về thông điệp thực sự của ông vì nó là tưởng tượng và quan trọng. Tôi khuyến cáo rằng bất kỳ ai mà nghiêm túc về việc dốc hết thời gian và tài năng của họ cho Linux/FOSS, trong bất kỳ khả năng nào – lập trình viên, nhà thiết kế, nhà mỹ thuật, người viết tài liệu, người dịch, người bảo vệ về pháp lý, bất kể là gì – xem điều này như là nói cho chính mình. Cảm ơn về sự rộng lượng của Linux Pro Magazine và Quỹ Linux mà cái này là sẵn sàng trực tuyến. Bạn cũng có thể tải nó về tại http://techcast.com/events/linuxcon/shuttleworth/shuttleworth.flv.
Nhịp độ, Chất lượng, Thiết kế
3 điểm trong bài phát biểu của Shuttleworth là Nhịp độ, Chất lượng, Thiết kế, và chúng là tất cả các phần của một tầm nhìn được phối hợp cho tương lai sự phát triển của Linux. Nó là một tầm nhìn rất khác từ cách mà bây giờ đã được thực hiện. Hiện trạng là rất hướng vào các lập trình viên. Các lập trình viên phần mềm bắt đầu và duy trì các dự án, và chất lượng, trách nhiệm và đường lối của các dự án thường được kiểm soát bởi các lập trình viên. Tầm nhìn của Mark là rộng lớn hơn và tham vọng hơn nhiều:
“Mọi người thường hỏi tôi vì sao tôi quá bị quyến rũ bởi phần mềm Tự do, và vì sao tôi đặt quá nhiều thời gian, năng lượng và tiền bạc vào Ubuntu... Tôi thực sự tin tưởng sự tiến triển của phần mềm Tự do là đúng cách để xây dựng các phần mềm. Không chỉ thế, mà sẽ có tiềm năng, nếu chúng ta làm dấy lên trò chơi của chúng ta... rằng chúng ta có thể chấm dứt việc xác định kinh nghiệm là một người bình thường khi nào đó sẽ bật một chiếc máy tính”.
Mark Shuttleworth's Linuxcon keynote has gotten a lot of attention. Some for being the big Linux celebrity, some for making some unfortunate comments, and a small bit for his actual message. I'm going to report on his actual message because it is visionary and important. I recommend that anyone who is serious about devoting their time and talents to Linux/FOSS, in whatever capacity-- coder, designer, artist, documenter, translator, advocate, whatever-- watch this talk for yourself. Thanks to the generosity of Linux Pro Magazine and the Linux Foundation it is available online. You can also download it for local streaming: $ wget http://techcast.com/events/linuxcon/shuttleworth/shuttleworth.flv
Cadence, Quality, Design
Mr. Shuttleworth's three points are Cadence, Quality, Design, and they are all part of coordinated vision for the future of Linux development. It is a very different vision from how it's done now. The current state is very developer-centric. Software developers start and maintain projects, and the quality, responsiveness, and direction of projects are mainly controlled by the developers. Mark's vision is broader and more ambitious:
"People often ask me why I'm so fascinated by Free software , and why I put so much time, energy, and money into Ubuntu...I really believe the Free software process is the right way to build software. Not only that, but there is the potential, if we raise our game... that we could end up defining the experience that the average person has whenever they turn on a computer."
OK, nghe hay đấy, nhưng làm thế nào chúng ta tới được đó? Nhịp độ, từ thông dụng mới phổ biến, là về giá trị của các phiên bản được tung ra theo thời gian:
“Bản thân phiên bản là việc tiếp sinh lực một cách khổng lồ... phiên bản là sự bắt đầu của một con đường cho nhiều phần khác của cộng đồng và vì những người sử dụng của chúng ta. Khi bạn làm một phiên bản thì nó có tất cả các dạng lợi ích khác. Nó mở rộng nền tảng cơ bản của những người mà có thể tham gia... hãy nghĩ về tất cả những người khác trong cộng đồng mà họ muốn được giúp bạn để phần mềm của chúng ta đi ra được với thế giới: những người viết tài liệu, những người dịch, các nhà mỹ thuật, những người bảo vệ về pháp lý... mà công việc của họ bắt đầu mội khi bạn cam kết sẽ làm một phiên bản”.
“Nó cũng sản sinh ra một số lượng khổng lồ việc kiểm thử... cho mỗi một người mà đang quản lý một phiên bản phát triển của Ubuntu, sẽ có 10 người tải về và cố làm việc với phiên bản beta. Và rồi thì sẽ có 100 người mà họ thực sự sử dụng phiên bản cuối cùng... Những tương tác ngắn, chu kỳ ngắn hơn có nghĩa là việc kiểm thử nhiều hơn. Chúng cũng có nghĩa là sự ưu tiên hóa và lập kế hoạch tốt hơn... nếu bạn trao cho bản thân bạn một số thời gian ít hơn thì bạn sẽ nói với bản thân bạn những gì là quan trọng nhất đối với chúng ta phải làm cho xong?”
“Một phiên bản mang lại sự công khai hóa... chúng ta sẽ làm những thứ đáng ngạc nhiên. Một phiên bản là một cơ hội để đưa ra đó và nói về điều đó... nó mang tới nhiều người đóng góp, người tham gia và người sử dụng hơn”.
Ông đã sử dụng ví dụ về một đội phát triển Web mà có chu kỳ ra phiên bản theo từng tháng. Nhân Linux là theo chu kỳ 3 tháng “mà nó là ma thuật … nó là việc tiếp sinh lực mạnh mẽ”. Gnome và KDE có chu kỳ là 6 tháng.
Nhịp độ cũng là về việc phối hợp với dòng ngược lên trên (upstream) và các dự án khác. Có một số tiến triển trong việc phối hợp cho phiên bản Ubuntu LTS (hỗ trợ dài hạn) tiếp sau mà nó sẽ có nền tảng nhân y hệt và các gói cơ bản chủ chốt khác như Debian. Sẽ không có việc nghỉ tay và hát các bài hát, mà nó là một sự khởi đầu. Ông nghĩ rằng việc phối hợp các phiên bản chủ chốt sẽ làm cho cuộc sống dễ dàng hơn cho người sử dụng và những người duy trì các phát tán vì sẽ không có quá nhiều các phiên bản của các gói khác nhau trôi nổi quanh ta, và nó sẽ làm giảm thiểu xung đột lâu năm của những ai có trách nhiệm về một lỗi cụ thể nào đó. (Người sử dụng thích nói các lỗi chỉ để mà nói 'Không phải vấn đề của chúng tôi, hãy nói nó cho bất kỳ ai/dòng ngược lên/dòng xuôi xuống/dòng bên cạnh những không phải là chúng tôi').
Nó cũng sẽ giúp các lập trình viên bằng việc giảm thiểu số lượng các phát tán distro để cố gắng hỗ trợ, và cho phép hợp tác và lên kế hoạch tốt hơn.
Ok, sounds good, so how do we get there? Cadence, the popular new buzzword, is about the value of timed releases:
"The release itself is enormously energizing...the release is the beginning of the journey for many other parts of the community and for our users. When you make a release it has all sorts of other benefits. It broadens the base of people who can participate...think of all the other people in the community who want to be helping you get your software out to the world: documenters, translators, artists, advocates...their job begins once you commit to making a release.
"It also generates a tremendous amount of testing...for every one person who is running a development version of Ubuntu, there will be ten people who download and try and work with the beta release. And then there will be a hundred people who actually use the final release...Short interations, shorter cycles mean more testing. They also mean better prioritization and planning...if you give yourself a shorter amount of time you say to yourself "What are the most important things for us to get done?
"A release brings publicity...we're doing amazing stuff. A release is an opportunity to get out there and talk about that..it brings more contributors, participants, users."
He used the example of a Web development team that has a monthly release cycle. The Linux kernel is on a three-month release cycle "which is magical...it is energizing." Gnome and KDE are on six-month cycles.
Cadence is also about coordinating with upstream and other projects. There is some progress in coordinating the next Ubuntu LTS release so that it will have the same base kernel and other key base packages as Debian. They're not quite holding hands and singing songs yet, but it's a start. He thinks that coordinating major releases will make life easier for users and distribution maintainers because there won't be so many different package versions floating around, and it will reduce the perennial conflict of who is responsible for a particular bug. (Users love reporting bugs only to be told 'Not our problem, report it to upstream/downstream/sidewaystream/anyone but us')
It will also help developers by reducing the numbers of distros to try to support, and enabling better collaboration and planning.
Chất lượng
Đây là một chủ đề khó khăn tiềm tàng phải giải quyết vì sự phát triển của FOSS là mở và cá nhân. Tên của lập trình viên và mã nguồn ở đó cho tất cả mọi người cùng thấy. Về lý thuyết cái này dẫn tới các phần mềm tốt hơn vì các lập trình viên là có tính toán hơn, có nhiều lý do hơn để tự hào trong công việc của họ hơn, và bất kỳ ai (về mặt lý thuyết) cũng có thể đóng góp.
Ông nghĩ rằng các kế hoạch kiểm thử và việc kiểm thử tự động là các công cụ tốt cho kiểm soát chất lượng, và nói có một sự khác biệt rõ ràng giữa các dự án mà sử dụng chúng và các dự án mà không sử dụng chúng. Lợi ích khác là việc mở các cánh cửa cho các lập trình viên mới:
“... nhiều dự án dòng ngược lên trên ở dạng có vài anh bạn mà họ biết lẫn nhau thực sự tốt... đây là điều thực sự khó để đi qua các lỗ hổng thừ việc là ai đó mà họ có quan tâm, và thể hiện và muốn nói về nó, và có thể có một số mã nguồn để đóng góp, đối nghịch với việc tới được cái điểm nơi mà bạn là một trong những anh bạn đó... ”
“Có thể đối với một số người đây là phần vui vẻ, bạn có được hiệu ứng bè đảng này. Nhưng tôi nghĩ điều này gây hại to lớn cho khả năng của chúng ta để phát triển các dự án. Chỉ những người mà họ luôn kiên gan có thể vượt qua được những lỗ hổng này. Trong khi nếu bạn mở hơn đối với mã nguồn mà chúng tới từ những người mà bạn không biết rồi sau đó nó thực sự thú vị đối với những anh bạn này, thì họ sẽ đóng góp mã nguồn... và nó tạo động lực cho họ làm nhiều hơn nữa”.
Việc kiểm thử tự động làm giảm các mâu thuẫn và giữ uy tín vì “bạn không thể tranh luận với người máy”. Nó tìm ra các vấn đề mà không có việc chỉ trỏ ngón tay.
Việc rà soát lại mã nguồn cải thiện chất lượng mã nguồn và là một cơ chế khác cho việc làm cho những lập trình viên mới tham gia, và có những chương trình cho sự hợp tác từ xa sao cho họ không phải ở trong cùng một vị trí vật lý như nhau.
Ông đi một chút vào chi tiết về việc quản lý kiểm soát nguồn, các tính trình tự động hóa, kiểm tra các đầu và và ra, có được một sự ổn định, và những khía cạnh khác của việc quản lý dự án phần mềm.
Quality
This is a potentially sticky subject to address because FOSS development is open and personal. The developer's name and code are there for all to see. Which theoretically leads to better software because devs are more accountable, have more reason to take pride in their work, and anyone (theoretically) can contribute.
He thinks that test plans and automated testing are good tools for quality control, and says there is a clear difference between projects that use them and projects that don't. Another benefit is opening doors to new developers:
"...a lot of upstream projects take the form of a couple of guys who know each other really well...it's really hard to cross the chasm from being somebody who is interested, and shows up and wants to talk about it, and maybe has some code to contribute, versus getting to the point where you're one of those guys...
"Maybe for some people it's part of the fun, you have this cabal effect. But I think it's hugely damaging to our ability to grow projects. Only people who are insanely persistent can cross that chasm. Whereas if you're more open to code that's coming in from people you don't know then it's really exciting for those guys, they get to contribute code...and it energizes them to do more."
Automated testing reduces conflicts and saves face because "You can't argue with the robot." It finds problems without pointing fingers.
Code review improves code quality and is another mechanism for bringing new developers on board, and there are programs for remote collaboration so they don't have to be in the same physical location.
He goes into a bit of detail on source control management, automated processes, checkins and checkouts, having a stable trunk, and other nuts-and-bolts aspects of software project management.
Good Design = Moving Into the Big Leagues
Thiết kế tốt = Chuyển vào các hạng lớn
Mark là người to lớn về thiết kế:
“Nếu chúng ta thức sự muốn tạo ra một sự khác biệt trong thế giới này, trong thế giới của người tiêu dùng, thì chúng ta phải viết các phần mềm mà chúng có thể cạnh tranh được với những phần mềm được thiết kế tốt nhất ở đó...”
“Chúng ta phải chỉ ra cách để bắt đầu phát triển phần mềm với một tầm nhìn rất mạnh mẽ về thiết kế, về những mong đợi của người sử dụng”.
Ông nghĩ để đạt được điều này mà các lập trình viên có thể thu lợi từ việc làm việc với các nhà thiết kế chuyên nghiệp và các chuyên gia về tính có thể sử dụng được. Sự hợp tác này cần bắt đầu sớm, trước khi những khó khăn sẽ được viết mã cứng vào trong chương trình.
“Các giao diện lập trình người sử dụng API và các phần mềm trung gian tạo ra một sự khác biệt khổng lồ đối với những gì có thể trong kinh nghiệm của người sử dụng. Các anh em nói 'Nhìn xem, tôi làm việc trong nhân, tôi làm ra các trình điều khiển thiết bị, tôi không phải lo lắng về kinh nghiệm của người sử dụng'. Những các quyết định được thực hiện trong nhân có thể có một ảnh hưởng khổng lồ lên những gì có thể trong kinh nghiệm của người sử dụng”.
Vì thế ông nói chúng ta là tuyệt với trong việc làm phần mềm cho các chuyên gia, nhưng lại có vài cách để đi cho việc làm cho nó có thể sử dụng được và có thể truy cập được cho những người không phải là chuyên gia. Việc đang gây tai hại với nhiều kho phần mềm cho wi-fi là một ví dụ về những vấn đề và những kinh nghiệm tồi cho người sử dụng bắt đầu từ mức thấp nhất. (Cảm ơn John Linville và những người khác trong đội wi-fi mà chúng ta bây giờ có một kho phần mềm cho wi-fi mới sáng ngời và được tích hợp mà nó làm việc một cách đẹp đẽ được cho những người sử dụng và lập trình viên).
“Chúng ta phải nghĩ cẩn trọng về chất lượng. Mã nguồn có thể là chất lượng cao, nó có thể là cường tráng và chính xác và quản lý những ngoại lệ và lỗi thực sự là đẹp đẽ... nhưng có là chất lượng thực sự không nếu những gì bạn đã làm là làm cho nó hầu như không thể cho những người sử dụng đầu cuối để có được một kinh nghiệm tốt, nếu người sử dụng đầu cuối đó không ngồi ngay bên cạnh bạn?”.
Mark is big on design:
"If we really want to make a difference in this world, in the consumer world, we have to write software that can compete with the best-designed software out there....
"We have to figure out how to... deliver stuff that is usable, and consistent, and fits users' brains. We have to figure out how to start software development with a very strong view of design, of user expectations."
He thinks to achieve this that developers would benefit from working with professional designers and usability experts. This collaboration needs to start early, before difficulties are hard-coded into the program:
"APIs and middleware make a huge difference to what's possible in the user experience. Guys say "Look, I work in the kernel, I do device drivers, I don't have to worry about user experience." But decisions made in the kernel can have an enormous impact on what's possible in the user experience."
So he says we're great at making software for experts, but have some way to go for making it usable and accessible to non-experts. Being plagued with multiple wi-fi stacks is an example of problems and poor user experiences starting from the lowest level. (Thanks to John Linville and the rest of the wi-fi team we now have a shiny new integrated wi-fi stack that works beautifully for users and developers.)
"We have to think carefully about quality. The code may be high-quality, it may be rigorous and robust and handle exceptions and errors really beautifully...but is really quality if what you've done is made it almost impossible for the end user to have a good experience, if the end user wasn't sitting right next to you?"
Ông đã kết thúc với một lời mời bất kỳ ai mà muốn phần mềm của họ được xem xét bởi các nhà thiết kế chuyên nghiệp. Đó chỉ là những điểm mấu chốt, và tôi nghĩ nó là đáng giá tốt để nghe toàn bộ bài nói này một vài lần, vì đó là những khái niệm gốc cơ bản cho thế giới đàn mèo mà nó là Linux/FOSS.
Những bình luận đáng tiếc
Mội vài lỗi gần như làm hỏng bài nói chuyện này đối với tôi, và tôi sẽ không bao giờ có thể nghe từ “các phiên bản” một lần nữa mà không có cảm tưởng một chút buồn nôn. Sự buột miệng tự do của các diễn giả và những người nói chính: Bao gồm toàn bộ thính phòng khi bạn nói với họ, đặc biệt khi một trong những chủ đề bài nói chuyện của bạn là sự hợp tác, cộng đồng, à việc mở rộng nền tảng những người đóng góp và người sử dụng. Hãy tránh những câu chuyện cười ngu ngốc. Hãy gắn với chủ đề. Cảm ơn.
Đối với những ai tò mò, xin tham chiếu tới:
Mark Shuttleworth's Community Has No Women
Về tác giả bài viết: Carla Schroder là tác giả của Linux Cookbook và Linux Networking Cookbook (O'Reilly Media), sắp tới là “Việc xây dựng một Studio ghi số với Audacity” (NoStarch Press), một người yêu sách từ lâu, và là chủ biên của LinuxPlanet và Linux Today.
He closed with an invitation for anyone who wants their software reviewed by professional designers.
Those are just the key points, and I think it is well worth listening to the whole talk a couple of times, because these are radical concepts for the the herd-of-cats world that is Linux/FOSS.
Unfortunate Comments
Several gaffes nearly spoiled this talk for me, and I shall never be able to hear the word "releases" again without feeling a bit nauseated. Free tip to speakers and keynoters: Include your whole audience when you talk to them, especially when one of the themes of your talk is collaboration, community, and expanding the contributor and user base. Avoid stupid jokes. Stick to the subject. Thank you.
For those who are curious, please refer to:
Mark Shuttleworth's Community Has No Women
Carla Schroder is the author of the Linux Cookbook and the Linux Networking Cookbook (O'Reilly Media), the upcoming "Building a Digital Recording Studio with Audacity" (NoStarch Press), a lifelong book lover, and the managing editor of LinuxPlanet and Linux Today.
Dịch tài liệu: Lê Trung Nghĩa
Không có nhận xét nào:
Đăng nhận xét
Lưu ý: Chỉ thành viên của blog này mới được đăng nhận xét.