每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,歡迎關注開源日報。交流QQ群:202790710;電報群 https://t.me/OpeningSourceOrg


今日推薦開源項目:《可視化的面向對象語言——Luna

推薦理由:Luna 語言是一個尚待完善的面向對象語言,它最大的特點是嘗試用可視化的方式將程序的進程表現出來。在最常見的情況下,每個節點對應一行代碼。

例如下圖

 

開源項目精選:可視化的面向對象語言——Luna

 

它的對應Luna代碼是

a = 1
b = 2
c = a + b
c.succ

 

從這裡我們可以看出,節點實際上將一行代碼分為兩部分:等號左邊和等號右邊。等號左邊是要處理的變數名,右邊則是對於表達式。

最左邊的兩個節點對應於行a = 1和b = 2。變數名稱a,b成為其相應節點的名稱,數字1和2它們的定義。他們沒有輸入埠和每個輸出埠。

中間的節點對應於該行c = a + b。它具有a和b連接到它的輸入節點。由此,可以清楚地看到輸入數據來自哪裡。

最右邊的節點對應於該行c.succ。該節點沒有名稱,因為相應的行沒有定義任何變數。它有c連接到它的self埠的節點。這個埠表示方法調用的目標。

我們可以看到,鏈接各個節點的線條顏色是黃色,這代表的是數據的類型。黃色是整型,橙色是浮點型( Luna 中被稱為real),紫色是字元串型,列表(數組)是藍色,含有多種數據類型的列表是綠色。每個節點的左端代表輸入,右端代表輸出。

數據類型:

就 Luna 目前的數據類型及處理來看,想要成為一門合格的面向對象的可視化語言還亟待完善。

Luna 目前支持三種基本數據類型:整型,真值(即浮點型),字元串,但三者直接的轉換如1+1.5這種表達式尚不能被實現,因此在用於數據處理方面的話還較為麻煩。

關於自定義數據類型:

與 python 類似, Luna 可以靠類生成一個新對象,以此達到使用自定義數據類型的目的。

對象在 Luna 里具有不可變性。也就是說在其他語言里,你可能會使用counter.count += 1去改變對象。而在 Luna 里,如果你寫foo = Circle 15.0, 無論如何使用它,foo將永遠是Circle 15.0,除非你重定義foo。

構造類與方法:

以下是構造類和方法的文本說明:

class Shape:
Circle:
radius :: Real
Rectangle:
width  :: Real
height :: Real

def perimeter: case self of
Circle r: 2.0 * pi * r
Rectangle w h: 2.0 * w + 2.0 * h

def area: case self of
Circle r: pi * r * r
Rectangle w h: w * h

 

總結:

主要優勢:

作為一款新型的可視化編程語言, Luna 更關注於數據的處理,這可以使任何需要使用計算機輔助進行數據處理的人都能快速的使用 Luna 進行編程。

主要缺陷:

目前的 Luna 在類和對象方面還有所欠缺。目前,沒有辦法使用可視化編輯器定義類和方法。

個人感覺 Luna 為了圖形化程序流程在代碼的靈活性上作出了很大的妥協,以至於cos=sin=5這樣的連等表達式都無法一行寫出,這對筆者這種喜愛語法糖的人來說還是比較不友好的QAQ,不過 Luna 本身側重的就是那些有數據處理需求而又不太對編程或者說語法感冒的設計者,有興趣的同學還是可以去 GitHub 上學習一下的。

此外:Luna的基礎語法以及操作都在官方文檔里有詳細的解釋

https://luna-lang.gitbooks.io/docs/content/visual_representation.html


今日推薦英文原文:《Who really owns an open project?》作者:

推薦理由:很多人不太了解開源社區是如何運作的,比如說,一個開源項目真正意義上屬於誰?一個典型例子是: Linus 是 Linux kernel 的作者,然後將其開源,然後更多的人加入進來這個項目貢獻代碼,還有做非代碼工作的志願者,還有捐贈者,那麼誰可以「擁有」這個開源項目呢?這個項目到底屬於誰呢?

老實說,這個問題挺複雜的,在探討這個問題之前,我們還得定義:什麼叫「擁有一個項目」,是知識產權?還是可以決定它的發展,還是創造了這個項目,還是可以毀滅這個項目,才叫「擁有」呢?

Who really owns an open project?

chain image
Image by : Internet Archive Book Images. Modified by Opensource.com. CC BY-SA 4.0

Differences in organizational design don't necessarily make some organizations better than others—just better suited to different purposes. Any style of organization must account for its models of ownership (the way tasks get delegated, assumed, executed) and responsibility (the way accountability for those tasks gets distributed and enforced). Conventional organizations and open organizations treat these issues differently, however, and those difference can be jarring for anyone hopping transitioning from one organizational model to another. But transitions are ripe for stumbling over—oops, I mean, learning from.

Let's do that.

Ownership explained

In most organizations (and according to typical project management standards), work on projects proceeds in five phases:

  • Initiation: Assess project feasibility, identify deliverables and stakeholders, assess benefits
  • Planning (Design): Craft project requirements, scope, and schedule; develop communication and quality plans
  • Executing: Manage task execution, implement plans, maintain stakeholder relationships
  • Monitoring/Controlling: Manage project performance, risk, and quality of deliverables
  • Closing: Sign-off on completion requirements, release resources

The list above is not exhaustive, but I'd like to add one phase that is often overlooked: the "Adoption" phase, frequently needed for strategic projects where a change to the culture or organization is required for "closing" or completion.

  • Adoption: Socializing the work of the project; providing communication, training, or integration into processes and standard workflows.

Examining project phases is one way contrast the expression of ownership and responsibility in organizations.

Two models, contrasted

In my experience, "ownership" in a traditional software organization works like this.

A manager or senior technical associate initiates a project with senior stakeholders and, with the authority to champion and guide the project, they bestow the project on an associate at some point during the planning and execution stages. Frequently, but not always, the groundwork or fundamental design of the work has already been defined and approved—sometimes even partially solved. Employees are expected to see the project through execution and monitoring to completion.

Employees cut their teeth on a "starter project," where they prove their abilities to a management chain (for example, I recall several such starter projects that were already defined by a manager and architect, and I was assigned to help implement them). Employees doing a good job on a project for which they're responsible get rewarded with additional opportunities, like a coveted assignment, a new project, or increased responsibility.

An associate acting as "owner" of work is responsible and accountable for that work (if someone, somewhere, doesn't do their job, then the responsible employee either does the necessary work herself or alerts a manager to the problem.) A sense of ownership begins to feel stable over time: Employees generally work on the same projects, and in the same areas for an extended period. For some employees, it means the development of deep expertise. That's because the social network has tighter integration between people and the work they do, so moving around and changing roles and projects is rather difficult.

This process works differently in an open organization.

Associates continually define the parameters of responsibility and ownership in an open organization—typically in light of their interests and passions. Associates have more agency to perform all the stages of the project themselves, rather than have pre-defined projects assigned to them. This places additional emphasis on leadership skills in an open organization, because the process is less about one group of people making decisions for others, and more about how an associate manages responsibilities and ownership (whether or not they roughly follow the project phases while being inclusive, adaptable, and community-focused, for example).

Being responsible for all project phases can make ownership feel more risky for associates in an open organization. Proposing a new project, designing it, and leading its implementation takes initiative and courage—especially when none of this is pre-defined by leadership. It's important to get continuous buy-in, which comes with questions, criticisms, and resistance not only from leaders but also from peers. By default, in open organizations this makes associates leaders; they do much the same work that higher-level leaders do in conventional organizations. And incidentally, this is why Jim Whitehurst, in The Open Organization, cautions us about the full power of "transparency" and the trickiness of getting people's real opinions and thoughts whether we like them or not. The risk is not as high in a traditional organization, because in those organizations leaders manage some of it by shielding associates from heady discussions that arise.

The reward in an Open Organization is more opportunity—offers of new roles, promotions, raises, etc., much like in a conventional organization. Yet in the case of open organizations, associates have developed reputations of excellence based on their own initiatives, rather than on pre-sanctioned opportunities from leadership.

Thinking about adoption

Any discussion of ownership and responsibility involves addressing the issue of buy-in, because owning a project means we are accountable to our sponsors and users—our stakeholders. We need our stakeholders to buy-into our idea and direction, or we need users to adopt an innovation we've created with our stakeholders. Achieving buy-in for ideas and work is important in each type of organization, and it's difficult in both traditional and open systems—but for different reasons.

Open organizations better allow highly motivated associates, who are ambitious and skilled, to drive their careers. But support for their ideas is required across the organization, rather than from leadership alone.

Penetrating a traditional organization's closely knit social ties can be difficult, and it takes time. In such "command-and-control" environments, one would think that employees are simply "forced" to do whatever leaders want them to do. In some cases that's true (e.g., a travel reimbursement system). However, with more innovative programs, this may not be the case; the adoption of a program, tool, or process can be difficult to achieve by fiat, just like in an open organization. And yet these organizations tend to reduce redundancies of work and effort, because "ownership" here involves leaders exerting responsibility over clearly defined "domains" (and because those domains don't change frequently, knowing "who's who"—who's in charge, who to contact with a request or inquiry or idea—can be easier).

Open organizations better allow highly motivated associates, who are ambitious and skilled, to drive their careers. But support for their ideas is required across the organization, rather than from leadership alone. Points of contact and sources of immediate support can be less obvious, and this means achieving ownership of a project or acquiring new responsibility takes more time. And even then someone's idea may never get adopted. A project's owner can change—and the idea of "ownership" itself is more flexible. Ideas that don't get adopted can even be abandoned, leaving a great idea unimplemented or incomplete. Because any associate can "own" an idea in an open organization, these organizations tend to exhibit more redundancy. (Some people immediately think this means "wasted effort," but I think it can augment the implementation and adoption of innovative solutions. By comparing these organizations, we can also see why Jim Whitehurst calls this kind of culture "chaotic" in The Open Organization).

Two models of ownership

In my experience, I've seen very clear differences between conventional and open organizations when it comes to the issues of ownership and responsibility.

In an traditional organization:

  • I couldn't "own" things as easily
  • I felt frustrated, wanting to take initiative and always needing permission
  • I could more easily see who was responsible because stakeholder responsibility was more clearly sanctioned and defined
  • I could more easily "find" people, because the organizational network was more fixed and stable
  • I more clearly saw what needed to happen (because leadership was more involved in telling me).

Over time, I've learned the following about ownership and responsibility in an open organization:

  • People can feel good about what they are doing because the structure rewards behavior that's more self-driven
  • Responsibility is less clear, especially in situations where there's no leader
  • In cases where open organizations have "shared responsibility," there is the possibility that no one in the group identified with being responsible; often there is lack of role clarity ("who should own this?")
  • More people participate
  • Someone's leadership skills must be stronger because everyone is "on their own"; you are the leader.

Making it work

On the subject of ownership, each type of organization can learn from the other. The important thing to remember here: Don't make changes to one open or conventional value without considering all the values in both organizations.

Sound confusing? Maybe these tips will help.

If you're a more conventional organization trying to act more openly:

  • Allow associates to take ownership out of passion or interest that align with the strategic goals of the organization. This enactment of meritocracy can help them build a reputation for excellence and execution.
  • But don't be afraid sprinkle in a bit of "high-level perspective" in the spirit of transparency; that is, an associate should clearly communicate plans to their leadership, so the initiative doesn't create irrelevant or unneeded projects.
  • Involving an entire community (as when, for example, the associate gathers feedback from multiple stakeholders and user groups) aids buy-in and creates beneficial feedback from the diversity of perspectives, and this helps direct the work.
  • Exploring the work with the community doesn't mean having to come to consensus with thousands of people. Use the Open Decision Framework to set limits and be transparent about what those limits are so that feedback and participation is organized ad boundaries are understood.

If you're already an open organization, then you should remember:

  • Although associates initiate projects from "the bottom up," leadership needs to be involved to provide guidance, input to the vision, and circulate centralized knowledge about ownership and responsibility creating a synchronicity of engagement that is transparent to the community.
  • Ownership creates responsibility, and the definition and degree of these should be something both associates and leaders agree upon, increasing the transparency of expectations and accountability during the project. Don't make this a matter of oversight or babysitting, but rather a collaboration where both parties give and take—associates initiate, leaders guide; associates own, leaders support.

Leadership education and mentorship, as it pertains to a particular organization, needs to be available to proactive associates, especially since there is often a huge difference between supporting individual contributors and guiding and coordinating a multiplicity of contributions.


每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,歡迎關注開源日報。交流QQ群:202790710;電報群 https://t.me/OpeningSourceOrg