dataesr/scientific-paragraphs-categorization huggingface dataset:
Acknowledgements. We thank  B. Mason  ( USNO ) for providing the individual position measurements of the companion of π 1 Gru from the WDS catalogue and the variable star observations from the AAVSO International Database contributed by observers worldwide and used in this research. We also thank  I. Platais  for advice with the proper motion evaluation. This work was supported in part by the  Belgian Federal Science Policy Office  via the  PRODEX Programme of ESA. AM and FK acknowledge funding by the  Austrian Research Promotion Agency FFG  under project number  FA 538019 ,  RO  under project number  I163-N16. Furthermore, AM acknowledge funding by the  Abschlussstipendium 2014 of the University of Vienna. This work used data from the  ESO archive  ( Programmes 076. D-0624 ,  077. D-0620 ,  078.
INTRODUCTION Numerous software development methods have been proposed to guide organizations in their software development: from the traditional waterfall approach and the V-model to the more recent and highly popular agile methods. While these methods all aim at providing a systematic way to develop software, the emergence of successful open source projects has been remarkable, given the seeming absence of a predefined processwhat  Erdogmus [2009]  provokingly called an antiprocess. Open-source communities have produced a number of high-quality and highly successful products, including the so-called LAMP stack (consisting of Linux, Apache, MySQL, and PHP/Perl/Python), while defying traditional wisdom in software development  [McConnell 1999 ]. Furthermore, while distributed development has proven extremely problematic and challenging for organizations  [Herbsleb and Grinter 1999] , open-source software development represents a successful exemplar of distributed development.
g, a software 'forge'  [Riehle et al. 2009] ). This model maximizes sharing of software packages within an organization, but reuse is rather ad-hoc and support is heavily dependent on the maintainer of a software package. Most organizations listed in Table I have adopted this model. The infrastructure used for this may vary, but a number of organizations have adopted clones of the SourceForge. net platform (e. g. , SAP  [Riehle et al. 2009] ). The second Inner Source model is what  Gurbani et al. [2010]  termed the projectspecific model. In this model there is typically an organizational unit (a core team) that takes responsibility for a certain Inner Source project (a shared asset). This responsibility includes the further development of the shared asset and providing support to users of the software throughout the organization.
We analyzed the data using qualitative techniques as described by  Seaman [1999]. All interview transcripts were thoroughly read, and phrases of interest were coded with the framework elements as seed categories. Throughout the process, short memos were written and exchanged among the authors which were then further discussed as necessary. In addition to the interviews, we drew from a number of other data sources at the three companies. For the case at Philips, we studied existing reports on its Inner Source initiative, and also had two informal discussions (one hour each) with the initiator of Philips' Inner Source initiative. These discussions gave additional insight into the history of the company's Inner Source program. At Neopost, we studied information available on the internal wiki as well as project documentation.
Deliberation about features, details, and idealized systems is typically not much appreciated. This is not to say that open-source developers do not discuss requirements at all, but that a sound balance must be found. On the one hand, conversations (e. g. , on mailing lists or IRC) may lead to discussions (disputes, even) on the most minute and trivial details, a phenomenon known as "bikeshedding"  [Fogel 2005, p. 98 ]. On the other hand, some community members may have the most fantastic plans and idea, but it is actual running code that is valued most. Linus Torvalds, 'benevolent dictator' of the Linux kernel project, expressed this sentiment famously as "Talk is cheap. Show me the code. " [Torvalds 2000 ]. Thus, a common scenario is that developers identify features, provide a "patch" that implements the new functionality after which it is offered to the community for peer review.
Standardization of Tools for Facilitating Collaboration. A key success factor for an Inner Source project is that there is a set of common and compliant development tools so as to make contributing easy  [Dinkelacker et al. 2002; Gurbani et al. 2006; Riehle et al. 2009]. Differences in the tools that are used across an organization (not uncommon in large organizations) can be an obstacle for developers to contribute, or may necessitate duplication of the code repository, causing additional synchronization efforts. For that reason, a set of common tools must be available throughout the organization. Tools commonly used by OSS projects are (besides compilers) version control systems (e. g. , Subversion), issue tracking software (e. g. , Trac), mailing lists, and wikis  [Robbins 2005 ]. While a number of these tools are also commonly used in commercial software development, different business units within large organizations often use a wide range of different tools  [Robbins 2005; Gurbani et al.
2006; Riehle et al. 2009 ]. Riehle et al. [2009]  reported that "The biggest hurdle to widespread adoption of SAP Forge is its limited compliance with tools mandatory for SAP's general software development process. " Several authors reported that moving code among different version control systems is challenging  [Dinkelacker et al. 2002; Gurbani et al. 2006 ]. For instance,  Gurbani et al. [2006]  reported their experiences of certain teams replicating the original shared asset's source code into their preferred repository, causing significant merging problems later on. Therefore, an organization considering adopting Inner Source should pay sufficient attention to addressing this issue. Often, barriers to achieve this are not of a technical nature, but rather organizational or sometimes political.
Software Product 5. 1. 1. Seed Product to Attract a Community. The seed product at Philips was initially a set of components, or component suite, with common functionality related to the DICOM (Digital Imaging and Communications in Medicine) standard. This is a standard for exchanging medical images and workflow information, and as such, is used by most product groups within Philips. For that reason, this set of components was a good starting point, or seed, for Philips' Inner Source initiative. Over time, this component suite evolved into a platform for a software product line, which is still evolving and extended today. In both Neopost and Rolls-Royce, we identified several potential seed products. At Neopost, a promising component is a Hardware Abstraction Layer (HAL). The HAL is a component that controls the actual hardware of inserter machines.
Common operations are abstracted away, which decouples a machine's user-interface application from its hardware. The HAL is written in C++ and has a well-defined interface consisting of a set of virtual functions (supporting polymorphism). This allows for easy and modular extensions by others, and it is likely the HAL will need many extensions in the future, as software support for new hardware components must be added. Given that the HAL will be used in most future machines developed at Neopost, it is of significant value to the organization. At Rolls-Royce, we identified a number of candidate seed products, some of which are still in a prototyping phase. Participants generally agreed across groups that a prototype would help to gather more requirements, which they felt supported the need for an initial seed product.
What you would do is configure the platform and within that configuration you'd choose A, B, C or D. It's more an integrated approach. " (P2) At Neopost, we found that the HAL is a very modular component, whereby the various hardware drivers are stored in separate files, which facilitates parallel development. This was in stark contrast to another component that we identified, whose main purpose is to read and decode instructions from a sheet of paper (as it is processed in a machine). This component was closely coupled with a system application (containing the graphical user interface) that uses it. One developer explained this as follows: "And instead of considering [it] as a component, it's just a copy of the [system] application [. ] So, saying that you developed a 'component' is arguable, because they really delivered a whole application with a small part that we also use.
Practices and Tools 5. 2. 1. Practices to Support Bazaar-Style Development. Philips, offering advanced systems for the medical domain, is operating in a regulated environment and as such its development process is subject to audits by regulators, such as the U. S. FDA. Philips have extensive processes for how requirements move from product groups to the core team. Formal channels for communicating requirements include issue trackers and databases with "all sorts of procedures," but there are also a number of informal channels. These include mailing lists on which developers can provide support to people in other product groups. Though an open-source way of working suggests a central repository through which developers can improve the code and make changes as they see fit, this is not the case in Philips.
[2010]  termed a feature advocate. Developers at Neopost follow the Scrum method to manage software projects, using three-week sprints. It is important to note that while software has an increasingly important role in Neopost's products and is becoming larger and more complex over time, the role of software is to control a machine's hardware. This means that product development is driven by development of the hardware, and the software development process must keep up. We found that Neopost does not have a formal requirements elicitation process in place, but there are a number of sources that the development team relies on. First, the most important source of requirements is the marketing department, which represents the "customer" role in the Scrum method. Other stakeholders throughout the organization also provide requirements, such as service, manufacturing and hardware engineers.
" (N7) The maintainer of HAL described this as follows: "If they want to change something in HAL, then they make a 'diff ' and send it to me for review. And if I think it's no problem, then I check it in. " The approach to software testing in Neopost varies per project; some projects have automatic unit test frameworks, whereas others have a more manual approach. The nature of testing is difficult due to the fact that much of the software is embedded. At machine level, a test department subjects the machines to extensive tests. After each development sprint, the development team gives a demonstration of the current version of the machine under development to Marketing, who provide immediate feedback. This three-week sprint cycle ensures that the software is always in a runnable state whereas the demonstrations and feedback help in delivering increasingly better versions of the product.
The core team has an "Operations" subdivision that provides operational support for the development environment that is rolled out throughout the organization. This ensures that all product groups have the same development environment, which prevents the various problems associated with different toolsets. At Neopost, too, all developers at the visited location use the same integrated development environment. Some teams use additional tools, for instance, one team uses ReviewBoard 8  which facilitates the coordination of a peer-review process. Most development is done in C++ targeting embedded platforms and controllers. This focus on a common technology reduces the need for a wide variety of development environments and tools (e. g. , compilers, debuggers). In our case study at Rolls-Royce, we found that there is a wide variety of software, written in COBOL, FORTRAN, C, C++, Java and Python.
Furthermore, there is a plethora of development environments and platforms, including variants of Unix, Linux, and Microsoft Windows, as one participant explained, "We're developing for Unix, and multiple flavors of PC, which makes things very complicated. " Given this large variety in technologies and platforms, the company also needs to maintain the development environments and tools. An important consideration here is that the organization cannot afford the loss of design capability, which is why there must be a tight control of the IT infrastructure. On the other hand, targeting development at multiple platforms helps to increase the software's robustness, as some compilers are more 'pedantic' than others in terms of compiler errors. Software development machines at Rolls-Royce are managed by a central IT department that has responsibility for a wide range of machines throughout the organization.
Neopost follows the Scrum methodology as previously mentioned, which provides the overall framework for daily coordination, and therefore provides much flexibility. Scrum meetings take place in the morning. At departmental level, all Scrum Masters gather with the department manager on a weekly basis for a Scrum-of-Scrums meeting. Software teams are co-located, which allows for quick, ad-hoc face-to-face meetings. Software engineers tend to specialize in certain parts of the whole system, thus enabling them to continue working in parallel on the same system. This specialization makes them the "contact person" for their particular subsystem. This suggests that such a person has taken on the role of a "trusted lieutenant" (in bazaar-terminology), which differentiates the process from the agile method (Scrum) that is followed.
Agile methods emphasize the concept of Collective Ownership, whereby the development team as a whole is responsible for the code, and any developer may make changes  [Schwaber and Beedle 2002; Cohn 2009]. Another important factor at Neopost is that machine development is hardware-driven, in that the software supports the hardware. As a result, it is very important that software and hardware engineers coordinate any changes amongst themselves as any changes in the hardware may have impact on the software. Some projects organize weekly face-to-face meetings to achieve this coordination. Interviewees at Rolls-Royce felt that they had a relatively high level of freedom in how they coordinated their work, thus facilitating a greater level of self-organization. One participant explained it this way.
"There's nothing really in place that coordinates our work beyond the informal chats about what we need. What's driving task selection for me is talking to customers and seeing, what common geometry do I need to build. There's no gaffer [boss] coming along to say 'you got to do this. ' " (R2) Furthermore, within teams developers work on different parts of the software, thereby developing a certain level of speciality (which, similar to Neopost, facilitates the emergence of "trusted lieutenants"). It is generally known within teams "who's doing what. " One participant highlighted the importance of a common vision and direction for a project where different people are "trying to pull it in different directions. " This suggests there is room for a benevolent dictator who coordinates and integrates contributions by others.
Since we've changed from a central team that delivers a binary platform to the new Inner Source model in which everybody could see the source code and also contribute, we saw the community growing. People started to inform each other about dos and don'ts about the design. And people found out much quicker whether others were using the platform correctly. That community became much more lively when we adopted the Inner Source model. " (P3) Neopost's internal LAN provides open access to all project artifacts to all employees. Source code is managed by a version control system, and other infrastructure includes an issue tracker and a wiki installation that is used for sharing knowledge and documentation. Thus, most of the infrastructure to facilitate an online community is present. One potential issue is that of online communication.
It's not to help others with that new functionality, it's primarily for us. But, once it's finished, then you'd also discuss this beforehand with the core team that the component can go back into the platform. " (P8) Support at Neopost was mostly at the middle management level. Interest in Inner Source at Neopost is mostly grounded in the organization's goal to increase software reuse. A number of years ago, a small development group was set up to (a) develop a common reference architecture, and (b) develop common, reusable components within that architecture to be used by all future projects. In effect, this group resembled a core team that would manage a set of shared assets. However, due to the need for achieving a quick time-to-market, at some point developers were needed in other projects, greatly reducing the team's capacity to continue its goal.
Discussion We can make a number of observations based on the findings presented in the previous section. Our discussion is organized using the three categories of the framework: Software Product, Practices and Tools, and Organization and Community. 6. 1. 1. Software Product. The first category relates to the software that is to be managed as an Inner Source project. In terms of identifying a 'seed' product, this was fairly straightforward in the two case organizations that have not fully adopted Inner Source (Neopost, Rolls-Royce). Interviewees immediately suggested potential products (or components) that could be further developed in an Inner Source project. The need for a shared asset to be reusable by a variety of users also seemed intuitive. In both Neopost and Rolls-Royce, participants indicated how "this could work" for a specific software component.
However, from our case studies it becomes clear that this may mean different things to different organizations. For instance, the Philips case illustrates how open-source practices have been tailored to fit the specific corporate context (i. e. , co-development projects). As briefly suggested in Section 6. 1. 1, the nature of the Inner Source product (in terms of scale and business value) may affect what practices can be adopted. At Neopost, software development is very much driven by hardware development and needs to keep up due to the strong interdependency of software and hardware. At Rolls-Royce, there was a clear need for long-term compatibility and availability, thus limiting the potential for 'reinvention' of implementations. In all cases, we conclude that an organization's specific business needs and context affect which opensource practices can be adopted, and how they are adopted.
In terms of using a common set of development tools, different organizations may have varying challenges. Given that most development at Neopost is embedded software, the range of software technologies used is rather homogeneous (i. e. , C and C++). At Rolls-Royce the variety was much larger, ranging from Python scripts to large legacy code bases written in COBOL, thus requiring tool support for each of the used technologies. Philips have made a clear commitment to their Inner Source initiative and ensured the required tools are available. Overall, the freedom to introduce new development tools was not a trivial issue in the organizations that have not yet adopted Inner Source. 6. 1. 3. Organization and Community. Adopting Inner Source is, after all, an organizational change, although the extent and degree of change will vary widely per organization.
In all three cases, we found that the nature of Inner Source adoption will depend on existing organizational structures and how amenable those structures are. We observed in both Neopost and Rolls-Royce that certain developers take ownership of a certain software component, which clearly suggests there is room for trusted lieutenants to emerge. At the same time, it is very important that a core team provides overall management of a shared asset: within Philips, the core team plays a pivotal role in planning and participating in co-development projects. We also argue that transparency is important (Section 4. 3. 2). Our study shows that this was a very important point within Philips as it made their internal community "much more active" (Section 5. 3. 2). However, introducing this transparency can be challenging for a number of reasons.
For an organization's management, there may be various drivers, such as increasing software reuse and reducing cost. However, while Inner Source can offer a number of benefits, it is not a panacea  [Stol et al. 2011 ]. The parties involved must be supported with budgetary and other resources. The literature suggests that identifying champions and giving them the space to advocate an Inner Source initiative is essential  [Dinkelacker et al. 2002; Gurbani et al. 2006]. Our contacts at the case study organizations are such champions; however, it is obviously a challenge to convince top-level management to commit to an Inner Source initiative. In both Neopost and Rolls-Royce, participants of our study suggested that while Inner Source initiatives are welcome, in practice a lack of budget or time inhibits pursuing them fully.
These are credibility (paralleling internal validity), transferability (external validity), dependability (reliability), and confirmability (objectivity). These are also recommended by  Cruzes and Dyb å [2011]  as appropriate for assessing the trustworthiness of a research study in a software engineering context. Previously,  Sfetsos et al. [2006]  used these in a qualitative study of Extreme Programming. The following evaluation discusses how each of these aspects of our study's trustworthiness was addressed as well as some limitations of our study. Some tactics (e. g. , triangulation) help to address several of the aspects below; they are discussed for each aspect separately. 6. 2. 1. Credibility. A study's credibility refers to the extent to which we can place confidence in the findings, or that the findings are plausible  [Guba 1981 ].
Philips was selected as a case as they have an established track record of Inner Source adoption, and therefore is a suitable choice to demonstrate that all factors of our framework are relevant from an Inner Source perspective. The cases of Neopost and Rolls-Royce are both also relevant for two reasons. First, both organizations were actively interested in adopting Inner Source, and thus represent the target audience for the framework. Second, both organizations have already started a number of initiatives that resemble elements of Inner Source. For instance, some Neopost developers already used the principle of 'self-selecting' a defect to work on, for which a patch was sent to the software package's maintainer. Also, other developers use peer-review as a practice, and Neopost's component group initiative resembled a core team.
Among the weakness of this finite element simulation they does not take into account residual manufacturing stress. Other study  [10]  has developed a numerical chain to integrate only the hardening process effect on the wheel, in order to study the rail/wheel fatigue contact. In our case, ABAQUS commercial finite element modeling software has been used to develop the numerical chain to 1 : 3 scale. In the first step of the numerical chain we simulate the forging process to obtain the final axisymmetric geometry of the axle. Then we proceed by transferring results to simulate the assembly process of the wheel on the axle. The final simulation is related to the application of fatigue load on the structure.