Title: Ways_of_Self_Organization_in_Decentralized_Develop
Category: Working_Groups

Author: ChainSafe
Date: 2018-10-29T11:43:51.947Z

Thank you everyone for today’s conversation, excited to see where this all goes.
Please add your notes and comments here

Author: cosmosys
Date: 2018-10-29T11:44:50.558Z

Hello, excited to see this group grow!

Author: tschubotz
Date: 2018-10-29T11:48:20.296Z

Hey all 
Here’s my doc of taking some notes of the Ring discussion in Prague: Way of self organization in decentralized development cycles - HackMD
Feel free to contribute and add things

Author: Ethernian
Date: 2018-10-29T12:05:26.900Z

Here are links to similar discussions / topics:


See here for problems and solutions while creating a list of people in decentralized:
Create List of Architects


Problem of local knowledge covered here


It is not 100% hit, but I mean good discussion point

Author: cleanunicorn
Date: 2018-10-29T12:15:01.764Z

Hey, happy to be a part of the discussion today. Waiting for the Manifesto Draft.
Could this be pushed to git? In my view it’s much simpler to collaborate and discuss before it’s finalized

Author: ChainSafe
Date: 2018-10-29T13:02:13.651Z

Great idea, a way of doing that could be by attempting to formalize this as a ring to be added to the scrolls.

Author: cosmosys
Date: 2018-10-29T15:03:35.698Z

I merged my notes into yours

Author: cosmosys
Date: 2018-10-29T15:05:02.712Z

Yup! after some traction think we can def add it to the scroll wiki

Author: Annavladi
Date: 2018-10-29T18:36:32.394Z

Great to meet everyone today.  Some problems defined that we are trying to solve
Hard to understand from the outsider where to go if you want to get involved…intimidating
How do we onboard new developers? Good first issue
Mass adoptions should be part of ethos
Education should be on everyone’s mind, what ever you do should be teachable to someone else

Author: Brett
Date: 2018-10-30T12:50:40.788Z

What is our ideal 10 out 10?

Author: cleanunicorn
Date: 2018-10-30T20:10:27.855Z

My 10/10
Defining a philosophy that enables decentralized development cycles. Important things for me as part of the definition:

allow people from multiple timezones collaborate efficiently
allow people with different commitments collaborate
create a framework that encourages knowledge sharing; this is important to increase the bus factor

allow people to gather knowledge that is auxiliary to the work they actually do

Author: ChainSafe
Date: 2018-11-03T16:14:51.452Z

Hey folks! I am trying to begin drafting a skeleton for the manifesto from the notes and I thought it would be pragmatic to start with principles similar to the manifesto for agile software development. Please let me know your thoughts and what to change/add to. Hopefully together we can get some of this preliminary work done and then we can start having bi-weekly (twice every month) calls to get things going. Thanks @noot for helping proof read this 
Principles of The Methods for Self Organized Development Cycles (SODC)

The highest priority is communication followed by process.
Sharing knowledge by never saying no, always empowering individuals to participate in discourse.
Self organization looks and feels different to different people, defining process and methodology for organizations is vital for decentralized development cycles.
SODC is about the people; user, developer, designer, etc… needs come first.
Inclusiveness as a mechanism for realizing individuals and collectives perspectives transparently.
DoAcracy as a method for creating self determined and self regulated development cycles. This allows for the individuals of an organization to take responsibility for their day to day tasks through a self determined process.
Milestones are a crucial aspect of SODC, allowing for team accomplishments to be celebrated. Whether the milestone was completed or not, the aim is to allow for an empirical study of the current SODC process being implemented.
A transparent and open process between all aspects of the development cycle is expected. Ensuring research, design, implementation, etc… are all working together and not against each other.
For SODC to be effective, it is important to collaborate with the wider open source ecosystem. Separate teams working on similar, dependent or complementary works should collaborate and share knowledge for the benefit of the larger community and in turn as members of the community help themselves optimize their development cycles.
In SODC teams operate by respect, not rank.
Teams must come to consensus on the definition of done, for clear outcomes to be understood by the entire team.

Author: sprusr
Date: 2018-11-04T20:56:04.250Z

Hey all, bit late to catch up with this thread but still super interested to see what we come up with! Some great stuff above already.
Points about communication and knowledge sharing remind me very much of some writing done around remote teams. I can’t find exactly the post I’m thinking of, but a quick search finds many including stuff about async communication, “when one person is remote, everyone is remote”, etc. I’ll try and find the one I have in mind and post here. Possibly existing ideas for remote teams could act as a good basis.

Author: gcolvin
Date: 2018-11-05T10:35:45.724Z

Reading through this quickly while I wait in Heathrow for my flight to Denver.  It’s fantastic.  A question I discussed with several people at Devcon was how to maintain coordinated development without the hierarchy of management used within corporations.  One insight that came up is that the best managers operate by respect rather than rank.

Author: ChainSafe
Date: 2018-11-06T13:54:47.236Z

Thank you for the feedback . I will add that point to the principles!

Author: ChainSafe
Date: 2018-11-08T16:06:54.157Z

I would really appreciate feedback from other people that attended the ring  (or anyone else! didn’t mean to exclude anyone)
Not sure if I am doing justice to the conversation we had.

Author: tschubotz
Date: 2018-11-09T15:40:28.743Z

Thanks for putting this together @ChainSafe!



 ChainSafe:


The highest priority is communication followed by process.



Since we have to account for quite some remote team, I like that communication is on top of the list. I think it cannot be underestimated.



 ChainSafe:


SODC is about the people; user and developer needs come first.



Who do we see as “developer” here? Really only the people coding? I would suggest to open this up a bit and also include e.g. (UX) designers and their needs, since their work is crucial for adoption and especially frontend dev teams usually have quite some dependencies to them. What do you think?



 ChainSafe:


Milestones are a crucial aspect of SODC, allowing for team accomplishments to be celebrated. Whether the milestone was completed or not, the aim is to allow for an empirical study of the current SODC process being implemented.



It’s super important to have them stored in one place and have everyone be aware of them. I have seen this too often in the past, that some people weren’t aware of the importance of some features and what it means for them to be done.

Author: ChainSafe
Date: 2018-11-09T16:36:56.409Z

Thanks for the feedback @tschubotz!



 tschubotz:

Who do we see as “developer” here? Really only the people coding? I would suggest to open this up a bit and also include e.g. (UX) designers and their needs, since their work is crucial for adoption and especially frontend dev teams usually have quite some dependencies to them. What do you think?


You are absolutely correct, this should include the whole team and not just developers. I will update this principle to reflect a more inclusive definition of people.



 tschubotz:

It’s super important to have them stored in one place and have everyone be aware of them. I have seen this too often in the past, that some people weren’t aware of the importance of some features and what it means for them to be done.


Totally! It is crucial to maintain a team definition of done, as this determines the outcome of a development cycle. I will add that to the list of principles.
Thanks again for the feedback, this is extremely helpful!

Author: gcolvin
Date: 2018-11-10T01:27:38.149Z

cleanunicorn:


allow people from multiple timezones collaborate efficiently



Many teams work almost entirely via proprietary, conversational channels like Gitter and Skype, with little to no support for threading, searching and archiving, and inadequate (if any) integration with email.  This makes working across time zones difficult for even small teams, and doesn’t scale to large teams. It hurts your other desiderata as well, as those not collaborating frequently, or simply seeking knowledge, will find themselves lost in a long thread of disjointed conversations.

Author: ChainSafe
Date: 2018-11-10T20:48:35.706Z

What have you seen work in these situations? Also, what would you say could be added to the principles to help people understand the importance of communicating through tools that work with an SODC? Thanks.

Author: timb
Date: 2018-11-11T12:43:47.559Z

One startup founder put it well: “Every decision someone has to make is the lack of a guiding principle”
Setting the right principles from the outset will help get a lot more done. The list above is a great start.



 tschubotz:

SODC is about the people; user and developer needs come first.


I think ‘contributer’ could include everyone relevant in this context.
For clarity, what do you think of prioritising  either users or contributors so when a decision that may affect both stakeholders comes along, the principle makes it an easy choice?

Author: jpitts
Date: 2018-11-11T18:29:58.483Z

Really excited and inspired to see this emerge. And I need this in so many projects I am involved in!
One thought I have is the use of the terms Self Organization and Decentralized. I see why it is important to call out the key principles/methods of this initiative w/ the acronym SODC. But as this initiative starts to form an enduring Ring, perhaps the name of the Ring should only reflect the most essential part of the problem domain that is being addressed. Perhaps then: “Development Cycles Ring”.
Using a short name for the Ring makes it a lot easier to refer to, and makes it more accessible to newfolk. The Self Organized Development Cycles acronym and other terminologies can be used in the writing once the reader understands the bigger picture.
As people get drawn in, they’ll begin to pick up on the principles and methods… and if they’re in Ethereum they’ll probably already have a lot of that baked-in!

Author: ChainSafe
Date: 2018-11-12T14:54:55.358Z

jpitts:

Perhaps then: “Development Cycles Ring”


Great name for the ring! It is very important not to scare people away with unnecessary jargon. Thanks for the feedback. I will change the name of the post to reflect the ring name once everyone agrees!

Author: gcolvin
Date: 2018-11-13T00:59:01.309Z

right-tool1195×814 146 KB

Author: cosmosys
Date: 2018-11-15T20:27:41.076Z

Great start and love the points on autonomy. I’ll take stab at shortening the manifesto.

Author: cosmosys
Date: 2018-11-15T20:32:47.031Z

Great idea.
Throwing out some more possibilities:

Decentralized Development Ring (DDR ha!)
Ethereum Agile Ring (EAR heh)
Autonomous Development Ceremonies
Decentralized Agile Ring

@ChainSafe - I’ll setup a weekly call and let anyone join. What’s the best way to get everyone’s email?
Cyrus

Author: cosmosys
Date: 2018-11-15T20:54:37.839Z

I’ve been thinking on how to leverage something like rocket chat



rocket.chat



Rocket.Chat | Secure CommsOS™ for Mission-Critical Operations
Centralize real-time messaging, voice, video, AI, and apps for secure, reliable and unified communication among internal and external stakeholders.

Author: ChainSafe
Date: 2018-11-15T21:05:47.973Z

Thanks for the feedback @cosmosys!



 cosmosys:

Throwing out some more possibilities:


Reading through this I have a question, what is the base type of workflow we are trying to address? Is a team being decentralized a necessity? Is agile, autonomous or distributed teams also a factor? I think @jpitts suggestion for calling the ring “Development Cycles Ring” does a great job of addressing the fundamental unifying characteristic between all decentralized, distributed, autonomous or agile teams which is the development cycle itself. SODC does not necessarily need to define this ring and I foresee many manifestos and educational materials being created for different types of teams.



 cosmosys:

I’ll setup a weekly call and let anyone join. What’s the best way to get everyone’s email?


A weekly call would be amazing! Instead of rocketchat could we use riot.im? It’s basically like gitter so conversations can be open to the public. Though I really like using the FEM discourse so people not fully active in the ring can still participate. We could also have a live streamed zoom call that we coordinate here or even create a github org so all our info can be public and forkable/maintainable by anyone.

Author: cosmosys
Date: 2018-11-15T22:30:55.756Z

Blockquote
Reading through this I have a question, what is the base type of workflow we are trying to address? Is a team being decentralized a necessity? Is agile, autonomous or distributed teams also a factor? I think @jpitts suggestion for calling the ring “Development Cycles Ring” does a great job of addressing the fundamental unifying characteristic between all decentralized, distributed, autonomous or agile teams which is the development cycle itself. SODC does not necessarily need to define this ring and I foresee many manifestos and educational materials being created for different types of teams.

Good question. In my opinion it is about synchronization and knowledge sharing of any type of Ethereum development wether it be agile, scrum, waterfall, distributed, etc.

Author: ChainSafe
Date: 2018-11-16T00:52:50.365Z

cosmosys:

Good question. In my opinion it is about synchronization and knowledge sharing of any type of Ethereum development wether it be agile, scrum, waterfall, distributed, etc.


Do you think a development cycle could represent the base primitive for synchronization and knowledge sharing?

Author: cosmosys
Date: 2018-11-16T01:15:52.257Z

BlockquoteDo you think a development cycle could represent the base primitive for synchronization and knowledge sharing?’

I think it is the other way around… What do other think?

Author: pet3rpan
Date: 2018-11-18T10:05:25.280Z

Lets have the call this upcoming wednesday / thursday / friday? Here are some timezones…
https://time.is/compare/0800_18_Nov_2018_in_Berlin/New_York/Denver/San_Francisco/Sydney
Can I suggest 21st November (wed):
8pm Berlin / 2pm New York / 12pm Denver / 11am SF / 6am Sydney

Author: ChainSafe
Date: 2018-11-18T17:21:11.675Z

That would be awesome 
Thursday and Friday work at the suggested time, but for Wednesday I am only available an hour earlier or after the suggsted time.

Author: pet3rpan
Date: 2018-11-18T21:08:02.767Z

Also just found this by @karalabe https://github.com/karalabe/eee/blob/master/README.md

Author: pet3rpan
Date: 2018-11-18T21:09:51.083Z

pet3rpan:

Lets have the call this upcoming wednesday / thursday / friday? Here are some timezones…
Time in Berlin, New York, Denver, San Francisco and Sydney - Time.is
Can I suggest 21st November (wed):
8pm Berlin / 2pm New York / 12pm Denver / 11am SF / 6am Sydney





 ChainSafe:

That would be awesome 
Thursday and Friday work at the suggested time, but for Wednesday I am only available an hour earlier or after the suggsted time.


What about @cosmosys @tschubotz @Ethernian @Annavladi @cleanunicorn @jpitts

Author: cleanunicorn
Date: 2018-11-19T09:54:19.548Z

How long will this be? 1 hour long?

Author: pet3rpan
Date: 2018-11-19T11:05:30.151Z

@cleanunicorn  Yes, one hour usually does the trick

Author: Annavladi
Date: 2018-11-19T20:30:15.340Z

I am on vacation starting Wednesday 21st and will not be back till 27th, Its a holiday week here in US, any way we can move this to next week please:)

Author: Annavladi
Date: 2018-11-19T20:45:14.599Z

very good points. however lets not get into American mentality of celebrating participation; we should celebrate achievement and success, so where you say milestones should be celebrated wheather milestone was accomplished or not; I think it needs to be re-worked. If you want progress, you have to have achievement, otherwise you are in a loop.

Author: pet3rpan
Date: 2018-11-20T00:59:36.205Z

Annavladi:

I am on vacation starting Wednesday 21st and will not be back till 27th, Its a holiday week here in US, any way we can move this to next week please:)


Have fun on your vacation  We will be having a call this week but I forsee further calls in taking place! Notes will be taken of course.
Here is the agenda with the dates of the meeting (22nd Nov. Thursday, 6pm Toronto/NYC, 3pm SF/LA, midnight Berlin/CEST)



HackMD



Magicians Hangout - HackMD

Author: ChainSafe
Date: 2018-11-20T02:37:57.704Z

ChainSafe:

Milestones are a crucial aspect of SODC, allowing for team accomplishments to be celebrated. Whether the milestone was completed or not, the aim is to allow for an empirical study of the current SODC process being implemented.


As stated above the milestones are these defined things that teams decide together through a process, the idea it to celebrate achieving a milestone. As Scrum teaches, the most important part of the process that allows for teams to self organize around milestones is to allow for an empirical study of the actual process. Whether or not  the milestone was accomplished, the whole point is not to achieve meaningless milestones and have a party. The point is to refine the process so we can learn and grow as empowered individuals.

Author: Ethernian
Date: 2018-11-21T17:19:06.153Z

ChainSafe:

Principles of The Methods for Self Organized Development Cycles (SODC)


I think we are all already know the existing approach of managed development cycles.
So I would focus on difference between SODC and the legacy one.
Where do you see the difference to existing management approaches?
What would you emphasize?

Author: ChainSafe
Date: 2018-11-22T16:09:04.646Z

Ethernian:

Where do you see the difference to existing management approaches?
What would you emphasize?


Personally, I see the main differences being that beyond our own development cycle to coordinate, we must coordinate with the larger open source community. Collaboration as a principle of SODC is crucial for an effective development cycle to be part of the larger community. What do you think @Ethernian?

Author: pet3rpan
Date: 2018-11-23T00:47:12.570Z

We just had our first call here between me and Aidan (ChainSafe)

Author: Ethernian
Date: 2018-11-24T00:19:47.878Z

ChainSafe:

… beyond our own development cycle to coordinate, we must coordinate with the larger open source community…
… What do you think @Ethernian?


thinking about it but… still unsure we have something really new here…
Why one SODC should coordinate with other SODCs in the larger open source community? What is the reason? I don’t say there is no any, but I would say, we need to point out the reason explicitly.
Is it because others are developing libraries one depends on? Or you mean there is reason of higher level for coordination? If parts should fit together and this is our goal, so may be we are missing some role like Product Manager (or Program Manager - for bigger cases)? Then we should try to adopt this classical role to our reality without reinventing the wheel.
From other side: there are bigger projects in opensource community releasing products based on work of many SODCs. For example, there are linux distributors, like Canonical with Ubuntu. Do we missing that part in our ecosystem?
I would prefer to find and adopt existing experience instead of reinventing the wheel.

Author: ChainSafe
Date: 2018-11-24T19:49:42.669Z

Ethernian:

Why one SODC should coordinate with other SODCs in the larger open source community? What is the reason? I don’t say there is no any, but I would say, we need to point out the reason explicitly.


I think community calls like the Plasma Implementers Call, show how neccessary it is for SODCs to coordinate with others SODCs. I agree that we should be more explicit about how we make that clear, any ideas?



 Ethernian:

Is it because others are developing libraries one depends on? Or you mean there is reason of higher level for coordination? If parts should fit together and this is our goal, so may be we are missing some role like Product Manager (or Program Manager - for bigger cases)? Then we should try to adopt this classical role to our reality without reinventing the wheel.


To answer all your questions, I would say that in blockchain it is much more than just depending on one another. It is about realizing that only together can we solve these problems. My big concern is that when we realize a lot of these projects we won’t continue this open collaboration. In regards to the specifics, I would say that specific roles like a PM are not necessary to specify as SODC to me is more akin to Agile Principles than a Scrum framework. This is not about reinventing the wheel, we have already done that by partaking in the web3.0 paradigm. This to me is about making observations based on what we do and are doing and trying to create principles around it.



 Ethernian:

Do we missing that part in our ecosystem?


It is the adhoc nature of these self organized calls like the Plasma Implementers Call that makes this process so unique. A lot of the time members of the Ethereum Foundation are involved, but it is individuals that have decided to self organize in these working groups.



 Ethernian:

I would prefer to find and adopt existing experience instead of reinventing the wheel.


Everything I have written has been inspired by the manifesto of agile software development, not sure what you mean by reinventing the wheel. This is just building on pre existing processes in a way that tries to capture the nature of development cycles in web3.0.
Thanks for the feedback!

Author: cosmosys
Date: 2018-11-30T20:09:46.652Z

I’ve been on planes over the past week - touched down in Toronto. Going to meet up with @ChainSafe tonight for anyone else that will be around.

Author: cosmosys
Date: 2018-11-30T20:10:19.156Z

BlockquoteWe just had our first call here between me and Aidan (ChainSafe)

Super fomo!!!

Author: chris-remus
Date: 2018-12-01T15:38:23.108Z

Please see my replies inline 



 ChainSafe:

Principles of The Methods for Self Organized Development Cycles (SODC)

The highest priority is communication followed by process.
Sharing knowledge by never saying no, always empowering individuals to participate in discourse.

By never saying no to what, a request for information? If that’s the intent, I agree. However, there should be a way these requests are channeled, to reduce administrative burden, repeated requests and interruptions in deep work flow. At the same time, I do believe saying no is critical to getting work done, as it relates to setting effective priorities.

Self organization looks and feels different to different people, defining process and methodology for organizations is vital for decentralized development cycles.

Yes. The agreed to processes and methodologies will also vary to some extent, as every team and project is different, comprised of unique individuals.

SODC is about the people; user, developer, designer, etc… needs come first.

The unique needs of each group need to be considered and addressed too. Striking this balance is tricky, yet possible.

Inclusiveness as a mechanism for realizing individuals and collectives perspectives transparently.

Creating a safe environment for differing and sometimes conflicting points of view needs to be created. Doing this allows for the effective manifestation of solutions exponentially more effective than the simple sum (and trade-offs) of individual opinions.

DoAcracy as a method for creating self determined and self regulated development cycles. This allows for the individuals of an organization to take responsibility for their day to day tasks through a self determined process.

There should be some overall and agreed-to organizing principles and priorities though.

Milestones are a crucial aspect of SODC, allowing for team accomplishments to be celebrated. Whether the milestone was completed or not, the aim is to allow for an empirical study of the current SODC process being implemented.
A transparent and open process between all aspects of the development cycle is expected. Ensuring research, design, implementation, etc… are all working together and not against each other.
For SODC to be effective, it is important to collaborate with the wider open source ecosystem. Separate teams working on similar, dependent or complementary works should collaborate and share knowledge for the benefit of the larger community and in turn as members of the community help themselves optimize their development cycles.

This is key in minimizing duplication of effort.

In SODC teams operate by respect, not rank.

Yes!

Teams must come to consensus on the definition of done, for clear outcomes to be understood by the entire team.

Yes! It sounds simple, yet is often overlooked. Projects can linger for a long time at what I call the last 10-15%. This is when the project is 85%-90% done, yet the last 10-15% takes as much effort as the first 85-90% to finish. It’s also a time where scope creep can prevent the last 10-15% from ever getting finished, i.e. “Maybe we can get this in, now that we’re almost done…”

Author: ChainSafe
Date: 2018-12-01T18:30:44.420Z

Thanks for the feedback, this is awesome!



 chris-remus:

By never saying no to what, a request for information? If that’s the intent, I agree. However, there should be a way these requests are channeled, to reduce administrative burden, repeated requests and interruptions in deep work flow. At the same time, I do believe saying no is critical to getting work done, as it relates to setting effective priorities.


Yes, a request of information was intended to be the example of something not to say no to. The way I have seen a natural way to “say no” is by having different spaces for people if they want to be left alone. We have a quiet room that has space for anyone looking to be left alone. For people without the space I have heard people use signs for a similar outcome. How do you think this principle could be updated more explicitly to get the message across?



 chris-remus:

Creating a safe environment for differing and sometimes conflicting points of view needs to be created. Doing this allows for the effective manifestation of solutions exponentially more effective than the simple sum (and trade-offs) of individual opinions.


I absolutely agree, how do we update the principle to reflect this?



 chris-remus:

There should be some overall and agreed-to organizing principles and priorities though.


That is what I see these principles as, a framework could be built on top of this to specify things in more detail.



 chris-remus:

This is key in minimizing duplication of effort.


Absolutely!



 chris-remus:

Yes! It sounds simple, yet is often overlooked. Projects can linger for a long time at what I call the last 10-15%. This is when the project is 85%-90% done, yet the last 10-15% takes as much effort as the first 85-90% to finish. It’s also a time where scope creep can prevent the last 10-15% from ever getting finished, i.e. “Maybe we can get this in, now that we’re almost done…”


Totally, this is scrum 101 and something people who preach scrum don’t highlight enough.

Author: JamesZaki
Date: 2018-12-08T11:45:46.914Z

To continue the detailed conversation, here are some comments/questions:
Objectives

provide resources to self-organising groups in the web3 domain
resources created from learnings from other open-source projects/products
highlight differences between web3 projects/products

(feel free to amend)
Some standard definitions
Product Manager - creates vision, roadmap, and backlog of high-level features/epics
Project Manager - facilitates flow of tickets through sprints
Some questions/clarifications

Products often conventionally from the point of view of end-user products being built by a hierarchical organisation, what considerations/differences need to be taken into account for open-source web3 products?
When the product is a protocol, the users of it are often developers (who are likely to be working on an open-source web3), how far do protocol developers go to anticipate end-user product-needs, and how these might feed into the protocol?

What do people think?

Author: ChainSafe
Date: 2018-12-11T11:13:53.791Z

Great feedback!



 JamesZaki:

what considerations/differences need to be taken into account for open-source web3 products?


I think a major difference is the process in which these products are built. Our only user facing product is a wallet app which we started at ETHDenver and have been building out ever since. We plan on integrating different layer 2 projects, meaning we have to be aware of the current research and development that is out there and potentially work with different teams to help us integrate these features. I believe this is a unique aspect of the web3 product domain, what are your thoughts?



 JamesZaki:

how far do protocol developers go to anticipate end-user product-needs, and how these might feed into the protocol?


I think as protocol developers and or people who build developer tools, we need to always think about how real people will end up using these things. If we do not allow for features that developers want to build for users to be a part of our tooling, I believe we are failing. This means working with developers to make sure we are building the right things.

Author: JamesZaki
Date: 2018-12-11T16:04:01.091Z

ChainSafe:

 JamesZaki:

what considerations/differences need to be taken into account for open-source web3 products?

… we have to be aware of the current research and development that is out there and potentially work with different teams to help us integrate these features. I believe this is a unique aspect of the web3 product domain, what are your thoughts?


Agreed, the movement of underlying dependencies is more rapid in web3 than regular open-source development. To add to the question, I’m also wondering if the decentralised ethos comes into play when developing products.
For those making a product for the sake of a token jammed into it, we’ll probably see the same centralised product decisions being made. But for those building for the decentralised future, I wonder how product decisions and vision differ. Would open-source DApp developers prefer making white-label products that can then be branded by anyone who wants to use it (whilst still giving credit where it’s due), or is that too idealistic an assumption to make?
Also how developers in this space take to familiar product visions vs more ideal decentralised products, and where this touches upon feasibility. Plenty to ponder

Author: ChainSafe
Date: 2018-12-12T14:12:22.100Z

JamesZaki:

or is that too idealistic an assumption to make?


That’s the nature of open source, I think this is an important aspect to the principles of an SODC.



 JamesZaki:

Plenty to ponder


Totally, we should talk about this in the next ethproduct call.

Author: ChainSafe
Date: 2018-12-14T19:11:21.714Z

Hey everyone, please find the first version of our principles live at sodc.io!
It lives as a github page that can be updated here. This should not remain on my personal account. It would be nice to transfer the repo over to the FEM org or to make a new one.
Let’s continue making them better and maybe start discussing what a few pillars might be throughout the principles.

Author: pet3rpan
Date: 2018-12-16T04:54:56.818Z

Its awesome! How do we go about testing, validating and improving this?