Erik Gfesser, Kiến trúc sư trưởng cho Thực hành Dữ liệu của SPR – Loạt Phỏng vấn

Erik đã gia nhập nhóm Thực hành Dữ liệu của SPR với tư cách Kiến trúc sư trưởng vào năm 2018.

Erik đã trở thành chuyên gia về dữ liệu, phát triển nguồn mở sử dụng Java và kiến trúc doanh nghiệp thực tế, bao gồm việc xây dựng các bản chứng minh khái niệm, nguyên mẫu và sản phẩm tối thiểu có thể.

Điều gì đã thu hút bạn đến học máy?

Khả năng của các ứng dụng học hỏi liên tục. Tôi đã bắt đầu sự nghiệp phát triển của mình với tư cách là một nhà phân tích dữ liệu cao cấp sử dụng SPSS tại một công ty nghiên cứu thị trường toàn cầu, và sau đó đã kết hợp sử dụng một công cụ engine quy tắc kinh doanh gọi là Drools vào các ứng dụng mà tôi xây dựng cho khách hàng, nhưng đầu ra của tất cả công việc này基本 là tĩnh.

Sau đó, tôi đã làm việc thông qua quá trình cải thiện quy trình, trong thời gian đó các giảng viên đã chứng minh chi tiết cách họ có thể cải thiện, thông qua thống kê và các phương pháp khác, các quy trình kinh doanh được sử dụng bởi khách hàng của họ, nhưng ở đây lại đầu ra chủ yếu tập trung vào các điểm trong thời gian. Kinh nghiệm của tôi khi làm việc để cải thiện một sản phẩm chăm sóc sức khỏe mà các đồng nghiệp và tôi đã xây dựng trong cùng thời kỳ này là điều đã cho tôi thấy tại sao việc học hỏi liên tục là cần thiết cho những nỗ lực như vậy, nhưng các nguồn lực hiện có không tồn tại vào thời điểm đó.

Đáng chú ý, sự thu hút của tôi đến học máy đã trở thành một vòng tròn khép kín, vì cố vấn sau đại học của tôi đã cảnh báo tôi về việc chuyên môn hóa trong lĩnh vực mà sau đó được gọi là trí tuệ nhân tạo, do mùa đông AI vào thời điểm đó. Tôi chọn sử dụng các thuật ngữ như ML vì những thuật ngữ này mang ít liên quan, và vì ngay cả AWS cũng thừa nhận rằng lớp dịch vụ AI của họ thực sự chỉ là một lớp trừu tượng cao hơn được xây dựng trên lớp dịch vụ ML của họ. Mặc dù một số lời đồn về ML ở đó là không thực tế, nhưng nó cung cấp các khả năng mạnh mẽ từ góc độ của các nhà phát triển, miễn là các nhà thực hành này thừa nhận rằng giá trị mà ML cung cấp chỉ tốt như dữ liệu được xử lý bởi nó.

Bạn là một người ủng hộ mã nguồn mở lớn, bạn có thể thảo luận về lý do tại sao mã nguồn mở lại quan trọng?

Một khía cạnh về mã nguồn mở mà tôi đã cần phải giải thích cho các giám đốc điều hành trong những năm qua là lợi ích chính của mã nguồn mở không phải là sử dụng phần mềm này không có chi phí tiền tệ, mà là mã nguồn được cung cấp miễn phí.

Ngoài ra, các nhà phát triển sử dụng mã nguồn này có thể sửa đổi nó cho riêng họ, và nếu các thay đổi được đề xuất được chấp thuận, họ có thể làm cho những thay đổi này có sẵn cho các nhà phát triển khác sử dụng nó. Trên thực tế, phong trào đằng sau phần mềm mã nguồn mở bắt đầu do các nhà phát triển chờ đợi trong thời gian dài để các công ty thương mại thực hiện các thay đổi đối với các sản phẩm họ cấp phép, vì vậy các nhà phát triển đã tự viết phần mềm có cùng chức năng, mở nó lên để được cải thiện bởi các nhà phát triển khác.

Phần mềm mã nguồn mở được thương mại hóa tận dụng được những lợi ích này, thực tế là nhiều sản phẩm hiện đại sử dụng mã nguồn mở dưới bề mặt, ngay cả khi các biến thể thương mại của phần mềm này thường cung cấp các thành phần bổ sung không có sẵn như một phần của bản phát hành mã nguồn mở, cung cấp các yếu tố khác biệt cũng như hỗ trợ nếu điều này là cần thiết.

Trải nghiệm đầu tiên của tôi với mã nguồn mở diễn ra khi xây dựng sản phẩm chăm sóc sức khỏe mà tôi đã đề cập trước đó, sử dụng các công cụ như Apache Ant, được sử dụng để xây dựng phần mềm, và một sản phẩm DevOps sớm gọi là Hudson (cơ sở mã của nó sau đó trở thành Jenkins). Lý do chính đằng sau quyết định của chúng tôi để sử dụng các sản phẩm mã nguồn mở này là chúng cung cấp các giải pháp tốt hơn so với các giải pháp thương mại, hoặc là các giải pháp sáng tạo không được cung cấp bởi các thực thể thương mại, không kể đến việc cấp phép thương mại của một số sản phẩm chúng tôi đã sử dụng là quá hạn chế, dẫn đến quá nhiều giấy tờ khi cần thêm giấy phép, do chi phí liên quan.

Theo thời gian, tôi đã thấy các sản phẩm mã nguồn mở tiếp tục phát triển, cung cấp sự đổi mới cần thiết. Ví dụ, nhiều vấn đề mà các đồng nghiệp và tôi đã vật lộn khi xây dựng sản phẩm chăm sóc sức khỏe này sau đó đã được giải quyết bởi một sản phẩm Java mã nguồn mở sáng tạo mà chúng tôi bắt đầu sử dụng gọi là Spring Framework, vẫn đang phát triển mạnh sau hơn một thập kỷ, hệ sinh thái của nó hiện đã mở rộng vượt ra ngoài một số đổi mới ban đầu mà nó cung cấp, bây giờ được coi là phổ biến, chẳng hạn như tiêm依赖.

Bạn đã sử dụng mã nguồn mở để xây dựng các bản chứng minh khái niệm, nguyên mẫu và sản phẩm tối thiểu có thể. Bạn có thể chia sẻ hành trình của mình đằng sau một số sản phẩm này?

Como đã giải thích trong một trong những nguyên tắc hướng dẫn mà tôi đã trình bày cho một khách hàng gần đây, việc xây dựng các nền tảng dữ liệu mà chúng tôi đã xây dựng cho họ nên được thực hiện một cách lặp lại theo thời gian. Các thành phần được xây dựng cho nền tảng này không nên được mong đợi là tĩnh, vì nhu cầu thay đổi và các thành phần mới và tính năng của các thành phần sẽ được cung cấp theo thời gian.

Khi xây dựng chức năng của nền tảng, hãy bắt đầu với những gì có thể hoạt động được trước khi thêm các tính năng không cần thiết, điều này trong một số trường hợp thậm chí bao gồm cả cấu hình. Bắt đầu với những gì hoạt động, hãy đảm bảo bạn hiểu nó, và sau đó phát triển nó. Đừng lãng phí thời gian và tiền bạc xây dựng những thứ có khả năng thấp được sử dụng, nhưng hãy cố gắng đi trước nhu cầu trong tương lai.

Sản phẩm tối thiểu có thể mà chúng tôi đã xây dựng cho sản phẩm này rõ ràng cần được xây dựng để các trường hợp sử dụng bổ sung có thể tiếp tục được xây dựng trên nó, ngay cả khi nó đi kèm với việc thực hiện một trường hợp sử dụng duy nhất, để phát hiện bất thường chi phí. Không giống như khách hàng này, một sản phẩm trước đó mà tôi đã xây dựng đã có một số lịch sử trước khi tôi đến. Trong trường hợp này, các bên liên quan đã tranh luận trong ba năm (!) về cách họ nên tiếp cận sản phẩm họ đang xây dựng. Một giám đốc điều hành của khách hàng đã giải thích rằng một trong những lý do anh ấy đưa tôi vào là để giúp công ty vượt qua một số cuộc tranh luận nội bộ này, đặc biệt là vì sản phẩm mà anh ấy đang xây dựng cần phải đáp ứng nhu cầu của các tổ chức liên quan.

Tôi đã phát hiện ra rằng những cuộc chiến tranh lãnh địa này chủ yếu liên quan đến dữ liệu thuộc sở hữu của khách hàng, các công ty con và khách hàng bên ngoài của họ, vì vậy trong trường hợp này, toàn bộ danh sách sản phẩm quay quanh cách dữ liệu này sẽ được tiêu thụ, lưu trữ, bảo mật và tiêu thụ cho một trường hợp sử dụng duy nhất để tạo ra các mạng lưới cung cấp dịch vụ chăm sóc sức khỏe cho phân tích chi phí.

Sớm trong sự nghiệp của tôi, tôi đã đến để hiểu rằng một chất lượng kiến trúc gọi là “sự sử dụng” không chỉ bị giới hạn ở người dùng cuối, mà còn là các nhà phát triển phần mềm. Lý do tại sao điều này là trường hợp là vì mã được viết cần phải được sử dụng giống như giao diện người dùng cần phải được sử dụng bởi người dùng cuối. Để một sản phẩm trở nên có thể sử dụng được, các bản chứng minh khái niệm cần phải được xây dựng để chứng minh rằng các nhà phát triển sẽ có thể làm những gì họ đặt ra để làm, đặc biệt là khi liên quan đến các lựa chọn công nghệ cụ thể mà họ đang thực hiện. Nhưng các bản chứng minh khái niệm chỉ là bước đầu tiên, vì các sản phẩm tốt nhất khi được phát triển theo thời gian. Theo quan điểm của tôi, nền tảng cho một sản phẩm tối thiểu có thể lý tưởng nên được xây dựng trên các nguyên mẫu thể hiện một số sự ổn định để các nhà phát triển sẽ có thể tiếp tục phát triển nó.

Khi xem xét cuốn sách “Học máy ở Quy mô Doanh nghiệp” bạn đã tuyên bố rằng “sử dụng các sản phẩm, khuôn khổ và ngôn ngữ mã nguồn mở cùng với một kiến trúc linh hoạt bao gồm cả các thành phần mã nguồn mở và thương mại cung cấp sự nhanh nhẹn mà nhiều công ty cần nhưng không ngay lập tức nhận ra từ đầu”. Bạn có thể đi vào một số chi tiết về lý do tại sao bạn tin rằng các công ty sử dụng mã nguồn mở là linh hoạt hơn?

Nhiều sản phẩm dữ liệu thương mại sử dụng các thành phần mã nguồn mở quan trọng dưới bề mặt, và cho phép các nhà phát triển sử dụng các ngôn ngữ lập trình phổ biến như Python. Các công ty xây dựng các sản phẩm này biết rằng các thành phần mã nguồn mở mà họ đã chọn để kết hợp cung cấp cho họ một bước chạy khi những thành phần này đã được sử dụng rộng rãi bởi cộng đồng.

Các thành phần mã nguồn mở có cộng đồng mạnh mẽ hơn dễ bán hơn, do sự quen thuộc mà chúng mang lại. Các sản phẩm thương mại có sẵn chủ yếu bao gồm mã nguồn đóng, hoặc thậm chí mã nguồn mở được sử dụng chủ yếu bởi các sản phẩm thương mại cụ thể, thường yêu cầu đào tạo bởi các nhà cung cấp, hoặc giấy phép để sử dụng phần mềm.

Ngoài ra, tài liệu cho các thành phần như vậy chủ yếu không được cung cấp công khai, buộc các nhà phát triển tiếp tục phụ thuộc vào các công ty này. Khi các thành phần mã nguồn mở được chấp nhận rộng rãi như Apache Spark là trung tâm, như với các sản phẩm như Databricks Unified Analytics Platform, nhiều mục này đã được cung cấp trong cộng đồng, giảm thiểu các phần mà các nhóm phát triển cần phụ thuộc vào các thực thể thương mại để thực hiện công việc của họ.

Ngoài ra, vì các thành phần như Apache Spark được chấp nhận rộng rãi như các công cụ tiêu chuẩn của ngành, mã cũng có thể dễ dàng di chuyển giữa các triển khai thương mại của các sản phẩm như vậy. Các công ty sẽ luôn có xu hướng kết hợp những gì họ coi là các yếu tố khác biệt, nhưng nhiều nhà phát triển không muốn sử dụng các sản phẩm hoàn toàn mới vì điều này chứng minh là thách thức khi di chuyển giữa các công ty và có xu hướng cắt đứt mối quan hệ với các cộng đồng mạnh mẽ mà họ đã quen với.

Từ kinh nghiệm cá nhân, tôi đã làm việc với các sản phẩm như vậy trong quá khứ, và nó có thể là một thách thức để có được sự hỗ trợ có năng lực. Và điều này là iron, vì các công ty này bán sản phẩm của họ với kỳ vọng của khách hàng rằng hỗ trợ sẽ được cung cấp một cách kịp thời. Tôi đã có kinh nghiệm gửi một yêu cầu kéo đến một dự án mã nguồn mở, với bản sửa lỗi được kết hợp vào bản xây dựng cùng ngày, nhưng không thể nói điều tương tự về bất kỳ dự án thương mại nào mà tôi đã làm việc.

Điều gì khác mà bạn tin về mã nguồn mở là dẫn đến “truy cập vào các cộng đồng nhà phát triển mạnh mẽ”. Làm thế nào lớn là một số cộng đồng này và điều gì làm cho chúng hiệu quả?

Các cộng đồng nhà phát triển xung quanh một sản phẩm mã nguồn mở nhất định có thể đạt đến hàng trăm nghìn. Tỷ lệ áp dụng không nhất thiết chỉ ra sức mạnh của cộng đồng, nhưng là một chỉ số tốt rằng điều này là trường hợp do xu hướng tạo ra các vòng tròn nhân ái. Tôi coi các cộng đồng là mạnh mẽ khi chúng tạo ra các cuộc thảo luận lành mạnh và tài liệu hiệu quả, và nơi phát triển tích cực đang diễn ra.

Khi một kiến trúc sư hoặc nhà phát triển cao cấp làm việc thông qua quá trình chọn những sản phẩm như vậy để kết hợp vào những gì họ đang xây dựng, nhiều yếu tố thường tham gia, không chỉ về sản phẩm bản thân và những gì cộng đồng trông như thế nào, mà còn về các nhóm phát triển sẽ áp dụng những sản phẩm này, liệu chúng có phù hợp với hệ sinh thái đang được phát triển, những gì con đường trông như thế nào, và trong một số trường hợp, liệu hỗ trợ thương mại có thể được tìm thấy nếu điều này có thể được cần.

Bạn đã xem xét hàng trăm cuốn sách trên trang web của mình, có ba cuốn mà bạn có thể giới thiệu cho độc giả của chúng tôi?

Ngày nay, tôi đọc rất ít sách lập trình, và trong khi có những ngoại lệ, thực tế là những cuốn sách này thường bị lỗi thời rất nhanh, và cộng đồng nhà phát triển thường cung cấp các lựa chọn thay thế tốt hơn thông qua các diễn đàn thảo luận và tài liệu. Nhiều cuốn sách tôi đọc hiện nay được cung cấp miễn phí cho tôi, hoặc bởi các bản tin công nghệ mà tôi đăng ký, hoặc bởi các tác giả và người quảng bá liên hệ với tôi, hoặc bởi những cuốn sách mà Amazon (AMZN ) gửi cho tôi.

(1) Một cuốn sách từ O’Reilly mà tôi đã giới thiệu là “Tìm kiếm Cứu cánh Cơ sở dữ liệu”. Tác giả đã đề cập chi tiết đến các thách thức mà một công cụ truy vấn cơ sở dữ liệu phải hỗ trợ các khối lượng công việc bao gồm từ OLTP ở một đầu đến phân tích ở đầu kia, với các khối lượng công việc thông minh kinh doanh và hoạt động ở giữa. Cuốn sách này có thể được sử dụng như một hướng dẫn để đánh giá một công cụ cơ sở dữ liệu hoặc kết hợp giữa công cụ truy vấn và lưu trữ, nhằm đáp ứng nhu cầu khối lượng công việc của bạn, cho dù đó là giao dịch, phân tích hay kết hợp cả hai.

(2) Mặc dù nhiều điều đã thay đổi trong không gian dữ liệu trong những năm qua, vì các sản phẩm phân tích dữ liệu mới tiếp tục được giới thiệu, “Phân tích Disruptive” trình bày một lịch sử ngắn gọn và dễ tiếp cận về 50 năm đổi mới trong phân tích mà tôi chưa từng thấy ở nơi khác, và thảo luận về hai loại gián đoạn: đổi mới gián đoạn trong chuỗi giá trị phân tích và gián đoạn ngành bởi các đổi mới trong phân tích. Từ quan điểm của các công ty khởi nghiệp và các nhà thực hành phân tích, thành công được cho phép bằng cách gián đoạn các ngành công nghiệp của họ, vì sử dụng phân tích để phân biệt một sản phẩm là một cách để tạo ra một mô hình kinh doanh gián đoạn hoặc tạo ra các thị trường mới.

(3) Một trong những văn bản kinh doanh công nghệ hay nhất mà tôi đã đọc là “Giới hạn của Chiến lược”, của một trong những người sáng lập Research Board (được mua lại bởi Gartner), một tổ chức nghiên cứu quốc tế điều tra các phát triển trong thế giới máy tính và cách các công ty nên thích nghi. Tác giả trình bày các ghi chú chi tiết từ nhiều cuộc trò chuyện của mình với các nhà lãnh đạo kinh doanh, cung cấp phân tích sâu sắc trên toàn bộ về kinh nghiệm của mình khi xây dựng (với vợ của mình) một nhóm khách hàng, các công ty lớn cần phải kết hợp chiến lược của họ với thế giới máy tính bùng nổ.

Bạn là Kiến trúc sư trưởng cho Thực hành Dữ liệu của SPR. Bạn có thể mô tả những gì SPR làm?

SPR là một công ty tư vấn công nghệ kỹ thuật số có trụ sở tại khu vực Chicago, cung cấp các dự án công nghệ cho một loạt khách hàng, từ các doanh nghiệp Fortune 1000 đến các công ty khởi nghiệp địa phương. Chúng tôi xây dựng các trải nghiệm kỹ thuật số từ đầu đến cuối bằng cách sử dụng một loạt các khả năng công nghệ, mọi thứ từ phát triển phần mềm tùy chỉnh, trải nghiệm người dùng, dữ liệu và cơ sở hạ tầng đám mây, đến huấn luyện DevOps, kiểm tra phần mềm và quản lý dự án.

Điều gì là một số trách nhiệm của bạn với SPR?

Como Kiến trúc sư trưởng, trách nhiệm chính của tôi là thúc đẩy việc phân phối giải pháp cho khách hàng, dẫn đầu kiến trúc và phát triển cho các dự án, và điều này thường có nghĩa là mặc nhiều mũ khác nhau như chủ sở hữu sản phẩm vì khả năng liên quan đến cách sản phẩm được xây dựng từ quan điểm thực hành nặng nề trong việc ưu tiên công việc, đặc biệt là khi xây dựng từ đầu. Tôi cũng được kéo vào các cuộc thảo luận với các khách hàng tiềm năng khi chuyên môn của tôi là cần thiết, và công ty gần đây đã yêu cầu tôi bắt đầu một loạt các phiên họp liên tục với các kiến trúc sư khác trong Thực hành Dữ liệu để thảo luận về các dự án của khách hàng, dự án phụ và những gì đồng nghiệp của tôi đang làm để theo kịp công nghệ, tương tự như những gì tôi đã chạy cho một công ty tư vấn trước, mặc dù các cuộc họp nội bộ như vậy cho công ty khác liên quan đến toàn bộ Thực hành Công nghệ, không cụ thể cho công việc Dữ liệu.

Trong phần lớn sự nghiệp của tôi, tôi đã chuyên về phát triển mã nguồn mở sử dụng Java, thực hiện một lượng công việc dữ liệu ngày càng tăng trên đường đi. Ngoài hai chuyên môn này, tôi cũng làm những gì đồng nghiệp và tôi đã đến để gọi là “thực tế” hoặc “thực dụng” kiến trúc doanh nghiệp, điều này có nghĩa là thực hiện các nhiệm vụ kiến trúc trong bối cảnh những gì sẽ được xây dựng, và thực sự xây dựng nó, chứ không chỉ nói về nó hoặc vẽ sơ đồ về nó, nhận ra rằng những nhiệm vụ khác cũng quan trọng.

Theo quan điểm của tôi, ba chuyên môn này chồng chéo với nhau và không loại trừ lẫn nhau. Tôi đã giải thích cho các giám đốc điều hành trong những năm qua rằng dòng mà ngành công nghệ đã truyền thống vẽ giữa phát triển phần mềm và công việc dữ liệu không còn được xác định rõ, một phần vì công cụ giữa hai không gian này đã hội tụ, và một phần vì, do sự hội tụ này, công việc dữ liệu bản thân đã trở thành một nỗ lực phát triển phần mềm. Tuy nhiên, vì các nhà thực hành dữ liệu truyền thống thường không có nền tảng phát triển phần mềm, và ngược lại, tôi giúp đáp ứng khoảng cách này.

Điều gì là một dự án thú vị mà bạn đang làm việc với SPR?

Just gần đây, tôi đã xuất bản bài đăng đầu tiên trong một loạt các nghiên cứu trường hợp về nền tảng dữ liệu mà nhóm của tôi và tôi đã triển khai trên AWS từ đầu này năm cho CIO của một công ty tư vấn toàn cầu có trụ sở tại Chicago. Nền tảng này bao gồm các đường ống dữ liệu, hồ dữ liệu, mô hình dữ liệu chuẩn, hình ảnh và mô hình học máy, sẽ được sử dụng bởi các bộ phận công ty, thực hành và khách hàng cuối của khách hàng. Mặc dù nền tảng cốt lõi sẽ được xây dựng bởi tổ chức CNTT của CIO, mục tiêu là nền tảng này sẽ được sử dụng bởi các tổ chức khác ngoài CNTT để tập trung các tài sản dữ liệu và phân tích dữ liệu trên toàn công ty bằng cách sử dụng một kiến trúc chung, xây dựng trên nó để đáp ứng nhu cầu trường hợp sử dụng của từng tổ chức.

Como với nhiều công ty thành lập, sử dụng Microsoft Excel là phổ biến, với bảng tính thường được phân phối trong và giữa các tổ chức, cũng như giữa công ty và khách hàng bên ngoài. Ngoài ra, các đơn vị kinh doanh và thực hành tư vấn đã trở nên cô lập, mỗi đơn vị sử dụng các quy trình và công cụ khác nhau. Vì vậy, ngoài việc tập trung các tài sản dữ liệu và phân tích dữ liệu, một mục tiêu khác là thực hiện khái niệm về quyền sở hữu dữ liệu, và cho phép chia sẻ dữ liệu giữa các tổ chức một cách an toàn và nhất quán.

Có điều gì khác mà bạn muốn chia sẻ về mã nguồn mở, SPR hoặc một dự án khác mà bạn đang làm việc?

Một dự án khác (đọc về nó tại đây và tại đây) mà tôi gần đây đã lãnh đạo liên quan đến việc triển khai thành công Databricks Unified Analytics Platform, và di chuyển việc thực hiện các mô hình học máy đến nó từ Azure HDInsight, một phân phối Hadoop, cho giám đốc kỹ sư dữ liệu của một công ty bảo hiểm lớn.

Tất cả các mô hình đã di chuyển này đều được dự định để dự đoán mức độ áp dụng của người tiêu dùng mà có thể được dự kiến cho các sản phẩm bảo hiểm khác nhau, với một số đã được di chuyển từ SAS vài năm trước khi công ty chuyển sang sử dụng HDInsight. Thử thách lớn nhất là chất lượng dữ liệu kém, nhưng các thử thách khác bao gồm thiếu phiên bản toàn diện, kiến thức bộ lạc và tài liệu không đầy đủ, và tài liệu và hỗ trợ Databricks chưa trưởng thành về việc sử dụng R tại thời điểm đó (triển khai Azure của Databricks vừa được cung cấp rộng rãi vài tháng trước khi dự án này).

Để giải quyết những thách thức chính này, như một phần tiếp theo của công việc triển khai của chúng tôi, tôi đã đưa ra các khuyến nghị về tự động hóa, cấu hình và phiên bản, tách biệt các vấn đề dữ liệu, tài liệu và sự cần thiết cho sự sắp xếp trên toàn bộ các nhóm dữ liệu, nền tảng và mô hình của họ. Công việc của chúng tôi đã thuyết phục một nhà khoa học dữ liệu trưởng ban đầu rất hoài nghi rằng Databricks là cách để đi, với mục tiêu được nêu sau khi chúng tôi rời đi là di chuyển các mô hình còn lại của họ đến Databricks càng sớm càng tốt.

Đây đã là một cuộc phỏng vấn thú vị chạm vào nhiều chủ đề, tôi cảm thấy như tôi đã học được rất nhiều về mã nguồn mở. Những người đọc có thể muốn tìm hiểu thêm có thể truy cập trang web công ty SPR hoặc trang web của Erik Gfesser.