search

magicstone-dev / magicstone.dev

Website, community issue tracker, wiki and forum
https://magicstone.dev
Creative Commons Zero v1.0 Universal
3 stars 2 forks source link

Problem: There is no development protocol as commonplace as Git #9

Open weex opened 3 years ago

weex commented 3 years ago

"Issue 1" so to speak is that no development protocol is as commonplace, ubiquitous and accepted as using Git. This is a problem because a defined development protocol may increase speed and quality of distributed software development. Any project that has not chosen a development protocol is therefore leaving a lot to chance and is therefore more likely to underperform any existing protocol that it might choose. When this problem is solved, developers who are setting up new projects might add choice of development protocol to the short list of decisions (technology, purpose, license) that they must make.

Under the C4 protocol, what's next for this particular issue is to debate and confirm its accuracy and value. For example on the dimension of accuracy, one could argue whether any particular development protocol could be best for all projects. On the value dimension, it remains to be proven whether the problem of development protocol is a valuable one to address.

ledcoyote commented 3 years ago

I think that git does fit the bill for C4 (indeed, it is specified by the protocol) if used in a perfectly controlled and limited way in the project repo (personal forks being managed however their authors see fit). There could be value in taking a step outside the letter of C4 to consider abstracting the development protocol from the tool. Exploring alternative VCS tooling and mapping it to C4 would increase the value of C4-tools. Combined, this would result in C4-tools having its business logic in an abstracted dev protocol, while adapters could be written for git and other VCS tooling.

Abstracting C4 itself would be valuable to clear thinking and could open up other avenues where the protocol could create value. VCS tooling adapters would add value and be extensions on C4, in a sense. The work required would be non-trivial, and should be taken in a stepwise fashion, starting with an abstract protocol definition.

weex commented 3 years ago

I think that git does fit the bill for C4 (indeed, it is specified by the protocol) if used in a perfectly controlled and limited way in the project repo (personal forks being managed however their authors see fit).

By mentioning Git, I didn't mean to say that it's something to be replaced but that it has a deserved and core position in software development.

C4 inhabits a different space, that of the development a process or project protocol. Many projects adopt an adhoc process that begins when the first PR is submitted. Depending on the time available and size of the team, that PR may sit, or get reviewed then merged, or get picked apart.

My point with this problem is to call out that nothing has achieved default status through intention, testing and experimentation and I suggest C4 to be that thing or maybe a descendant or something completely different.

It sure would help developers to know that a common working process was in wide adoption, similar to how learning git or bash has wide utility.

ledcoyote commented 3 years ago

That makes sense. I had misunderstood the problem as stated. For free software projects C4 is a very good standard. It's not clear what obstacles have prevented it's widespread adoption. Lack of awareness? Not-invented-here bias?

weex commented 3 years ago

It would be interesting to find some evidence but I think lack of awareness and general resistance to change. The easiest way to affect change in tech is the startup, go off on your own where a small group can buy in 100% and demonstrate the new way.