• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

A little story

crowning

crowning

Well-known member
Over there I wanted to explain sergey461 how open source development works with a little story, but it got a bit lengthy so I decided to give it its own thread.

Here we go:
[ quote from there ]
------------------------------------------------------------------
Let me explain UdjinM6 's answer with a little story:

Last year I discovered Dash (Darkcoin back then). I liked the concept, the openness of its developer, and the fact that you could still mine it with a modest profit.
The base technology was quite advanced, a bit adventurous at times, but with a clear development direction, a fact which was lacking with my "main" coin at that time, Litecoin.
What I didn't like at all was that it was still using the original Bitcoin wallet, which was lacking a lot (feature wise) and looked rather un-sexy.
I decided to develop my own wallet. In Java, because that's the language I use in my professional "other" life.

After a couple of weeks and iterations of my wallet I gave up, mainly because the C++ codebase changed THAT much every other day that most of the time I had to catch up with Evan's changes instead of developing my wallet.

I didn't want to develop in C++ (I was quit good at C++ ages ago, but my last C++ project before switching to Java was back in 1996, so I felt too out-of-loop to contribute anything useful), so I started to post development requests over at the old Darkcoin Jira, which were liked by the community, but never got implemented. Not because Evan was too lazy or didn't like the ideas, but he had other priorities and a day only has 24 hours.

At some point I figured instead of bugging Evan every other day I could use that time to actually implement the stuff I wanted.

Requirements? Use cases? Someone to tell you what to do, and how to do it? Specification? Design?

Fuck it.

I want THAT button, HERE on this page, and it should do THIS and THAT. And I want it NOW.

I had to learn some minor things and tools I had never used before, though:
  • Github? What's that? How can I clone a repository? How can I create a branch? What's a pull request? Why do usable Git-GUIs always lack the functions I need but offer everything else? What's bigger, the number of stars of the known universe or the possible permutations of git command-line parameters?
  • Qt? Well, it's got an API with 1209 classes (YES, I've counted them. Twice!). First experience was that what you need is always in some other class, and the results were something which were almost, but not quite, entirely unlike what I wanted. Times operating systems it supports.
  • Boost library? Probably (I stopped counting somewhere) even more classes. Lots of them non-trivial. But a great toolset to solve problems. And an even greater toolset to create completely new problems, especially when you have no plan what you're doing.
  • Gitian? One of coolest tools I've ever seen. Wicked. I'm still undecided whether the guy who created it is a genius or completely nuts. Probably both. Not hard to set up if you have a week or two of spare time.
So I implemented my first feature request (dunno what it was. Probably something with a shiny button. Or fixed a string which was spelled wrong), made a screenshot of my changes and created a pull-request, and eventually it got merged into the main repository.

No release plan. No design papers. No meetings. Maybe a reply to the request with change proposals, or pointers where I messed things up.

Do.
Publish.
Discuss.

Not the other way around. In open source, when you start with the "discussion" part, almost always nothing will ever be done at all because everyone has an opinion, some even more. Too much time and nerves wasted in discussions instead of doing things.

What if you invested your time to implemented something and it doesn't get accepted? Live with it, life goes on.

Is this the best way to develop software? Probably not.

But it works and produces results. That's what counts.
 
Last edited by a moderator:
crowning said:
Over there I wanted to explain sergey461 how open source development works with a little story, but it got a bit lengthy so I decided to give it its own thread.

Here we go:
[ quote from there ]
------------------------------------------------------------------
Let me explain UdjinM6 's answer with a little story:

Last year I discovered Dash (Darkcoin back then). I liked the concept, the openness of its developer, and the fact that you could still mine it with a modest profit.
The base technology was quite advanced, a bit adventurous at times, but with a clear development direction, a fact which was lacking with my "main" coin at that time, Litecoin.
What I didn't like at all was that it was still using the original Bitcoin wallet, which was lacking a lot (feature wise) and looked rather un-sexy.
I decided to develop my own wallet. In Java, because that's the language I use in my professional "other" life.

After a couple of weeks and iterations of my wallet I gave up, mainly because the C++ codebase changed THAT much every other day that most of the time I had to catch up with Evan's changes instead of developing my wallet.

I didn't want to develop in C++ (I was quit good at C++ ages ago, but my last C++ project before switching to Java was back in 1996, so I felt too out-of-loop to contribute anything useful), so I started to post development requests over at the old Darkcoin Jira, which were liked by the community, but never got implemented. Not because Evan was too lazy or didn't like the ideas, but he had other priorities and a day only has 24 hours.

At some point I figured instead of bugging Evan every other day I could use that time to actually implement the stuff I wanted.

Requirements? Use cases? Someone to tell you what to do, and how to do it? Specification? Design?

Fuck it.

I want THAT button, HERE on this page, and it should do THIS and THAT. And I want it NOW.

I had to learn some minor things and tools I had never used before, though:
  • Github? What's that? How can I clone a repository? How can I create a branch? What's a pull request? Why do usable Git-GUIs always lack the functions I need but offer everything else? What's bigger, the number of stars of the known universe or the possible permutations of git command-line parameters?
  • Qt? Well, it's got an API with 1209 classes (YES, I've counted them. Twice!). First experience was that what you need is always in some other class, and the results were something which were almost, but not quite, entirely unlike what I wanted. Times operating systems it supports.
  • Boost library? Probably (I stopped counting somewhere) even more classes. Lots of them non-trivial. But a great toolset to solve problems. And an even greater toolset to create completely new problems, especially when you have no plan what you're doing.
  • Gitian? One of coolest tools I've ever seen. Wicked. I'm still undecided whether the guy who created it is a genius or completely nuts. Probably both. Not hard to set up if you have a week or two of spare time.
So I implemented my first feature request (dunno what it was. Probably something with a shiny button. Or fixed a string which was spelled wrong), made a screenshot of my changes and created a pull-request, and eventually it got merged into the main repository.

No release plan. No design papers. No meetings. Maybe a reply to the request with change proposals, or pointers where I messed things up.

Do.
Publish.
Discuss.

Not the other way around. In open source, when you start with the "discussion" part, almost always nothing will ever be done at all be cause everyone has an opinion, some even more. Too much time and nerves wasted in discussions instead of doing things.

What if you invested your time to implemented something and it doesn't get accepted? Live with it, life goes on.

Is this the best way to develop software? Probably not.

But it works and produces results. That's what counts.
Click to expand...
I LOVE YOUR STORY!! Just love it love it!! :grin:

Programming is not for everybody and learning programming from uni is the worst! They do not teach you there's a world out there called "open source"!
 
crowning said:
Over there I wanted to explain sergey461 how open source development works with a little story, but it got a bit lengthy so I decided to give it its own thread.

Here we go:
[ quote from there ]
------------------------------------------------------------------
Let me explain UdjinM6 's answer with a little story:

Last year I discovered Dash (Darkcoin back then). I liked the concept, the openness of its developer, and the fact that you could still mine it with a modest profit.
The base technology was quite advanced, a bit adventurous at times, but with a clear development direction, a fact which was lacking with my "main" coin at that time, Litecoin.
What I didn't like at all was that it was still using the original Bitcoin wallet, which was lacking a lot (feature wise) and looked rather un-sexy.
I decided to develop my own wallet. In Java, because that's the language I use in my professional "other" life.

After a couple of weeks and iterations of my wallet I gave up, mainly because the C++ codebase changed THAT much every other day that most of the time I had to catch up with Evan's changes instead of developing my wallet.

I didn't want to develop in C++ (I was quit good at C++ ages ago, but my last C++ project before switching to Java was back in 1996, so I felt too out-of-loop to contribute anything useful), so I started to post development requests over at the old Darkcoin Jira, which were liked by the community, but never got implemented. Not because Evan was too lazy or didn't like the ideas, but he had other priorities and a day only has 24 hours.

At some point I figured instead of bugging Evan every other day I could use that time to actually implement the stuff I wanted.

Requirements? Use cases? Someone to tell you what to do, and how to do it? Specification? Design?

Fuck it.

I want THAT button, HERE on this page, and it should do THIS and THAT. And I want it NOW.

I had to learn some minor things and tools I had never used before, though:
  • Github? What's that? How can I clone a repository? How can I create a branch? What's a pull request? Why do usable Git-GUIs always lack the functions I need but offer everything else? What's bigger, the number of stars of the known universe or the possible permutations of git command-line parameters?
  • Qt? Well, it's got an API with 1209 classes (YES, I've counted them. Twice!). First experience was that what you need is always in some other class, and the results were something which were almost, but not quite, entirely unlike what I wanted. Times operating systems it supports.
  • Boost library? Probably (I stopped counting somewhere) even more classes. Lots of them non-trivial. But a great toolset to solve problems. And an even greater toolset to create completely new problems, especially when you have no plan what you're doing.
  • Gitian? One of coolest tools I've ever seen. Wicked. I'm still undecided whether the guy who created it is a genius or completely nuts. Probably both. Not hard to set up if you have a week or two of spare time.
So I implemented my first feature request (dunno what it was. Probably something with a shiny button. Or fixed a string which was spelled wrong), made a screenshot of my changes and created a pull-request, and eventually it got merged into the main repository.

No release plan. No design papers. No meetings. Maybe a reply to the request with change proposals, or pointers where I messed things up.

Do.
Publish.
Discuss.

Not the other way around. In open source, when you start with the "discussion" part, almost always nothing will ever be done at all because everyone has an opinion, some even more. Too much time and nerves wasted in discussions instead of doing things.

What if you invested your time to implemented something and it doesn't get accepted? Live with it, life goes on.

Is this the best way to develop software? Probably not.

But it works and produces results. That's what counts.
Click to expand...

I agree with moli... LOVE IT You sure know how to tell a story!
 
moli said:
Everybody should tell their story how they got into this coin and what it was like at the beginning...

Your turn now. I'm busy atm. lol
Click to expand...
And you, always in 'the know', should keep journals and notes... for when the studios one day decide to make The Story of Dash movie.
 
crowning said:
Over there I wanted to explain sergey461 how open source development works with a little story, but it got a bit lengthy so I decided to give it its own thread.

Here we go:
[ quote from there ]
------------------------------------------------------------------
Let me explain UdjinM6 's answer with a little story:

Last year I discovered Dash (Darkcoin back then). I liked the concept, the openness of its developer, and the fact that you could still mine it with a modest profit.
The base technology was quite advanced, a bit adventurous at times, but with a clear development direction, a fact which was lacking with my "main" coin at that time, Litecoin.
What I didn't like at all was that it was still using the original Bitcoin wallet, which was lacking a lot (feature wise) and looked rather un-sexy.
I decided to develop my own wallet. In Java, because that's the language I use in my professional "other" life.

After a couple of weeks and iterations of my wallet I gave up, mainly because the C++ codebase changed THAT much every other day that most of the time I had to catch up with Evan's changes instead of developing my wallet.

I didn't want to develop in C++ (I was quit good at C++ ages ago, but my last C++ project before switching to Java was back in 1996, so I felt too out-of-loop to contribute anything useful), so I started to post development requests over at the old Darkcoin Jira, which were liked by the community, but never got implemented. Not because Evan was too lazy or didn't like the ideas, but he had other priorities and a day only has 24 hours.

At some point I figured instead of bugging Evan every other day I could use that time to actually implement the stuff I wanted.

Requirements? Use cases? Someone to tell you what to do, and how to do it? Specification? Design?

Fuck it.

I want THAT button, HERE on this page, and it should do THIS and THAT. And I want it NOW.

I had to learn some minor things and tools I had never used before, though:
  • Github? What's that? How can I clone a repository? How can I create a branch? What's a pull request? Why do usable Git-GUIs always lack the functions I need but offer everything else? What's bigger, the number of stars of the known universe or the possible permutations of git command-line parameters?
  • Qt? Well, it's got an API with 1209 classes (YES, I've counted them. Twice!). First experience was that what you need is always in some other class, and the results were something which were almost, but not quite, entirely unlike what I wanted. Times operating systems it supports.
  • Boost library? Probably (I stopped counting somewhere) even more classes. Lots of them non-trivial. But a great toolset to solve problems. And an even greater toolset to create completely new problems, especially when you have no plan what you're doing.
  • Gitian? One of coolest tools I've ever seen. Wicked. I'm still undecided whether the guy who created it is a genius or completely nuts. Probably both. Not hard to set up if you have a week or two of spare time.
So I implemented my first feature request (dunno what it was. Probably something with a shiny button. Or fixed a string which was spelled wrong), made a screenshot of my changes and created a pull-request, and eventually it got merged into the main repository.

No release plan. No design papers. No meetings. Maybe a reply to the request with change proposals, or pointers where I messed things up.

Do.
Publish.
Discuss.

Not the other way around. In open source, when you start with the "discussion" part, almost always nothing will ever be done at all because everyone has an opinion, some even more. Too much time and nerves wasted in discussions instead of doing things.

What if you invested your time to implemented something and it doesn't get accepted? Live with it, life goes on.

Is this the best way to develop software? Probably not.

But it works and produces results. That's what counts.
Click to expand...


Nice story. Can I provide my private story.
Once time I get part in one project as arhitect. Customer say: I need system in 3 months. .... I think "Okey" ... May I see to requirements? Customer say "of course!!" And call analysis. And analysis say: we started to develop requiremets two weeks ago. I say ... THAT?!?!?!?!?!? Customer waits system but .....

I say "Okey.. But we works in 'TimeAndMaterial' scheme and all risks is yours" Customer say "ok".

I and my command works 3 months hardly!!!! And rewrite code again and again. But deadline is comming. As final: We works hardly and we NOT produces result .

In begin og the year ... The situation is repeated. But ... I am not works hardly.

Summary: We must know that software we develop anather we can develop endlessy and not produces result (Hm ... we don't khow that result we needs).
I agree that we have to observe some balance between documentation and coding.
 
sergey461 said:
Nice story. Can I provide my private story.
Once time I get part in one project as arhitect. Customer say: I need system in 3 months. .... I think "Okey" ... May I see to requirements? Customer say "of course!!" And call analysis. And analysis say: we started to develop requiremets two weeks ago. I say ... THAT?!?!?!?!?!? Customer waits system but .....

I say "Okey.. But we works in 'TimeAndMaterial' scheme and all risks is yours" Customer say "ok".

I and my command works 3 months hardly!!!! And rewrite code again and again. But deadline is comming. As final: We works hardly and we NOT produces result .

In begin og the year ... The situation is repeated. But ... I am not works hardly.

Summary: We must know that software we develop anather we can develop endlessy and not produces result (Hm ... we don't khow that result we needs).
I agree that we have to observe some balance between documentation and coding.
Click to expand...
With open source if your code doesn't work then it's just not accepted to a project, and you move on. You are free to use someone else's code to create whatever you want. And your code is also free for others to use. I'm still not sure if you understand this concept. Maybe google and read about "open source" and visit a few sites, for example:

https://github.com/dashpay/dash (Dash's site)
http://sourceforge.net/ (another open source website for programmers)

https://opensource.com/resources/what-open-source
https://opensource.com/life/14/1/get-involved-open-source-2014
 
sergey461 said:
Nice story. Can I provide my private story.
Once time I get part in one project as arhitect. Customer say: I need system in 3 months. .... I think "Okey" ... May I see to requirements? Customer say "of course!!" And call analysis. And analysis say: we started to develop requiremets two weeks ago. I say ... THAT?!?!?!?!?!? Customer waits system but .....

I say "Okey.. But we works in 'TimeAndMaterial' scheme and all risks is yours" Customer say "ok".

I and my command works 3 months hardly!!!! And rewrite code again and again. But deadline is comming. As final: We works hardly and we NOT produces result .

In begin og the year ... The situation is repeated. But ... I am not works hardly.

Summary: We must know that software we develop anather we can develop endlessy and not produces result (Hm ... we don't khow that result we needs).
I agree that we have to observe some balance between documentation and coding.
Click to expand...

Time for stories? Alright then :rolleyes:

Actually that sounds very familiar to me. I worked few years as an architect on few IT-projects where many organizations worked together, CEO and CTO from all these companies were involved in strategic planning, discussing etc, there was combined project team of 10+ to 20+ members that followed all the rules by creating and approving requirements, modifying them through determined process with yet another approvals of global changes on strategic level etc. Everyone worked hard. The thing is: when you start working on something that nobody did (in that environment/conditions) before - you have no idea where it will end and what obstacles there are no matter how experienced all members of your team are. Their experience from previous (even similar) projects can help current team to avoid some previous mistakes that are obvious for them now and this can save you time and money. But in such projects there always will be something no one had any idea about when project just stared.

In open source world it's even worse :grin: In the beginning you are the customer AND the architect AND the programmer of your own product at the very same time. There might be some other customers that come to you and say "hey, that's cool but I want that 'new feature' to be implemented (and I want it now)" or "hey, that's cool but it doesn't work that well, I think there's a bug" (i.e. issues). As well as there might be some other architects/programmers who like what you're doing and they come to you and say "hey, that's cool but there was an issue and I fixed it, have a look" or "hey, that's cool but I just implemented 'new feature' for you and now it's even cooler, have a look" (i.e. pull requests). But it's YOUR product based on YOUR vision and YOUR requirements so you can either accept this issues and pull requests OR use some parts of them and reimplement as you like OR even just deny them completely. You just do what you like, as you like and as much as you like. However if you are making something that is valuable for others there will be more and more customers who are willing to use your product and architects/programmers who are willing to help you. And if it's not that valuable - well, not a big deal, you just made yet another worthless thing :tongue: (not-really, because at least there was some new experience for you).

So, back to where we originally started: if you see something that is missing in Dash but you want it to be implemented and you can implement it from scratch or adapt it from Bitcoin world - just do it (c). :smile: If you're not the only one who need it there will be at least an appreciation from the community and hopefully some help from those who also want to make it happen.

And that's, basically, it.


PS. May the Source be with you :grin:
 
Nice discussion :)

I'd like to throw in a very good post on BCT (one of the gems there) in context of open source, crypto currencies and self organising organisations:


So who is in charge?

When it comes to p2p apps, the bottom line is that as soon as the source code is publicly released, no-one is ”in charge” of anything. The witticism “herding cats” doesn’t even come in to it; people are completely free to do as they like: run a node, not run a node; hold coins, don't hold coins; set up a foundation, a faucet, a business, promote the coin, fud the coin, set up webwallets, offer an alternative wallet design, provide off-chain features, pay to spam the blockchain, pay to clean up the blockchain, generously contribute to a faucet, mischevously drain a faucet dry.

The fact that there is no-one in charge is significant to US financial regulators. A couple of years ago FinCEN made it unambiguously clear ...

A final type of convertible virtual currency activity involves a de-centralized convertible virtual currency (1) that has no central repository and no single administrator, and (2) that persons may obtain by their own computing or manufacturing effort.
Click to expand...

So, “official” this and “official” that are meaningless in the context of a cryptocurrency because no-one has the authority to stamp anything “official”. Or rather, anyone and everyone has the opportunity to stamp anything they want as “official” or make a claim to be “the official dev” but it carries no inherent authority, only that which it itself engenders.

How does anything ever get done?

The thing is, a cryptocurrency is a discrete Open Source project in its own right and in Open Source projects, things just sort of get done. Or not. The psycho-social aspects are currently not terribly-well understood in a number of key areas, one of which is the motivation of contributors.

In the case of altcoins, it seems that the creation of the altcoin's peer2peer network also establishes a social consensus which behaves as a prototypal form of “Teal” organisation as described in Frederic Laloux’ Reinventing organisations.

[...]

Teal EVOLUTIONARY PURPOSE practices
  • organization seen as a living entity with its own evolutionary purpose
  • strategy emerges organically from collective intelligence of self-managing employees
  • decision making by listening to organization‘s purpose (everyone, large group, meditations…)
  • concept of competition irrelevant (embraced to pursue purpose)
  • growth and market share only important in as much they help achieve purpose
  • profit as lagging indicator: will come naturally when doing the right thing
  • inside out marketing: offer is defined by purpose
  • “sense and respond” planning/budgeting/controlling
  • no or radically simplified budgets, no tracking of variance; no targets
  • “change management” no longer relevant as organization constantly adapts from within
  • suppliers chosen by fit with purpose
  • total transparency invites outsiders to make suggestions to better bring about purpose
  • conscious sensing of what mood would serve best

The evolutionary purpose practices are a remarkably close description of the characteristics of an Open Source altcoin project.

In essence, altcoins are de facto Teal Organisations created as a natural consequence of the distributed nature of the p2p app.

Despite the New Waviness, the broad-brush description of a Teal Organisation never quite loses sight of its utilitarian purpose: doing things better, more effectively, with a more complex set of values.

That’s not a bad philosophy for an experimental vehicle like an altcoin to adopt.
Click to expand...


https://bitcointalk.org/index.php?topic=1059746.msg11985838#msg11985838
 
Last edited by a moderator:
crowning said:
Actually I once asked my boss if he could hire someone cheap from India or China to handle my emails and meetings. No kidding.
Didn't work out, though...
Click to expand...
How didn't it work out? I'd do it for you for cheap. 300 DASH a month. :)
 
crowning said:
Communication overhead. When someone needs to ask you 2 questions to answer an email with one question it somehow doesn't save time...
Click to expand...
Thanking on to you? I'd will have then starting tomorrow...

Edit: y1JvTDcWbUh4etmiRagXW6JjkcqRieRRVp
 
moli said:
If you're so cheap.. people will wonder if you can do anything..
I used to think if software is free, it must not be worth anything... :)
Click to expand...
Outrage! You forgot the endless spinning wheel also known as technical support. Think about the indescribable pleasure users would get if developers only provided the program. Free/Libre software is more than the source. That single word stirs to the core :grin:

I have a bad memory, but I think it was the Onyx release. That's when everything started for me. Linux enthusiast > Virtualization > VPS > Dash... Accessible self-hosting and p2p [1] [2] [3]... Is there anything else to be said?
 
My opinion may be unpopular, but I strongly believe that for effective development some level of coordination is needed. A one man team does not need any, as he/she has perfect information, can set his own priorities, etc. As projects grow in size, this changes significantly.

There's a huge competition between cryptocurrencies, and the one with the fastest development team has a huge advantage. And when talking about "fastest", I mean the team that is able to translate real, top priority customer needs into software solutions. It does not matter if a UI bug or a typo is fixed, when a way more important bug is still in the software. And without any level of coordination, contributors to a project may focus their efforts on low priority things, which won't really push the project forward.
Also, more people might be working on the fix to the extact same issue. Or two conflicting solutions can be given to related issues, etc.

While there are definitely benefits of the environment described in crowning 's post, it might not be efficient. And if another coin does better in this regard, our advantage may start to shrink.

And before anyone thinks I'm defending the traditional project based approach - oh, I so don't. But there's a huge range of options between the waterfall model and GitHub's open allocation model. My belief is that some light (really light and fluid) management will increase our overall productivity. Build on the merits of the open source mentality described by OP, and add a thin layer on top of it to coordinate efforts.
 
You must log in or register to reply here.
Back
Top