Skip to content
This repository has been archived by the owner on Dec 29, 2021. It is now read-only.

Vert.x: A case study of successful project reorganization #59

Open
aschrijver opened this issue Jul 19, 2017 · 1 comment
Open

Vert.x: A case study of successful project reorganization #59

aschrijver opened this issue Jul 19, 2017 · 1 comment

Comments

@aschrijver
Copy link

aschrijver commented Jul 19, 2017

Vert.x

(NOTE This showcase is part 4 of Positioning, vision and future direction of the Dat Project)

Vert.x is interesting for 2 reasons: one, it's a good case study for good project organization and community building, and two, their technology and/or ideas + concepts can be quite relevant to you.

(You might want to take a quick peek at vert.x landing page before reading on)

Some interesting bullet points (I won't digress too much, hopefully):

  • appealing web presence, narrow profile, everything branching out from landing page
  • well-guarded core, under Eclipse guidance, but without most of its strictures
  • toolkit with a comprehensive set of officially supported modules (meaning: compatibility, stability guarantees, follows release cycles, not customer/dev support)
  • clean, consistent, relevant set of repositories in vert-x3, no pollution
  • if you are officially supported you must be in vert-x3
  • community can be promoted to official modules based on popularity, use, stability and quality. The core team is the ultimate decider here
  • ~800 questions on SO. Modest, yes, but not requiring core team attention at all
  • very active google group and freenode channels for the dev team
  • and with all this vert.x didn't change its identity. It still felt like the project as it was before the Jykes! curve started mounting

Vert.x technology

Not only is vert.x an excellent example of a message-based application framework, it also puts the properties that come with such architecture design to good benefit. For example by adding polyglot programming support.

Now this should resonate with the scientific community! I would bet that given N programming scientists, you get N + 1 programming languages being used. Vert.x polyglot programming allows teams / projects to cooperate seemingly using their (jvm-based) language of choice. And this goes further than just having decoupled modules, or microservices written in different languages.

[Note: Regarding JVM I should probably write another post sometime, on a number of interesting cultural observations I made, as a newcomer to your community, like religious superstitions. Let me know if you're interested]

If Dat were to be polyglot in the future it would attract a broader range of scientists to both dev and user community - people that already have the proper mindset and moral + ethical values (in general).

Then there is the vert.x toolkit itself. Even though vert.x is running on the JVM it can be a useful technology for running/combining with Dat. I don't know the terminology, but I hear about various background services, storage, blind servers, repeaters/forwarders, elevated services, etc.

Concluding: "Be inclusive and open towards all technology"

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant