The thesis that open-source is created by geek enthusiasts in our time has lost some relevance. However, the open source ideology was born that way. Cool programs, written at night, bearded (and not very) geezer, disinterestedly, just to make the world better - changed the world of software development.

Any programmer secretly wants to do something big and bright for everyone to like. If you tell me that you are not one of those that you just like to close the tickets in the working bug tracker, and you don’t dream of releasing your project to the big world, I won’t believe you. Or advise you to change the profession. I am convinced that a programmer is an artist, and it is important for an artist to do something of his own, perhaps just “on the table” - but to do it.

Once, the idea of ​​a project fell into my head. The idea was purely research, and I was not going to make a kind of “product” out of it. In addition, I had not previously led projects in the public domain and I really wanted to try, as it generally happens. What came out of it - under the cut.

At the very beginning of the life of the project, I already wrote about him on Habré. Then it was the first steps, the code was raw, but it worked. I wanted the project to arouse interest from other authors, because I obviously would not have pulled it alone and abandoned it in general. In principle, it would have happened if I had not received my first pull-request from a stranger. But first things first…
')

What is this about?

I made my own implementation of a stack machine executing scripts in 1C: Enterprise. Or, if it is simpler, an open interpreter of the 1C language and an open implementation of some standard 1C classes. At the same time, a clear applied goal of the project was set up - to give 1C-nicknames a scripting automation tool that would be easy to learn. The project was named 1Script.

And so, the project was published on Habré and on the profile infostart.ru portal 1C- ovsky . Waiting for feedback. I received the first response on myst and laughed heartily. The topic on the forum was called “Interpreter 1C on Habré. Let's zachmyrim? " There are a lot of good people on Mr. I, I was glad :)

Then we went to more or less adequate questions, to which I diligently answered, after which the articles in the normal mode dropped from the first pages somewhere down, and the interest in the project subsided. Well, it was the expected final, I got a little sad, but not much. Actually, I did not count on any particular result. Chatted and okay. The days went by, I finished something, even laid out another version, but nobody except me needed it. My crush has dried up. Although I was not disappointed, I stopped writing new code.

Second wind

About two months after the publication, Sergey Batanov came to me (Serega, hello! :) - a noticeable dude in the 1C-nick community who offered his assistance in developing the standard library. This was the 1C class “Table of Values”. Of course, I agreed. And when I saw the real code that Sergey sent, I was happy, like a child, really. On the Internet, it often happens when someone offers something in words, but often does not get to the point. And then - the real live code that works, which is completely adequate, which can be inserted into the project!

At the same time, the task is quite large, I myself would be too lazy to do it. And here - a tangible, really useful, measurable by lines of code contribution to the overall project! In short, I’m not lying if I say that it was Sergey who did it so that the project was not abandoned by me. This awesome inspiration is to get help from a stranger. Just because he was interested in what you started.

Gradually, I began to receive feedback from people who tried the engine and asked "where is this feature?", "But how to do this?" All these questions had to be answered, saying that this is a prototype, and most urgently these features add. But enthusiasm went off scale: "People are interested and try to use," so new features were added fairly quickly. Initially, the standard library did not even have functions to work with files.

Further more

After some time, I was written by Alexander Kuntashov, with a question about the integration of 1Script and the Snegopat project ( www.snegopat.ru ). Who does not know - this is such a resharper for 1C. In it you can make script plugins to the 1C Configurator and there is a whole community of authors of similar plugins.
These plugins were written in JavaScript, and therefore required qualifications that went beyond the standard 1C programmer. Because of this, ultimately, the development of the ecosystem of plug-ins was inhibited. The number of people who want to improve the Configurator is approximately equal to the total number of 1C-nicknames, however, the need to learn JavaScript scares the authors of potential masterpieces.

Again, I was wildly delighted with the demand for my brainchild, asked the author for the Snegopata distribution kit and shook dust from my C ++ knowledge. The dust turned out to be much more than knowledge, but the creative itch did the trick, and I plunged into MSDN.

About a month later, in the Configurator 1C, it became possible to write plugins directly in 1C, without switching to the JavaScript editor window. At the same time, the first critical engine bugs were fixed and the internal architecture was significantly revised.
I received an intoxicating delight in communicating with C ++, COM, ATL and everyone else after many years of working exclusively with 1C. Well, also from the fact that he did something useful, tangible for the 1C-nick community.

The first experience of combat use

At about the same time (I don’t remember exactly), the project came to the attention of Alexey Lustin ( alexey-lustin ) (Lech, hello to you too!) - among 1C-nicknames a person known and respected. This coincided with my search for a new job. I looked after interesting companies in the market, and Alexey - specialists for the project Continuos Integration / Continuos Delivery for 1C-nicknames. Then Lesha had already seen my project (and nickname) on Habré, and I already knew that a certain team of advanced 1C-nicknames in the network do interesting non-standard things.

At that moment, such things as unit testing, storing 1C code in git, BDD + cucumber for 1C, and so on were already known in the community. Alexey seemed to me the most accessible of these dudes, and I wrote him a letter, asking if he had any interesting work. So, together with my project, I got into a cheerful company of geeks who had gathered at that time in the company where Alexey worked.

At that time, the engine already had a minimum set of capabilities needed by the script, and it could (it seemed to me) in principle be used as scripting for building and deploying 1C bases.

Why use a new engine for this?

Actually, the scripting languages ​​are a zillion, it’s not clear why we need another one, and even an unknown one - the reader will ask Habr - and it will be not quite right. Strategically, the future product was intended for 1C-nicknames and would have to live on from developer to developer, regardless of personnel changes in the company. In the 1C-nick community there is an objective problem: among them there are a lot of cool specialists, but for some reason the average 1C-nickname does not want to learn any other language, after having filled a hand in 1C well. I do not know what is the cause of this phenomenon, probably because 1C (irony)? People come to 1C knowing Java, C / C ++, microcontrollers, Delphi, or not knowing anything, but they often stay in 1C and reluctantly go back to their original ecosystems.
I now foresee a wave of anger, but be kind, listen to the thesis to the end. There are exceptions to any rule, however, planning a system that must go through several generations of developers (not biological, but personnel generations, of course), then you are most likely to find a specialist who can develop it if it is written in 1C. If it is a python (or insert your favorite language), then you will have to hire a python man who knows 1C very well. And after his transition to the big bosses - you will have to look for another one of the same, with competences in the field of 1C. And if it is immediately 1C language, then you will have to find only 1C-nick, who knows 1C well and that will be enough.
In other words, the system will be more resilient and will be able to develop by a large number of specialists, if it is written in the whole language they know.

Thus, the scope of 1Script became clear: these are DevOps and similar tasks for 1C projects.

The first bumps and proper development

The first more or less large script that I wrote (there were no more than a hundred lines of texts before) caused the engine to fall. With a certain combination of parameters and call chains, control was transferred to an unknown place in the code, and the application crashed. I had to almost completely rewrite the implementation of the call stack and exception handling. It was a call in the style of "Oh, so! Well, I'll fix you, schA! ”The fighting fuse allowed me to rewrite the necessary modules in one day and to reveal, in addition, a couple of other bugs. The code began to run stably. I have released a new release. Along the way, since I was now engaged in Continuous Integration, it came to the realization that the project also needed a build server and release release automation. In addition, artbear joined the project , known among 1C nicknames as a luminary and a guru of 1C testing. He made me on the basis of his xUnitFor1C framework toolkit for testing the engine. So I had acceptance behavior tests, also written in 1C. I picked up TeamCity on my home server and set up nightly builds with a test run. Along the way, I was charged with enthusiasm - the project lives and acquires new contributors. It was wildly inspired.

For some three or four months, the class library of the engine has acquired, finally, everything necessary for most scripting tasks: network functions, work with archives, XML and so on. Our project on CI for 1C was successfully launched.

At about the same time, thanks to alexey-lustin again, new interested users began to come to the project. They requested features, found bugs, demanded new releases.
The flow of features, the allocation of the library code, along with the need for a simple release scheme, led me to such an interesting thing as growth. But about her, a little later.

In November 2014, I was invited to speak at the prestigious 1C conference of the Infostart Event in St. Petersburg. Of course, I agreed, and I took 1Script with the topic of the speech. The topic was approved that, for me, firstly, the fact of some fame of the project (that is, the listeners would probably come, because at least they heard something about it), and secondly, I hoped to attract contributors since the time for the development of the engine is almost over.
Especially for the conference, I even made a special fun - CGI mode, in which the scripts could be run under the control of the HTTP server and generate the HTTP output. Sites in the language of 1C is no longer a terrible dream of the host, but a harsh reality (just kidding).
Speech at Infostart can be considered the first public announcement, where 1Script can no longer be ashamed to be called a product, a tool capable of solving specific tasks. It was no longer an experiment, but a combat product. Although still in beta status.

Growth Problem or Pitfalls Project Support

As it turned out, the presence in your management of a claimed project, even a small one, carries a considerable overhead of such a burden. For starters, this is a stream of features. Wishes come much more often than commits that implement these wishes. It is required to strictly consider the versions in which certain errors were corrected. It is necessary to notify users somehow that a bug has been fixed or a new feature has appeared since version X. Increased functionality requires documentation, and documentation tends to become obsolete.
And the funny thing is that the technical infrastructure of the “support” itself is required. It took a website, a documentation generator, an assembly / deployment server, and so on and so forth ... It took financial investments in infrastructure — minimal, but still investments.
Starting a research project, I did not even anticipate the number of organizational and technical issues that would be faced with the growth of the project. The transition to the git-flow method helped a lot in this regard, it became easier to understand yourself and communicate with users on the topic of versions and branches.

Crowdfunding experience (horrible word)

At the beginning of this year I tried an experiment - I organized a collection of donations for the infrastructure - a domain name and hosting. I was wondering how the project could pay for its own existence. The result was, people unfamiliar to me, really, sent about 100-500 p. which was enough to pay for a domain name in the .io zone. Then, the campaign was curtailed and the flow of funds stopped. It did not come to full payback, although some financial support was received.
The most important thing is that the thesis about the effectiveness of the donation model, as such, was tested in its natural form. Conclusion - in my case donation can hardly be called effective, although it was not zero.

Library of useful scripts

For a year and a half of coding, 1Script library blocks stood out, which you can use yourself and recommend to others. A natural way at my disposal accumulated a number of developments that were recyclable.
This led to the fact that the ability to connect third-party "packages", also written in 1Script, was added to the engine. The output was another project, called the oscript-library. ( https://github.com/EvilBeaver/oscript-library ) This library, of course, also required infrastructure, documentation, end-user updates, and more. But the flow of contributing by 1C-nicknames has increased significantly. After all, packages are developed in an already familiar language, which means that you can immediately benefit, port existing work, etc. The community of “1C script writers” began to grow, which was largely contributed to the second report at the Infostart Event in 2015.

What it looks like

For import, a special preprocessor directive is used. #Use (#Use) It is not in the original 1C platform, but for the ease of importing libraries, we had to deviate from the canonical syntax and borrow the solution in other ecosystems.

# json //  JSON        #  =  JSON(); //   -  // ... 

The specific solution was already developed by a team of authors, application scenarios, pitfalls, etc. were thought out. Google Docs was used as a tool for brainstorming.

Batch manager

To manage the packages, a simple package manager was written on his knee, called OPM (OneScript Package Manager). It is also written in 1Script and is a console package management utility. Currently, the package infrastructure is being rethought and work is being done on a production-ready version of opm.

Project today

Today, 1Script is a stable, successfully used automation tool for 1C-nicknames in dozens of companies. In addition, OneScript is already a kind of brand, this name is known in the community, the tool is actively used, written, asked questions, discussed and, which is especially pleasant, is being finalized.
In addition, a library of reusable code packages is an almost integral part of the project. It is small, but covers a significant part of the tasks solved daily by a typical 1C-nick.
This is no longer just a "1C interpreter". The community has created an ecosystem of useful and sought-after tools.
For me, it was a unique experience, I received words (and deeds) of support from dozens of unfamiliar (and now familiar) people to me. The program that I started solely in order to "try" turned into a working project used in real combat missions. In addition, a great experience was gained in managing such an open-source project - support, maintenance, infrastructure, etc.
Well and the most important thing - the pleasure is received that you do something necessary.

What we plan to do next

The active use of the library packages revealed a number of shortcomings and inconveniences. We plan to make adjustments to the package infrastructure and expand the functionality of the package manager. We also plan to expand the set of libraries, for example, now we are working on a wrapper for the Docker API. We manage docker-containers with the help of scripts on 1C and developments on this topic are likely to also be published when they are brought to mind. This will result in a simplified DSL for manipulating containers from the 1script script.

Technical summary

• Programming language - C #, .NET v4.0 / Mono 3.1x
• Development environment - VS 2013-2015
• The interpreter name is oscript.exe (run for execution is oscript <your-file>)
• Script File Extension - .os
• Package file extension - .ospx
• Code performance - in most measurements up to 4 times faster than the original 1C platform. At least, not slower than her.
• Engine repository - github.com/EvilBeaver/OneScript
• Library repository - github.com/oscript-library

I don’t write the project’s website, firstly, so that it doesn’t sound like PR, and secondly, it simply cannot endure the habraeffect.

Tips for novice experimenters

If you have your own project that you would like to bring to light, then let me give you a couple of tips based on personal experience.

• Dare! If you keep your project in the table and do not tell anyone about it, then no one will know about it. Start with an article on Habr. One article will not be enough. Mention your project in the forums dedicated to the subject area of ​​your project, give examples of successful application.
• Be prepared for the fact that there are many offers from people, and there are much less real commits. Approach in the style of "This is open-source, you need, you do it", unfortunately, not a ride.
• Think over the solution of the “growth problem” in advance. Growth, as a rule, is explosive and coping with a sharply increased pool of tasks is quite difficult.
• Automate everything you can from the start - testing, building, publishing versions, documenting. These things are easiest to save for later, but “later” there will be no time to automate all this.
• Attract contributors. Contribution to the project is not only code. Often it is even just ideas. Ask: “how best to do this,” “how this might look.” You will be prompted. And it is likely - will help.
• Growing a project is incredibly awesome. Feel free to share your work, enjoy the process!

Thank you for reading to the end! :)