1. S1
1.1. informações gerais
1.1.1. motivation
1.1.1.1. Despite the recent popularity of hackathons, there are few systematically reported experiences about hackathons
1.1.1.2. in three months at Facebook [1]. In software engineering, the closest equivalent to a hackathon seems to be software prototyping.
1.1.1.3. the companies are facing the fact that the amount of functionality that needs to be developed to satisfy customer needs is far more than what represents a reasonable investment [17], [18].
1.1.1.4. Satisfying these customer needs especially in fast-paced and unpredictable mass-consumer markets calls for external development.
1.1.2. method
1.1.2.1. We describe the experiences of organizing a hackathon within F-Secure by a means of a case study
1.1.2.2. This research followed the case study approach [11], focusing on two different aspects: assessing the 3rd party API and learning about a hackathon as a practice for F-Secure. Thus, we applied a research approach that was qualitative and explorative in nature in order to capture the thorough understanding of a multifaceted phenomenon.
1.1.2.3. As a central part of the preparations, we carried out a lightweight pre-study on how to organize a hackathon successfully. However,
1.1.3. data collection techniques
1.1.3.1. Interviews
1.1.3.2. Observations
1.1.3.3. Documentation
1.1.3.4. Questionnaires
1.1.4. results
1.1.4.1. The results indicate that the hackathon was a realistic, efficient, and effective means of holistically testing the ecosystem including technical details but especially the overall design and developer experience. The hackathon resulted in identifying bottlenecks, and it provided future directions for the development of the ecosystem. The
1.2. hackathon
1.2.1. definition
1.2.1.1. A hackathon refers to a hacking marathon; a hackathon is an event where people in small groups participate in an intensive prototyping activity for a limited amount of time.
1.2.2. properties
1.2.2.1. length
1.2.2.1.1. The length of a hackathon varies typically from a day to a few days.
1.2.2.2. objectives
1.2.2.2.1. often, an objective is to develop new, innovative software applications or services
1.2.2.3. similar to
1.2.2.3.1. Jam
1.2.3. study case
1.3. jam
1.4. software systems
1.4.1. developed by using different approaches
1.4.1.1. component-based systems [13]
1.4.1.2. software platforms [14]
1.4.1.3. software product lines [15], [16]
1.5. software ecossystem
1.5.1. Inorder to tackle these, a more open model is needed beyond organizational borders. Recently, the software ecosystem has emerged as a development strategy.
1.5.2. kinds
1.5.2.1. keystone-centric [22]
1.5.2.1.1. when a company opens up a successful product line to third-party development [12].
1.5.3. elements
1.5.3.1. platform boundary resources.
1.5.3.1.1. SDK
1.5.3.1.2. application programmer interface (API);
1.5.3.2. actors / stakeholders
1.5.3.2.1. either companies or individuals,
1.5.3.2.2. different actors have different motivations, different business models, and a symbiotic relationship between each other and the ecosystem itself [20].
1.5.3.3. software platform
1.5.3.3.1. emerges the
1.5.3.4. relashionships between stakeholders
1.5.4. activities
1.5.4.1. demo session
1.5.4.2. briefing about the facilities
1.5.4.3. opening word
1.5.5. facilities
1.5.5.1. support people present
2. S3
2.1. informações gerais
2.1.1. method
2.1.1.1. descriptive case study [15].
2.1.1.1.1. We conducted an industrial case study on third-party developer experience, particularly on the role of platform boundary resources in exposing the platform architecture and facilitating development
2.1.1.1.2. The unit of analysis was the software ecosystem and as a subunit of analysis, the platform boundary resources
2.1.1.2. study case
2.1.1.2.1. hackathon organized by the F-Secure.
2.1.1.2.2. three-day hackathon to assess the ease of third-party application development for CAN Ecosystem, to see how the requirements for third-party applications are fulfilled, and the enablers and obstacles to third-party development.
2.1.1.2.3. The data analysis was carried out following the conventions of grounded theory analysis [27], [24] using Atlas.ti in order to accumulate empirical evidence around concepts.
2.1.2. questões de pesquisa
2.1.2.1. RQ1
2.1.2.1.1. What different kinds of platform boundary resources exist in software ecosystems?
2.1.2.2. RQ2
2.1.2.2.1. How does the platform architecture influence the platform boundary resources?
2.1.2.3. RQ3
2.1.2.3.1. How do platform boundary resources support or hinder the development of third-party applications?
2.1.3. objetivo
2.1.3.1. This paper presents a descriptive case study [15] on the role of platform boundary resources in exposing and extending the platform architecture and enabling third-party application development.
2.1.4. contribuições
2.1.4.1. Our case study addresses the lack of research on real-world ecosystems [10].
2.1.4.2. To extend the model of classifying the platform boundary resources into technical and social [14], we propose an onion model of three levels of platform boundary resources that facilitate third-party development.
2.1.4.3. Further, we describe the relations between platform boundary resources, platform architecture, and third-party development
2.2. software ecosystems
2.2.1. “a set of businesses functioning as a unit and interacting with a shared market for software and services, together with the relationships among them” [16] where “relationships are frequently underpinned by a common technological platform or market and operate through the exchange of information, resources and artifacts” [16]
2.2.2. Technically characteristics [17]
2.2.2.1. have a central organization that links to others by interface relations, thus having control not over others specific choices but “over the premises of choice”
2.2.2.2. have a self-regulatory behaviour: for example, a product line controlled in a centralized way turns into a collaborative approach where the central organization adapts to the surrounding environment and vice versa [17].
2.2.2.3. are networked: the network consists of all participants, potentially even of competitors, and thus can be understood as an innovation network [8]
2.2.2.4. depend on information and communication technologies: not only on the software platform, but also on the tools that enable collaboration among different participants
2.2.3. can be organized in different ways
2.2.3.1. keystone-centric software ecosystem,
2.2.3.2. consortium-based software ecosystem,
2.2.3.3. with no referent organization.
2.2.4. architecture
2.2.4.1. participants
2.2.4.1.1. share value
2.2.4.2. platform
2.2.4.2.1. Within software ecosystems, the platform is the key technological resource [10], [21].
2.2.4.2.2. The platform may be
2.2.4.2.3. properties
2.2.4.2.4. boundary resources
2.2.4.2.5. architecture
2.2.4.3. third part
2.2.4.3.1. third-party applications are an essential part of the software ecosystem, which means that the architecture must consider structures beyond the imminent boundary of the platform itself.
2.2.5. other elements
2.2.5.1. actors
2.2.5.1.1. the actors are not considered being a part of the ecosystem architecture, but actors are entities that interact with the ecosystem architecture.
2.2.5.1.2. keystone player
2.2.5.1.3. Third party developers
2.2.5.1.4. End-users
2.3. hackathon
2.3.1. refers to a highly engaging continuous event, where people in small groups participate in an intensive activity producing tangible results in a limited amount of time