Notes on architecture as a cross cutting concern
Submitted by pwagstrom on Thu, 02/11/2010 - 19:16
A few of us met to discuss how architecture is an issue that addresses multiple different areas. You can find the etherpad at http://etherpad.com/foss2010-architecture.
Here's a copy of the notes:
How does cross-cultural development affect architecture?
US vs Japanese software development
Transfer
- can architect software for better comprehensibility which will lead to better transfer
- there is also transfer in: it's easier for people to come on board to contribute with some architectures
- lots of transfer may lead to lots of flow of information in and out
- choice of license is a "community architecture" issue also influences amount of transfer that happens
- Kate Stuart @ maryland has studied choice of license influences what people do
Learning
- the architecture decides whether or not the tool is suitable for student participation
- e.g., plugin is a good thing to work on for small/young student groups
- software may be chosen as a function of what you want to teach them
Community Structure
- the structure of the community
- pyramid of participation -- as people move along they can change to other systems
As people learn, they can flow to other components
If it's a monolithic community then they have a harder time understanding and have fewer places to move
- Need to reward people to increase their participation. We can give them modules to help them participate longer.
Also works well with corporations
People hate losing something they've been given
Open Source as an addiction?
Evolution
- some studies have been done on code base evolution
- Open Source struggles to evolve the codebase in radical ways. Possible that because they lack central control they can't evolve.
* Examples: Perl 6, Gallery 2
* Perl fans are addicts who are willing to do anything to justify their addiction
- does it work the same way in open source?
- when the code evolves, how does the organization evolve with it?
- do open source projects have to start simple, and then collect users, and then evolve once they have the user community
(hypothesis is that if we had a very complicated project show up, noone would be willing to learn it)
-What happens when a project starts as a proof of concept and gathers a community, and vice versa, what happens when a project starts as a deliberate architected piece of software and gathers as a community? Are these different? In other words what's the relationship between how the software evolves and how the community evolves?
In virtually all open source projects, the architecture is not a first class object. If you alter the architecture there is no where for people to understand the architecture.
one challenge is that in open source software there is noone who can assert the architecture of the software -or- the architecture of the organization -- at the beginning, or in the middle
Practice
there are books with recommended architectures for how open source software ought to be developed
- can these ideas be disseminated to other open fields
certain architectures are easier to organize a community around
following standards simplifies the decision space
- also make it easier to bring in more people who already have some familiarity
- makes it easier for the project to fork
monolithic projects may be more difficult to fork
- do projects become more monolithic over time?
- do users prefer interfaces with more cross-cutting features? If so, does this lead to more monolithic design?
- are there pattners that protect from this architectural problem?
abstraction can add complexity
- may make it harder for new people to join the project
Society
- do people in different cultures create different architectures in the community, which leads to different architectures in the software
natural language challenges in working together
- Would brazil/china produce software with a different architecture because their society is structured differently?
- in a distributed team does a person from one distant place have a tough time getting architectural ideas listened to?
- culture: do differences in culture affect working together
- e.g., do Japanese people try to avoid showing partially created software
- willingness to have public conflict
- preference for authoritarian society
Collaboration
Distributed FOSS teams: how does the way the FOSS project is distributed impact the architecture of the software and the community?
If the architecture of the project is tightly coupled with the social structure, then we can examine the architecture to better understand how communication is required across components.
tools: can take tools and help n00bs to map to work, e.g. by the architecture 'intelligent task grabbing' in wikipedia.
Groking tools to help others understand the architecture
Groups:
- pwagstrom's blog
- Login to post comments
